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

Question

有一个 OpLog 游标，是否有可能在更新操作中获取除默认 _id 之外的另一个索引？

背景:

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

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

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

感谢任何输入!

Answer 1

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

Now if some data gets updated, the only index returned in the OpLog is the default _id, which forces me to query the whole cluster for the second part of the compound index to leverage the whole shard key in further processing.

There are some NodeJS Microservices running in the background tailing the OpLogs of the ReplicaSets of the different shards to trigger further processing on data changes. Now if some data gets updated, the only index returned in the OpLog is the default _id, which forces me to query the whole cluster for the second part of the compound index to leverage the whole shard key in further processing.

对于分片集群，您必须在每个分片上跟踪操作日志，就像您正在做的那样。但是，对于您的用例，_id 和分片键有一个有用的属性:两者都是 immutable .

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

因此建议尝试的方法是:

• oplog 尾随分片发现感兴趣的更新文档的 _id
• 查询文档的本地分片(通过 _id)以找到分片键字段
• 使用片键通过 mongos 读取/更新文档以进行进一步处理

您应该进行测试，看看这是否真的会对您的部署产生可衡量的性能差异，但这种方法将使查询能够针对单个分片，而不是分散/聚集到所有分片。

明显的警告:除了通过从您在操作日志中观察到更新的本地分片中获取文档来欺骗发现分片键之外，您肯定希望分片集群的所有查询和更新通过 mongos 进行处理。