今天接到乙個使用者反饋的問題，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，就是乙個典型的產生大量儲存碎片的例子。儲存碎片對服務通常影響不大，但如果因為空間不夠用了需要**，如何去強制的**這些碎片空間？
MongoDB 雜湊分片為什麼資料大小不均勻？
今天接到乙個使用者反饋的問題，sharding集群，使用wiredtiger引擎，某個db下集合全部用的hash分片，show dbs發現其中乙個shard裡該db的大小，跟其他的集合差別很大，其他基本在60g左右，而這個shard在200g左右？由於這個db下有大量的集合及索引，一眼也看不出問題，...
mongodb 5 分片集群
分片集群是指將資料橫向拆分，將乙個資料伺服器上將資料依據一定的規則分散到多台伺服器上。以降低單台伺服器的訪問壓力，提高資料服務的效能。幾乎所有的資料庫系統都能夠手動進行分片，但是這在路由管理上，以及各個分片的管理上都相對困難。mongodb支援自動分片，就可以擺脫手動分片管理困難的問題。集群自動切分...
為什麼會出現hash雜湊雜湊
如何理解hash 又名雜湊，或者雜湊 實現hash的資料結構示意圖 由圖可知，雜湊表其實就是乙個一維陣列，而陣列中的每乙個元素都是乙個單向鍊錶而已。這樣的資料結構解決了陣列的增刪元素的不足和鍊錶的查詢效率的不足。雜湊原理 通過雜湊演算法 md4 md5 sha1 將任意長度的資料對映成固定長度，較少...