Graph 哪种技术最适合存储和查询大型只读图形？

我有一个巨大的有向图：它由160万个节点和3000万条边组成。我希望用户能够找到图形的两个节点之间的所有最短连接（包括传入和传出边）（通过web界面）。目前，我已将图形存储在PostgreSQL数据库中。但是这个解决方案不是非常高效和优雅，我基本上需要将图的所有边存储两次（参见我的问题）

---

有人建议我使用像or这样的图形。然而AllegroGraph的免费版本仅限于5000万个节点，并且还有一个非常高级的API（RDF），对于我的问题来说，它似乎太强大和复杂了。另一方面，Neo4j只有一个非常低级的API（python接口还不成熟）。这两种方法似乎更适合于节点和边频繁添加或删除到图形中的问题。对于图形上的简单搜索，这些GraphDB似乎太复杂了

我的一个想法是“误用”一个搜索引擎，因为我基本上只是在图表中搜索连接

另一个想法是，使用服务器进程，将整个图形（500MB到1GB）存储在内存中。然后，客户机可以查询服务器进程，并且可以非常快速地遍历图，因为图存储在内存中。使用一些现有的框架编写这样的服务器（最好是Python）是否很容易

---

您将使用哪种技术来存储和查询如此巨大的只读图形？

必须管理一个相当大的图形。了解他们的架构可能会有所启发。请特别注意它们是如何将整个图形缓存在内存中的。

我有一个有向图，我（mis）使用了Lucene

每个边都存储为一个文档，节点作为文档的字段，我可以搜索这些字段

它的性能已经足够好了，使用它作为基于web的工具的用户可以接受从节点获取入站和出站链接的查询时间。但是对于计算密集型的批处理计算，我正在做许多100000次的查询，我对得到的查询时间不满意。我感觉到我肯定误用了Lucene，所以我正在研究第二个基于Berkeley DB的实现，这样我就可以对两者进行并排比较。如果我有机会在这里发布结果，我会这样做

---

但是，我的数据需求比您的数据需求大得多，超过了可用内存的容量。因此，我使用的Lucene索引是在磁盘上的，但对于Lucene，您可以使用“RAMDirectory”索引，在这种情况下，整个内容将存储在内存中，这可能很适合您的需要。

如果我错了，请纠正我，但由于每个节点都是链接节点的列表，因此在我看来，具有模式的DB更多的是负担而不是优势。 听起来谷歌应用程序引擎也很适合你：

• 它是为阅读而优化的——如果你想更快的阅读，它还可以使用memcached
• 它是分布式的，因此大小不会影响效率

当然，如果您以某种方式依赖关系数据库来查找路径，它将不适用于您

我刚刚注意到q已经4个月了

还有一个开源文档图dbms，具有商业友好许可证（Apache2）。简单的API、类似SQL的语言、ACID事务和对Gremlin图形语言的支持

SQL具有树和图的扩展。例如：

select from Account where friends traverse (1,7) (address.city.country.name = 'New Zealand')

---

返回至少一位居住在新西兰的朋友的所有帐户。对于friend，这意味着递归到第7级深度。

因此，您有一个图形作为数据，并希望执行一个经典的图形操作。我看不出还有什么技术比图形数据库更适合使用。

创造性的解决方案，但边的关系数据库不也可以吗？或者我错过了一些你从使用lucene中获得的免费功能？是的，可能会。我使用Lucene只是因为当时我已经在使用它了，我想要一个独立的、可移植的解决方案，可以完全在我的应用程序（如bdb）的过程中运行。“对于简单的图形搜索，这些GraphDB似乎太复杂了。”我不确定这意味着什么。将图形存储在除图形以外的任何对象中都会带来更大的复杂性。