我的应用程序数据由一棵随着用户与系统交互而增长的巨大树组成。图数据库比 key-val 存储更适合存储大树吗？可扩展性的损失（因为事实图数据库通常更难分片）是否被其他功能补偿？
【问题讨论】：
标签： graph nosql neo4j scalability graph-databases
定义“巨大”。如果您可以适应 Neo4J 的范围/限制，或者拥有自然且合乎逻辑的分片模型，Neo4J 将是一种更清洁/更简单/更强大的方法，并且需要更少的代码。正如 Nicholas 所说，如果您的数据库将有很多“热点”节点（很多关系），那么您可能会在使用 Neo4J 时遇到一些挑战，尽管您通常可以使用一些应用程序设计方法来解决这个限制。
【讨论】：
这取决于。
如果你使用键值存储，我想你会为孩子做很多查找，这可能是一个很长的列表，所以你的键是父节点，你的价值是孩子，你最终可能会导致表的大量移动和查询。这通常是您在关系数据库（这些类型的表连接）中遇到的问题。
图数据库很棒，因为您不进行连接，而是进行遍历，因此您将从根开始，并指定深度或结束条件，然后您可以让图遍历使用传出关系将您带到您的最终结果。
我同意你的观点，分片对于图数据库来说不是一个好的选择，至少在跨存储关系遍历的意义上不是。但是我相信通过对数据进行适当的建模，这应该不是问题，至少在图形数据库很智能的情况下不会。
Neo4j 存在密集节点的问题，其中具有许多 (500k+) 关系的节点可能会导致遍历速度变慢，但您可以使用索引来解决此问题。除此之外，它非常适合大数据，因为它在磁盘上的存储效率很高，而且它的遍历速度非常快。
【讨论】：