今天接到乙個使用者反饋的問題，sharding集群，使用wiredtiger引擎，某個db下集合全部用的hash分片，show dbs發現其中乙個shard裡該db的大小，跟其他的集合差別很大，其他基本在60g左右，而這個shard在200g左右？
由於這個db下有大量的集合及索引，一眼也看不出問題，寫了個指令碼分析了一下，得到如下結論
somedb 下所有集合都是hash分片，並且chunk的分布是比較均勻的
show dbs 反應的是集合及索引對應的物理檔案大小
集合的資料在各個shard上邏輯總大小是接近的，只有shard0占用的物理空間比其他大很多
從shard0上能找到大量 movechunk 的記錄，猜測應該是集合的資料在沒有開啟分片的情況下寫到shard0了，然後開啟分片後，從shard0遷移到其他shard了，跟使用者確認的確有一批集合是最開始沒有分片。
所以這個問題就轉換成了，為什麼複製集裡集合的邏輯空間與物理空間不一致？即collection stat 裡size與storagesize的區別。
mymongo:primary> db.coll.stats()
儲存引擎儲存時，需要記錄一些額外的元資料資訊，這會導致物理空間總和比邏輯空間略大
儲存引擎可能支援資料壓縮，邏輯的資料塊儲存到磁碟時，經過壓縮可能比邏輯資料小很多了（具體要看資料的特性，極端情況下壓縮後資料變大也是有可能的）
而上述case裡，集合資料先分到乙個shard，然後啟用分片後，遷移一部分到其他shard，就是乙個典型的產生大量儲存碎片的例子。儲存碎片對服務通常影響不大，但如果因為空間不夠用了需要**，如何去強制的**這些碎片空間？
2017-08-03 15:42:04 update
關於 compact操作，有同學問道，問題鏈結
mongdb中由於刪除了大量的資料，但是沒有釋放磁碟空間給系統，想通過compact命令來釋放磁碟空間；但是對compact命令有幾個疑問
compact命令在wiredtiger引擎上是庫級別鎖還是collection級別鎖？
執行compact命令需要多大的空餘磁碟空間呢
MongoDB雜湊分片為什麼分布不均勻？
今天接到乙個使用者反饋的問題，sharding集群，使用wiredtiger引擎，某個db下集合全部用的hash分片，show dbs發現其中乙個shard裡該db的大小，跟其他的集合差別很大，其他基本在60g左右，而這個shard在200g左右？由於這個db下有大量的集合及索引，一眼也看不出問題，...
為什麼 MongoDB 連線數被用滿了？
使用 mongodb 時，可能會遇到因為 mongod 連線數用滿了，導致客戶端無法連線的問題。mongod的最大連線數通過net.maxincomingconnections指定，預設值為1000000，相當於沒有限制，生產環境強烈建議根據實際需求配置，以避免客戶端誤用導致 mongod 負載過高...
為什麼會出現hash雜湊雜湊
如何理解hash 又名雜湊，或者雜湊 實現hash的資料結構示意圖 由圖可知，雜湊表其實就是乙個一維陣列，而陣列中的每乙個元素都是乙個單向鍊錶而已。這樣的資料結構解決了陣列的增刪元素的不足和鍊錶的查詢效率的不足。雜湊原理 通過雜湊演算法 md4 md5 sha1 將任意長度的資料對映成固定長度，較少...