Graph 图形数据库是否比键val存储更适合存储树？

我的应用程序数据由一棵巨树组成，它随着用户与系统的交互而增长。图形数据库是否比关键val存储更适合存储大树？可伸缩性的损失（因为图形数据库通常更难切分）是否由其他特性补偿

视情况而定

如果您使用键值存储，我会想象您会对子节点进行大量查找，这可能是一个很长的列表，因此您的键将是父节点，而您的值将是子节点，并且您可能会对表进行大量移动和查询。这通常是关系数据库中的问题，这些类型的表联接

图形数据库非常好，因为您不进行连接，而是进行遍历，因此您可以从根开始，指定深度或结束条件，然后让图形遍历使用传出关系来获得最终结果

我同意您的观点，切分对于图形数据库不是一个好的选择，至少在跨存储关系遍历的意义上不是这样。但我相信，通过对数据进行适当的建模，这不应该是一个问题，至少如果图形数据库是智能的，就不会是问题

---

Neo4j对于密集节点有一个问题，其中具有许多（500k+）关系的节点可能会导致遍历速度减慢，但是您可以使用索引来解决这个问题。除此之外，它对大数据非常有用，因为它在磁盘上的存储效率很高，而且遍历速度非常快

定义“巨大”。如果您能够适应Neo4J的限制/限制，或者拥有一个自然的逻辑切分模型，那么Neo4J将是一种更干净/更简单/更强大的方法，并且需要的代码将少得多。正如Nicholas所说，如果您的数据库将有很多“热点”节点（许多关系），那么您可能会遇到一些挑战w/Neo4J，尽管通常可以使用一些应用程序设计方法来克服这一限制。

@Viclib也许看看Titan而不是Neo4J会有所帮助。它着重于使用诸如HBase或Cassandra之类的后端存储进行切分。是的，这将是一种替代方案，尽管我只精通Neo4j。Titan是否通过键/值配对进行节点/关系连接？也从未使用过。我知道节点基本上是K/V的集合，但不确定关系。当查看文档时，情况似乎是这样的：“每个边都有一个由从键到值的映射定义的属性集合。”我很惊讶没有人提到像Mongo DB这样的文档数据库。或者这只是一种键值存储？根据我的经验，文档数据库不是存储树的答案，因为如果不将整个文档树读入内存，就无法访问内部节点。我希望有一天会有人提出一个NoSQL树数据库。