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

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

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

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

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

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

来源

2009-12-22 asmaier

“对于图表上的简单搜索，这些GraphDB看起来太复杂了。”不知道这是什么意思。除了图形以外的任何东西存储图形都会增加复杂性。 – sevenforce 2014-10-17 18:52:02

LinkedIn必须管理一个相当大的图。在他们的体系结构上检查出this info可能是有益的。特别要注意他们如何将整个图形缓存在内存中。

来源

2009-12-22 11:40:46

我有一个有向图，我（错）使用Lucene。

每条边都作为文档存储，其中节点为文档的字段，然后我可以搜索。

它的表现已经足够好了，并且查询时间用于从节点获取入站和出站链接对于将其用作基于Web的工具的用户来说是可接受的。但是对于计算密集型的批量计算，我正在做很多100000次查询，我不满意查询时间。我明白我绝对会滥用Lucene，因此我正在开发第二个基于Berkeley DB的实现，以便我可以对两者进行并排比较。如果我有机会在这里发布结果，我会做。

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

来源

2009-12-22 12:09:04 Joel

创造性的解决方案，但不会边缘的关系数据库一样好？或者我错过了使用lucene获得的一些免费功能？ – drxzcl 2009-12-22 15:24:54

是的，它可能会。我之所以使用Lucene是因为我当时已经在使用Lucene，并且我想要一个完全可以在我的应用程序（如bdb）中运行的独立的，可移植的解决方案。 – Joel 2009-12-22 16:38:45

纠正我，如果我错了，但由于每个节点都是链接节点的列表，在我看来，具有模式的数据库比负载更重要。它还听起来像谷歌应用程序引擎将是对你的胡同：

它优化用于读取 - 如果你希望它更快
它的分布还有的memcached的 - 这样的大小不会影响效率

当然，如果你以某种方式依赖于关系数据库寻找路径，它不会为你工作...

我只是注意到，q是4个月大

来源

2010-04-24 21:58:55 Nick

也有OrientDB一个开放源码的文件图形DBMS与商业友好许可证（Apache 2）。简单的API，SQL语言，ACID Transactions和Gremlin图形语言的支持。

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

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

要返回至少有一个居住在新西兰的朋友的所有帐户。而对于朋友则意味着递归到深度的第七层。

来源

2010-09-23 09:54:18 Lvca

所以你有一个图形作为你的数据，并希望执行一个经典的图形操作。我看不出其他什么技术比图形数据库更适合。

来源

2014-10-17 18:57:23 sevenforce

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

回答

相关问题