关于增强MongoDB索引的提案

Question

我们从“Index Cardinality”视频[M101J：MongoDB for Java Developers]中学到的一点是，当一个带有多键索引的文档被移动时，他的所有索引也必须更新，这会产生很大的开销。

我认为有可能以某种方式绕过这个约束。显而易见的解决方案是添加另一个间接层（这是解决计算机科学问题的着名模式:-)）而不是直接从索引引用文档，我们为每个引用该文档并获取索引的文档创建一个实体引用该实体，现在当我们移动文档时，我们只需要修改该实体（实体将永远不会移动，因为它的BSON形状将始终相同）。当然，这个解决方案的问题在于交易空间的性能（索引也会遇到这个问题）。

但所有的希望都没有消失;在MongoDB中，所有文档都有一个不可变的_id字段，该字段会自动编入索引。鉴于所有这些，我们知道如果文档被移动，其关联的_id索引也将被更新，那么为什么不让所有其他索引引用文档的相应_id索引呢？

鉴于此解决方案，文档移动时将唯一更新的索引是_id索引。

我想知道这个解决方案是否可以在MongoDB中实现，或者是否存在一些隐藏的问题会使其变得不切实际？

由于

Answer 1

当我发布与Jira门票相同的问题时，我从“Andy Schwerin”得到的答案：https://jira.mongodb.org/browse/SERVER-12614

Andy Schwerin回答：

• 这是可行的，但它使所有读取访问主索引。因此，如果要读取通过辅助索引找到的文档，则必须使用该_id，然后在主索引中查找该文档以查找当前位置。根据应用程序，这可能是一个很好的权衡或坏的。过去的其他数据库系统在记录的旧位置（有时称为墓碑）中使用特殊标记来指向新位置。这使得您只需在文档移动时支付间接费用，代价是需要定期清理索引，以便您可以垃圾收集旧的逻辑删除。

还要感谢 leif 获取信息链接http://www.tokutek.com/2014/02/the-effects-of-database-heap-storage-choices-in-mongodb/我已经向作者提出了同样的问题，这是他的回答：

Zardosht Kasheff回答：

• 你可以，但是对二级索引的点查询可能会导致三个I / O而不是两个。目前，对于任一方案，对二级索引的点查询可能需要I / O来获取行标识符，而另一个用于检索文档。使用此方案，您需要一个I / O来获取_id，另一个需要获取行标识符，第三个需要获取文档。这似乎是不可取的。