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

測試配置

• mongos x 2、shard x 3
• 測試1：集合不開啟分片，批量 insert 導入數(shù)據(jù)，每個 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的擴展能力如何體現(xiàn)？

結果分析

這里核心的問題在于 batch insert 在 mongos 和 mongod 上處理行為的差別

導入數(shù)據(jù)時，一次 insert 一條數(shù)據(jù)，和一次 insert 100 條數(shù)據(jù)，性能差距是很大的；首先減少了client、server 端之間的網(wǎng)絡交互；同時 server 可以將 batch insert 放到一個事務里，降低開銷；

mongos 在收到 batch insert 時，因為一個 batch 里的數(shù)據(jù)需要根據(jù) shardKey 分布到不同的shard，所以一個 batch 實際上需要被拆開的；這里 mongos 也做了優(yōu)化，會盡量將連續(xù)的分布在一個shard上的文檔做 batch 發(fā)到后端 shard。

在集合不開啟分片的情況，mongos 收到的 batch 肯定是轉發(fā)給 primary shard，所以轉發(fā)過去還是一整個 batch 操作； 而在集合開啟分片的情況下，因為用戶測試時，shardKey 是隨機生成的，基本上整個 batch 被打散成單條操作，逐個往后端 shard 上發(fā)送，請求到后端 shard 基本已經(jīng)完全沒有合并了。

所以在上述測試中，不分片的單個 shard 6w qps、與分片后每個 shard 2.4w qps，實際上就是請求是否 batch 執(zhí)行的差別。

對應用的影響

從上面的分析可以看出，batch 往分片的集合寫入時，因為無法預知數(shù)據(jù)應該分散到哪個分片，實際上往后端 shard 寫入時，會失去 batch 的效果，但這個批量導入一般發(fā)生在數(shù)據(jù)導入階段，影響比較小。

原文鏈接
本文為云棲社區(qū)原創(chuàng)內容，未經(jīng)允許不得轉載。

總結

以上是生活随笔為你收集整理的MongoDB sharding 集合不分片性能更高？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內容還不錯，歡迎將生活随笔推薦給好友。