具有复合索引的分片群集上的MongoDB Oplog光标

Question

拥有OpLog游标，是否可以在更新操作中获取除默认_id之外的其他索引？

背景

我有一个分片集群，复合索引为分片键。此复合键的一部分用于确定哪组分片用于存储数据（也称为Tag Aware Sharding）

在不同分片的副本集的后台tailing the OpLogs中运行一些NodeJS微服务，以触发对数据更改的进一步处理。现在，如果某些数据得到更新，OpLog中返回的唯一索引是默认的_id，这迫使我 查询整个群集 ，以获取复合索引的第二部分在进一步处理中利用整个分片键。

应用程序非常密集，对每次更新都意味着在整个集群上进行一次额外查询。如果我能在更新操作中获得整个复合索引，我可以避免这个查询。

感谢您的任何意见！

Answer 1

与MongoDB 3.2一样，replication oplog不包含与文档相关的分片键或二级索引的详细信息。 oplog不是为您的用例而设计的;我建议在MongoDB问题跟踪器中观看/ upvoting SERVER-13932: Change Notification Stream API。

  

现在，如果某些数据得到更新，OpLog中返回的唯一索引是默认的_id，这迫使我在整个集群中查询复合索引的第二部分，以便在进一步处理时利用整个分片键。

     

在后台运行一些NodeJS微服务，拖尾不同分片的副本的OpLog，以触发对数据变化的进一步处理。现在，如果某些数据得到更新，OpLog中返回的唯一索引是默认的_id，这迫使我在整个集群中查询复合索引的第二部分，以便在进一步处理时利用整个分片键。

使用分片群集时，您必须在每个分片上拖尾oplog，就像您正在做的那样。但是，对于您的用例，_id和分片键有一个有用的属性：两者都是immutable。

我不确定您的微服务如何配置为聚合更新，但如果您看到插入或更新，并且您想要查找有关该文档的分片键的更多信息，则只需查询一个分片：您刚观察到的那个更新该文档的那个。

所以建议尝试的方法是：

• 在碎片上的oplog尾部发现更新的感兴趣的文档的_id
• 查询文档的本地分片（按_id）以查找分片键字段
• 使用分片键
通过mongos读取/更新文档以进行进一步处理

您应该测试一下，看看这是否会为您的部署带来可衡量的性能差异，但这种方法可以使查询针对单个分片而不是分散/聚集到所有分片。

明显需要注意：除了通过从您在oplog中观察到更新的本地分片中获取文档来发现分片密钥之外，您绝对需要所有查询＆amp;要通过mongos处理分片群集的更新。