Memory 具有小ram的巨型图的宽度优先搜索

我目前有一个图，它有大约1000万个节点和3500万条边。目前，完整的图形在程序启动时加载到内存中。这需要几分钟的时间（毕竟是Java），并且需要大约半GB的RAM。目前，它运行在一台配备双核处理器和4G内存的机器上

当使用广度优先搜索来搜索图形时，内存使用量会上升到1GB的峰值，平均需要10秒

我想在几台计算机上部署这个程序。除了图形搜索之外的功能只占用很少的资源。我的目标系统非常微型，只有512兆内存

关于如何实现一种方法（可能使用数据库）来搜索该图而不消耗太多内存，有什么建议吗？由于程序在访问硬件设备时大部分时间处于空闲状态，因此上述图形的路径查找最多可能需要5分钟

谢谢你对我的指导

更新：

---

刚找到。有人知道它是否适合这种庞大的图形吗？

你的问题有点含糊不清，但总的来说，一个好的策略主要遵循广度优先语义，同时使用与深度优先搜索相同的内存量。这个想法是，你做一个深度优先搜索，一开始只限于1级；如果找不到解决方案，从零开始，限制在2个级别；如果失败，尝试3个级别，以此类推

---

一开始这似乎有点多余，但由于您进行的是深度优先搜索，所以内存中保留的节点要少得多，并且始终比直接的广度优先搜索少搜索一个级别。由于一个级别中的节点数量呈指数增长，在较大的图形上，很可能节省最后一个额外级别会为冗余地尝试前面的所有层带来回报。

我想说，当您有这样一个大小合适的图形时，Neo4j绝对是一个好方法。它不仅具有内置的BFS算法，还可以将数据持久保存在磁盘上，从而缩短启动时间

请在highscalability.com上查看：

我使用过Neo4j，它们的文档非常好，它们提供了一些很好的入门示例，实际上只需要几分钟就可以开始

---

查看他们的-

Neo4j将数据以图形形式存储在数据库中，数据将被持久化，您可以使用图形遍历Api（BFS、DBS、A*Dijkstra…）或使用Cypher查询语言进行访问。

如果可能（取决于您的任务），您可以使用BFS的非完整替代方案。。比如光束搜索？减少搜索的前端通常会提高性能lot@IVlad不，节点本身只是一个从0到10000000的整数。其余的数据是根据需要从XML文件中提取的。伊夫拉德的评论只是对储蓄失去了理解mine@anthares：光束搜索听起来是个不错的尝试。不过，我更愿意将整个图表保留在内存之外。到目前为止，我还不知道/没有想过迭代深化。这听起来像是至少解决实际搜索的内存使用问题的第一步。在文件或数据库中保留ram中的实际数据时，对图形搜索的执行情况有何粗略估计？取决于图形的表示方式。也许您可以逐级加载它，直到找到解决方案为止？为每个节点直接读取磁盘很可能会对性能造成严重破坏。有趣。我应该尝试编写一个为此优化的索引文件。目前，该文件只是一个ASCII列表，其中包含大量的REFERENCE->referenced。如果可以正确排列数据，还可以加载后续级别，以便在搜索过程中进行异步搜索。也就是说，在搜索级别4时，从磁盘读取级别5。但这确实要求数据文件从任何根节点按级别排序。@Novelocrat:我每次都有不同的开始（根）节点和结束节点。所以用这种方式储存是有点困难的。