MongoDB sharding 集合不分片性能更高？

最近雲上用戶用戶遇到一個 sharding 集羣性能問題的疑惑，比較有表明性，簡單分享一下

測試配置

• mongos x 二、shard x 3
• 測試1：集合不開啓分片，批量 insert 導入數據，每一個 batch 100 個文檔
• 測試2：集合開啓分片，隨機生成 shardKey，chunk 已提早 split 好，能確保寫入均分到3個shard

測試結果

• 測試1：單個 shard cpu 跑滿，insert qps 在 6w 左右
• 測試2：3個 shard cpu 跑滿，insert qps 在 7w 左右（平均每一個分片2.4w左右）

注：兩個測試裏，mongos 都不是瓶頸，能力足夠

從測試結果看，每一個shard都承擔 1/3 的負載，的確達到橫向擴張的目的，但爲啥分片以後，單個shard的能力就降低了呢？若是是這樣，sharding的擴展能力如何體現？

結果分析

這裏核心的問題在於 batch insert 在 mongos 和 mongod 上處理行爲的差異

1. 導入數據時，一次 insert 一條數據，和一次 insert 100 條數據，性能差距是很大的；首先減小了client、server 端之間的網絡交互；同時 server 能夠將 batch insert 放到一個事務裏，下降開銷；
2. mongos 在收到 batch insert 時，由於一個 batch 裏的數據須要根據 shardKey 分佈到不一樣的shard，因此一個 batch 實際上須要被拆開的；這裏 mongos 也作了優化，會盡可能將連續的分佈在一個shard上的文檔作 batch 發到後端 shard。
3. 在集合不開啓分片的狀況，mongos 收到的 batch 確定是轉發給 primary shard，因此轉發過去仍是一整個 batch 操做； 而在集合開啓分片的狀況下，由於用戶測試時，shardKey 是隨機生成的，基本上整個 batch 被打散成單條操做，逐個日後端 shard 上發送，請求到後端 shard 基本已經徹底沒有合併了。

因此在上述測試中，不分片的單個 shard 6w qps、與分片後每一個 shard 2.4w qps，實際上就是請求是否 batch 執行的差異。

對應用的影響

從上面的分析能夠看出，batch 往分片的集合寫入時，由於沒法預知數據應該分散到哪一個分片，實際上日後端 shard 寫入時，會失去 batch 的效果，但這個批量導入通常發生在數據導入階段，影響比較小。

原文連接
本文爲雲棲社區原創內容，未經容許不得轉載。