为什么大多数NoSQL存储解决方案都没有某种指针＆＃34;对于超高效的连接，就像前关系型DBMS一样？
我的意思是，我部分理解为什么经典RDBMS抛弃指针的理论原因（需要更新它们并为内存和磁盘双重同步，没有＆＃34;磁盘＆＃34;足够快，可以随意处理 - 访问某些用例，例如现代SSD可以等。）
但是在那里的许多NoSQL解决方案中，为什么很少有人意识到这个模型对于许多实际情况都很棒（我知道将是OrientDB和Neo4j），而不仅仅是那些需要图遍历的模型。我的意思是，当你需要像多连接这样的东西时，你需要ping pong Mongo并进行N次查询而不是一次。
不是NoSQL文档的用例 - 与图形数据库之间足够重叠的数据库，这样的功能是有意义的，并且只是为NoSQL提供SQL连接的所有实用功能没有太多额外成本的解决方案，对于大多数查询而言，索引会变得无用，并且占用大量数据集的空间会少得多？
（...作为奖励，任何NoSQL解决方案都可以作为图形数据库使用，并且对Mongo中存储的图形进行约100个节点的路径长度遍历，只需自动运行得足够快）
答案 0 :(得分：3)
我认为关键问题是数据位置和水平可伸缩性。 NoSQL的一个前提是RBDMS的读取模型，即那些需要连接的模型，会导致瓶颈。
想想Twitter：原始数据模型阅读量很大，但你需要做的联接是非常大的（数十亿条推文x数亿用户x数百亿的跟随者 - 跟随者关系，这些关系在大小[1-10M，或者这些天的任何aplusk]）。
即使您想要加入的ID不适合合理的机器RAM，计算ID的重叠也会变得非常昂贵。如果考虑实际数据，水平可扩展性几乎是不可能的，因为没有先验知识需要击中分片/机器。在每个关注者列表中存储所有关注者指针将需要疯狂记账以进行微不足道的更改，同时不利用创建时间位置（或至少每个订阅源的创建时间位置）。
在多租户应用程序中，您可以随时通过租户，销售区域或代理商或甚至是时间进行分片：您可以找到某些位置标准＆GT; 95％的案例。
使用图形会变得更加复杂，特别是那些具有某些连接属性的网络（具有小直径/小世界现象的无标度网络）：一个简单的帖子，如名人所说，可以快速传播大部分整个网络，意味着几乎每个查询都必须点击保存帖子的一个节点。
当然，帖子本身将由网络服务器缓存，但添加喜欢和评论，或收藏和转推，故事变成一场噩梦（写！）添加通知电子邮件，内容排名和过滤，你在真正的恐怖。
对Mongo中存储的图形进行~100个节点的路径长度遍历，只需自动运行得足够快
如果该数据恰好位于100个不同的节点上，那么纯粹的网络开销将在50毫秒的范围内，即使在没有拥塞和空闲机器的单个数据中心中也是如此。如果这种情况在全球范围内传播，或者个人查询需要更长时间，那么您很快就会达到5000毫秒。此外，如果只有一台计算机关闭，查询将失败。
这在很大程度上取决于网络的细节，这就是问题应该通过应用程序代码而不是数据存储来解决的原因。
当你需要像多连接这样的东西时，你需要ping pong Mongo并做N个查询而不是一个
当您需要MongoDB中的多连接时，您使用了错误的工具来处理数据模型，反之亦然。多连接意味着规范化意味着读取沉重，它与MongoDB的关键概念作斗争。但是，即使在MongoDB中，您也可以store quite large association lists。但是这个工具在这里变得几乎无关紧要了：例如，如果你看一下Facebook TAO,，那里几乎没有技术依赖。