有人可以解释文档数据库如何作为图形数据库工作吗？
ArangoDB 和 Neo4j 有什么区别？
最佳答案
免责声明:我是来自 ArangoDB 的 Max，核心开发人员之一。
首先，可以在我的文章 Graphs in data modeling - is the emperor naked? 中找到对此和其他相关问题的更长讨论。 ，但我将尝试在这里简洁地回答这两个问题。
(1) 在文档存储中存储图相对容易(就像在关系数据库中一样)，例如，可以简单地将每个顶点的文档存储在“顶点集合”中，并将每个边的文档存储在“边缘收集”。只需要确保每条边存储它来自哪个顶点以及它去哪个顶点。在 ArangoDB 中，我们为此使用边缘文档中的 _from 和 _to 属性。
然而，图数据库的关键能力是它需要有效地回答有关图的查询。图的典型查询是(a)“图中顶点的邻居是什么？”或 (b) “图中从顶点 A 到顶点 B 的最短路径是什么？”或(c)“给我我可以通过跟随边从顶点 A 到达的所有顶点”。而 (a) 只需要在边集合上有一个好的索引，(b) 和 (c) 涉及图中先验未知的步骤数。因此，(b) 和 (c) 不能用像 SQL 这样的传统数据库查询语言有效地完成，仅仅因为它们会涉及客户端和服务器之间的大量通信，或者至少是一个非常复杂的具有可变数量的表达式加入。因此，我将诸如 (b) 和 (c) 之类的查询称为“图形”，但并未对其进行严格定义。
因此，我对“文档存储如何成为图形数据库”的简短回答。 is:将图存储如上，并在数据库服务器中实现图查询，可通过数据存储的查询语言访问。原则上，同样可以用关系数据库和 SQL 的一些相当大的扩展来完成。
使用 ArangoDB，我们设法将文档、图形和键/值特征组合成一个单一的、连贯的查询语言。因此我们称 ArangoDB 为“多模型数据库”，因为它无缝地结合了这三种数据模型。您甚至可以在单个查询中混合数据模型!
这引出了我对问题(2)的回答，这显然有点偏颇:
与上述意义上的分布式多模型数据库 ArangoDB 相比，Neo4j 是一个经典的图数据库。它存储图形，允许使用“图形查询”查询它们，并具有为此优化的存储和查询引擎。 Neo4j 特别擅长使用其内置的查询语言密码匹配路径。它确实允许将属性附加到顶点和边，但它不是一个功能齐全的文档存储。它没有针对使用多个二级索引处理文档查询进行优化，也没有进行连接。此外，Neo4j 不是分布式的。
Neo4j 是用 Java 编写的，ArangoDB 是用 C++ 编写的，并且嵌入了谷歌的 V8 来执行 JavaScript 扩展。
有关性能比较，请参阅 this post .
关于neo4j - ArangoDB 文档数据库和图形数据库？这怎么可能？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/30851112/