首先,在我的文章Graphs in data modeling – is the emperor naked?中可以找到关于这个问题和其他相关问题的更长时间的讨论,但我将在这里简明扼要地回答这两个问题.

(1)在文档存储中存储图形是相对容易的(因为它在关系数据库中),例如,可以简单地在“顶点集合”中存储每个顶点的文档,并且在“顶点集合”中存储每个边缘的文档.边收集”.人们只需要确保每个边缘存储它来自哪个顶点以及它到达哪个顶点.在ArangoDB中,我们在边缘文档中使用_from和_to属性.

但是,图形数据库的关键功能是它需要有效地回答有关图形的查询.图的典型查询是(a)“图中顶点的邻居是什么？”或(b)“图中从顶点A到顶点B的最短路径是什么？”或(c)“给我所有我可以通过跟随边缘从顶点A到达的顶点”.而(a)只需要边缘集合上的良好索引,(b)和(c)涉及图中先验未知数量的步骤.因此,使用传统的数据库查询语言(如sql)无法有效地完成(b)和(c),因为它们会涉及客户端和服务器之间的大量通信,或者至少是一个具有可变数量的非常复杂的表达式.连接.因此,我将(b)和(c)之类的查询称为“图形”,而不是严格定义.

因此,我简单回答“文档存储如何成为图形数据库？” is：如上所示存储图形并在数据库服务器中实现图形查询,可从数据存储的查询语言访问.原则上,可以使用关系数据库和sql的一些可观的扩展来完成相同的操作.

通过ArangoDB,我们设法将文档,图形和键/值功能组合成一个统一的查询语言.因此,我们将ArangoDB称为“多模型数据库”,因为它无缝地组合了这三种数据模型.您甚至可以在单个查询中混合数据模型！

这导致了我对问题(2)的回答,这显然有点偏颇：

与ArangoDB(上述意义上的分布式多模型数据库)相比,Neo4j是一个经典的图形数据库.它存储图形,允许使用“图形查询”查询它们,并具有针对此进行优化的存储和查询引擎. Neo4j特别擅长使用内置查询语言cypher匹配路径.它允许将属性附加到顶点和边缘,但它不是一个功能齐全的文档存储.它没有针对使用多个二级索引处理文档查询进行优化,也没有进行连接.此外,Neo4j未分发.

Neo4j是用Java编写的,ArangoDB是用C语言编写的,嵌入了Google的V8来执行JavaScript扩展.

有关性能比较,请参阅this post.