为什么大多数 NoSQL DBMS 没有“指针”？

Question

为什么大多数 NoSQL 存储解决方案没有某种用于超高效连接的“指针”，如关系前 DBMS 所具有的客观原因是什么？

我的意思是，我部分理解了为什么经典 RDBMS 放弃指针的理论原因（需要更新它们并对内存和磁盘进行双重同步，没有足够快的“磁盘”可以像某些用例的随机访问一样处理，例如现代SSD 可以等）。

但是在众多 NoSQL 解决方案中，为什么只有很少一部分人意识到这个模型对于许多实际案例来说非常棒（我知道 OrientDB 和 Neo4j 除外），而不仅仅是那些需要图遍历的案例。我的意思是，当您需要诸如多连接之类的事情时，您需要 ping pong Mongo 并执行 N 个查询而不是一个。

NoSQL 文档数据库的用例是否与图形数据库之一重叠得足够多，这样的功能是否有意义，并且只会在没有太多额外成本的情况下向 NoSQL 解决方案提供 SQL 连接的所有实用功能，并且对于大多数查询会使索引无用，并且占用大量数据集的空间要少得多？

（...作为奖励，任何 NoSQL 解决方案都可以用作图形数据库，并且对存储在 Mongo 中的图形进行约 100 个节点的路径长度遍历会自动足够快地工作）

Answer 1

我认为关键问题是数据局部性和水平可扩展性。NoSQL 的一个前提是 RBDMS 的读取密集型模型（即需要连接的模型）会导致瓶颈。

想想 Twitter：原始数据模型需要大量读取，但您需要进行的连接非常大（数十亿条推文 x 数亿用户 x 数百亿关注者-关注者关系，其大小差异很大 [1 -10M，或者 aplusk 现在拥有的任何东西]）。

当您想要加入的 id 无法容纳在合理的机器 RAM 中时，计算 ids 的重叠就会变得非常昂贵。如果考虑实际数据，水平可扩展性几乎是不可能的，因为没有先验知识哪些分片/机器需要受到攻击。将所有关注者指针存储在每个关注者列表中将需要疯狂的簿记来进行琐碎的更改，同时不利用创建时局部性（或至少每个提要的创建时局部性）。

在多租户应用程序中，您始终可以按租户、销售区域、代理商甚至时间进行分片：您可以​​找到一些适用于 > 95% 的情况的局部性标准。

对于图表，这变得更加复杂，尤其是那些具有某些连接属性的图表（具有小直径/小世界现象的无标度网络）：一个简单的帖子，例如名人的帖子，可以快速传播到整个网络的很大一部分网络，这意味着几乎每个查询都必须命中担任该职位的一个节点。

当然，帖子本身会被网络服务器缓存，但添加点赞和评论，或者收藏和转发，故事就会变成一场噩梦（写！）添加通知电子邮件、内容排名和过滤，你就会感到真正的恐惧。

对存储在 Mongo 中的图进行约 100 个节点的路径长度遍历会自动足够快

如果该数据恰好位于 100 个不同的节点上，则即使在没有拥塞和空闲机器的单个数据中心中，纯粹的网络开销也将在 50 毫秒范围内。如果这种情况蔓延到世界各地，或者单个查询需要更长的时间，您很快就会达到 5000 毫秒。此外，如果只有一台机器宕机，查询就会失败。

这在很大程度上取决于网络的细节，这就是为什么问题应该由应用程序代码而不是数据存储来解决。

当你需要诸如多连接之类的东西时，你需要 ping pong Mongo 并执行 N 个查询而不是一个

当您需要在 MongoDB 中进行多重联接时，您正在为数据模型使用错误的工具，反之亦然。多连接意味着规范化意味着大量读取，这与 MongoDB 的关键概念相悖。但是，即使在 MongoDB 中，您也可以存储相当大的关联列表。但这个工具在这里几乎变得无关紧要：例如，如果你看一下Facebook TAO，就会发现其中几乎没有技术依赖。