图表数据库是否比key-val商店更适合存储树木？

Question

我的应用程序数据包含一个巨大的树，随着用户与系统交互而增长。图表数据库是否比key-val商店更适合存储大树？可伸缩性的损失（对于事实图dbs通常更难分片）是否会被其他功能补偿？

Answer 1

这取决于。

如果你使用一个键值存储，我会想你会为子节点做很多查找，这可能是一个很长的列表，所以你的键是父节点，你的值是孩子，你和你最终会有很多动作和查询表。这通常是关系数据库中存在的问题，这些类型的表连接。

图形数据库很棒，因为你不进行连接，但是遍历，所以你要从根开始，指定深度或结束条件，然后你可以让图遍历使用传出关系来引导你最终结果。

我同意你的意见，分片不是图形数据库的好选择，至少不是跨店关系遍历的意义。但我相信通过对数据进行适当的建模，这应该不是问题，至少在图形数据库是智能的时候不是。

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

Answer 2

定义“巨大”。如果你能够适应Neo4J的限制或限制，或者拥有自然和逻辑的分片模型，Neo4J将是一个更清洁/更简单/更强大的方法，并且需要更少的代码。正如尼古拉斯所说，如果你的数据库有很多“热点”节点（许多关系），你可能会遇到一些Neo4J的挑战，尽管通常有一些应用程序设计方法可以用来解决这个限制。