计划中的 MongoDB SHARDING_FILTER

Question

我在 Sharded Cluster 上有问题。我正在测试性能以比较 Sharded 和 Replica Set。

我在没有mongos的情况下直接向Shard 1插入数据，然后通过聚合查询查询它，但我找不到它。我检查了解释计划，该计划在主分片的阶段显示“SHARDING_FILTER”，但在我检查解释计划时在辅助分片中没有。

控制它的配置是什么？

MongoDB 版本:3.0.12

Answer 1

I have inserted data to Shard 1 directly without mongos and then query it by aggregate query but I cannot found it.

尚不完全清楚您的性能比较是什么，但无论如何您都应该始终通过 mongos 与分片集群的数据进行交互。

mongos 的作用包括跟踪分片集群元数据(从配置服务器缓存)、观察数据插入/更新/删除和路由请求。绕过 mongos 将导致收集/数据可见性的潜在复杂化(正如您所观察到的)，因为您将跳过一些用于分片部署的预期数据管理基础设施。

I checked in explain plan that shows "SHARDING_FILTER" in stage on Primary shard but doesn't have that in Secondary when I checked explain plan.

次级读取最终是一致的，因此给定次级上的数据状态可能不一定与当前的分片集群元数据匹配。对于许多分片来说，这变得更加成问题:具有辅助读取首选项的结果可能会从具有显着复制滞后差异的辅助数据中组合出来。

对于分片集群的一致查询，您应该始终通过 mongos 使用主要读取(这是默认行为)。通过 mongos 对初选的查询可能包括一个 SHARDING_FILTER 阶段，该阶段过滤不属于当前分片的结果文档(例如，由于正在进行的迁移，其中文档需要暂时存在于捐赠者和目标分片上)。

在 MongoDB 3.4 中，辅助节点没有过滤结果的能力，因为它们需要维护一个单独的集群元数据 View ，以匹配它们的最终一致状态。有一个相关的 Jira 问题需要关注/投票:SERVER-5931 - Secondary reads in sharded clusters need stronger consistency .如果没有仔细考虑最终一致性对您的用例的影响，我目前不建议在分片集群(或一般情况下)中进行二次读取。一般情况请阅读Can I use more replica nodes to scale? .

What's configuration to control about it?

使用默认的read preference (primary 读取)并始终通过 mongos 与您的分片部署进行交互。