哪种技术最适合存储和查询巨大的只读图？

Question

我有一个巨大的有向图：它包含160万个节点和3000万个边缘。我希望用户能够在图形的两个节点之间找到所有最短的连接（包括传入和传出边缘）（通过Web界面）。目前我已将图存储在PostgreSQL数据库中。但是这个解决方案不是非常有效和优雅，我基本上需要将图表的所有边缘存储两次（请参阅我的问题PostgreSQL: How to optimize my database for storing and querying a huge graph）。

有人建议我使用像neo4j或AllegroGraph这样的GraphDB。然而，AllegroGraph的免费版本限制为5000万个节点，并且还有一个非常高级的API（RDF），这对我的问题来说似乎太强大和复杂。另一方面，Neo4j只有一个非常低级别的API（并且python接口尚未成熟）。它们似乎更适合于问题，其中节点和边缘经常被添加或移除到图形中。对于图表上的简单搜索，这些GraphDB似乎过于复杂。

我有一个想法就是“滥用”像Lucene这样的搜索引擎，因为我基本上只是在图表中搜索连接。

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

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

Answer 1

LinkedIn必须管理一个相当大的图表。查看this info的架构可能会有所帮助。请特别注意它们如何将整个图形缓存在内存中。

Answer 2

还有OrientDB开源文档图dbms，带有商业友好许可证（Apache 2）。简单的API，SQL语言，ACID事务以及对Gremlin图形语言的支持。

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

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

要与至少一位住在新西兰的朋友返回所有帐户。而对于朋友来说，递归到达深度的第7级。

Answer 3

我有一个有向图，其中我（错误）使用了Lucene。

每个边都存储为Document，节点作为文档的Fields，然后我可以搜索。

它的性能足够好，并且从节点获取和出站链接的查询时间对于将其用作基于Web的工具的用户来说是可接受的。但对于计算密集型，批处理计算，我正在做很多100000次查询，我对查询时间不满意。我觉得我肯定在滥用Lucene，所以我正在开发第二个基于Berkeley DB的实现，这样我就可以对两者进行并排比较。如果我有机会在这里发布结果，我会这样做。

但是，我的数据要求远远大于你的数据要求。 3GB，超过我的可用内存。因此，我使用的Lucene索引是在磁盘上，但是使用Lucene，您可以使用“RAMDirectory”索引，在这种情况下，整个内容将存储在内存中，这可能非常适合您的需求。

Answer 4

如果我错了，请纠正我，但由于每个节点都是链接节点的列表，在我看来，具有模式的数据库更多的是负担而不是优势。 这听起来像Google App Engine就在你的小巷里：

• 它针对阅读进行了优化 - 如果你想要更快的话，那就是memcached
• 它是分布式的 - 所以尺寸不影响效率

当然，如果你以某种方式依赖Relational DB来查找路径，那么它对你不起作用......

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

Answer 5

因此，您有一个图表作为您的数据，并希望执行经典的图形操作。我无法看到其他技术比图形数据库更适合。