最近云上用戶用戶遇到一個(gè) sharding 集群性能問(wèn)題的疑惑，比較有代表性，簡(jiǎn)單分享一下

測(cè)試配置

• mongos x 2、shard x 3
• 測(cè)試1：集合不開啟分片，批量 insert 導(dǎo)入數(shù)據(jù)，每個(gè) batch 100 個(gè)文檔
• 測(cè)試2：集合開啟分片，隨機(jī)生成 shardKey，chunk 已提前 split 好，能確保寫入均分到3個(gè)shard

測(cè)試結(jié)果

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

注：兩個(gè)測(cè)試?yán)?#xff0c;mongos 都不是瓶頸，能力足夠

從測(cè)試結(jié)果看，每個(gè)shard都承擔(dān) 1/3 的負(fù)載，的確達(dá)到橫向擴(kuò)張的目的，但為啥分片之后，單個(gè)shard的能力就下降了呢？如果是這樣，sharding的擴(kuò)展能力如何體現(xiàn)？

結(jié)果分析

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

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

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

在集合不開啟分片的情況，mongos 收到的 batch 肯定是轉(zhuǎn)發(fā)給 primary shard，所以轉(zhuǎn)發(fā)過(guò)去還是一整個(gè) batch 操作； 而在集合開啟分片的情況下，因?yàn)橛脩魷y(cè)試時(shí)，shardKey 是隨機(jī)生成的，基本上整個(gè) batch 被打散成單條操作，逐個(gè)往后端 shard 上發(fā)送，請(qǐng)求到后端 shard 基本已經(jīng)完全沒(méi)有合并了。

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

對(duì)應(yīng)用的影響

從上面的分析可以看出，batch 往分片的集合寫入時(shí)，因?yàn)闊o(wú)法預(yù)知數(shù)據(jù)應(yīng)該分散到哪個(gè)分片，實(shí)際上往后端 shard 寫入時(shí)，會(huì)失去 batch 的效果，但這個(gè)批量導(dǎo)入一般發(fā)生在數(shù)據(jù)導(dǎo)入階段，影響比較小。

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

總結(jié)

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

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