图形数据库是否比keyval存储更适合存储树？

Question

我的应用程序数据包含一个巨大的树，随着用户与系统交互而增长。图形数据库比key-val商店更适合存储大树吗？可扩展性的损失（对于图形dbs通常更难分割）由其他功能补偿？

Answer 1

这要看情况。

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

图形数据库是伟大的，因为你不做连接，但遍历，所以你会开始在根，并指定深度，或结束条件，然后你可以让图遍历使用传出关系，让你你的最终结果。

我同意你的看法分片不是图形数据库一个不错的选择，至少不能跨店关系遍历的感觉。但我相信，对数据进行适当的建模，这应该不成问题，至少在图数据库很聪明的情况下不会有问题。

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

Answer 2

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