graph - 图数据库比 key-val 存储更适合存储树吗？

Question

我的应用程序数据由一个巨大的树组成，随着用户与系统的交互而增长。图数据库比 key-val 存储更适合存储大树吗？可扩展性的损失（因为事实图数据库通常更难分片）是否被其他功能补偿？

Answer 1

这取决于。

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

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

我同意你的观点，分片对于图数据库来说不是一个好的选择，至少在跨存储关系遍历的意义上不是。但是我相信通过对数据进行适当的建模，这应该不是问题，至少在图形数据库很智能的情况下不会。

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

Answer 2

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