計劃中的MongoDB SHARDING_FILTER

Question

我在Sharded Cluster上遇到問題。我正在測試性能以在Sharded和Replica Set之間進行比較。

我已經將數據直接插入碎片1而沒有mongos，然後通過聚合查詢來查詢它，但是我找不到它。我檢查瞭解釋計劃，該計劃在主要分部的舞臺上顯示「SHARDING_FILTER」，但在檢查解釋計劃時沒有在中學進行。

什麼是配置來控制它？

MongoDB的版本：3.0.12

Answer 1

我已經插入的數據直接碎片1無mongos然後彙總查詢查詢，但我不能找到它。

這並不完全清楚您的性能對比是什麼，但無論您應該總是通過mongos與分片羣集交互數據。

mongos的作用包括跟蹤分片羣集元數據（從配置服務器緩存），觀察數據插入/更新/刪除和路由請求。繞過mongos將導致收集/數據可見性方面的潛在複雜性（如您所觀察到的），因爲您正在跳過用於分片部署的一些預期的數據管理基礎架構。

我檢查瞭解釋計劃，顯示「SHARDING_FILTER」在舞臺上的主要分片，但沒有在輔助時，當我檢查解釋計劃。

次級讀取最終是一致的，因此給定次級數據的狀態可能不一定匹配當前的分片羣集元數據。對於許多碎片，這會變得更加成問題：對於次要讀取偏好結果，可能會與次要結合，複製滯後存在顯着差異。

對於分片羣集的一致查詢，您應始終使用mongos的主讀取（這是默認行爲）。通過mongos對初選進行的查詢可能包括SHARDING_FILTER階段，該階段過濾不屬於當前分片的結果文檔（例如，由於正在進行遷移，文檔需要在捐助者和目標分片上暫時存在）。

與在MongoDB 3.4中一樣，次級沒有過濾結果的能力，因爲他們需要維護與最終一致狀態相匹配的集羣元數據的單獨視圖。有一個相關的Jira問題來觀看/ upvote：SERVER-5931 - Secondary reads in sharded clusters need stronger consistency。如果沒有仔細考慮最終一致性對您的用例的影響，我目前不會推薦分片羣集（或一般情況下）的二級讀取。一般情況下，請閱讀Can I use more replica nodes to scale?。

什麼是配置來控制它？

使用默認read preference（primary讀取），並通過mongos與碎片化的部署始終交互。