为什么大多数NoSQL数据库管理系统没有“指针”？

Question

为什么大多数NoSQL数据库管理系统没有“指针”？

mongodbneo4jorientdbgraph-databasesdatabase

5

为什么大多数NoSQL存储解决方案都没有像传统RDBMS一样的超高效联接“指针”？

我知道，传统关系型数据库管理系统已放弃使用指针（需要更新它们并为内存和磁盘进行双重同步，没有足够快速的“磁盘”可用于某些用例，例如现代SSD可以），这部分原因很容易理解。

但是，在众多的NoSQL解决方案中，为什么只有极少数的解决方案意识到这种模式对于许多实际情况（不仅限于需要图遍历的方案）会非常有用呢？我的意思是，当你需要像多重联接这样的操作时，你需要在Mongo之间来回跳跃并执行N个查询来代替一个。

难道NoSQL文档数据库的使用场景与图形数据库的使用场景不重叠吗？这种功能不仅有意义，而且还可以为NoSQL解决方案提供所有SQL联接的实际功能，成本不高，并且对于大多数查询来说会使索引变得无用，并且占用较小的存储空间。

作为额外的好处，任何NoSQL解决方案都可以作为图形数据库使用，将存储在Mongo中的图形进行~100节点路径长度遍历就像自动快速工作一样。

- NeuronQ

为什么不使用图形数据库进行高效连接？您不需要拥有复杂的图形模型来使用图形数据库。 - Brian Underwood

@BrianUnderwood 我的问题实际上有点相反：为什么要使用除图形数据库之外的任何东西，为什么其他NoSQL DB（我认为图形数据库是NoSQL家族的一部分）甚至存在？...因为在所有实际目的中，您迟早会需要n级联接...如果您放弃关系世界观，那么为什么不只是拥有某种“指针”机制来进行这些连接呢？ - NeuronQ

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- mnemosyn · Accepted Answer

我认为关键问题是数据本地化和水平可扩展性。 NoSQL 的前提是 RBDMS 的读重模型，即需要连接的模型会导致瓶颈。

以 Twitter 为例：最初的数据模型是读重型的，但你需要进行的连接非常庞大（数十亿条推文 x 数亿用户 x 数百亿个关注者-被关注者关系，这些关系大小变化极大[1-10M，或者像 aplusk 这些天一样]）。

当你想要连接的 id 甚至无法容纳在合理的机器 RAM 中时，计算 id 的重叠变得非常昂贵。如果考虑实际数据，水平可扩展性几乎不可能，因为没有先验知识哪些分片/机器将需要访问。在每个关注者列表中存储所有关注者指针将需要进行繁琐的记账，而且不能利用创建时间本地性（或至少是每个 feed 的创建时间本地性）。

在多租户应用程序中，你可以根据租户、销售区域、代理商甚至时间进行分片：你可以找到某些适用于 >95% 的情况的本地性标准。

使用图形，特别是那些具有某些连接属性的图形（具有小直径/小世界现象的无标度网络）变得更加复杂：一个简单的帖子，比如名人发布的帖子，可以很快地在整个网络的大部分传播，这意味着几乎每个查询都必须命中保存帖子的一个节点。当然，帖子本身将被Web服务器缓存，但是如果添加了喜欢和评论、收藏和转发等内容，则故事就会变成一场噩梦（写作！）。再加上通知电子邮件、内容排名和过滤，你就真正进入了恐怖之境。

在Mongo中执行100个节点路径长度遍历只需自动快速工作

如果这些数据恰好位于100个不同的节点上，则即使在没有拥塞和空闲机器的单个数据中心中，纯粹的网络开销也将在50ms范围内。如果这种情况扩散到全球或者查询需要更长时间，你很快就会达到5000ms。此外，如果只有一台机器宕机，查询就会失败。这太过依赖于网络的细节，这就是为什么问题应该由应用程序代码而不是数据存储解决的原因。

当你需要像多重连接这样的东西时，你需要在Mongo中来回跳动并执行N个查询，而不是一个。

当你需要在MongoDB中进行多重连接时，你可能在使用错误的数据模型或工具。多重连接意味着规范化，意味着读取密集，这与MongoDB的关键概念相冲突。然而，即使在MongoDB中，你也可以存储相当大的联合列表。但是，在这里技术几乎变得无关紧要：例如，如果你看看Facebook TAO，那么技术依赖性很小。