DDS數據庫均衡慢問題

用戶在擴容添加一個shard節(jié)點后，balance線程檢測到新的shard節(jié)點后，開始執(zhí)行均衡策略，通過執(zhí)行movechunk命令將其他shard上的一些chunk遷移到新的shard上，進行負載均衡，但是用戶發(fā)現，執(zhí)行movechunk的速度特別慢，一個chunk的遷移需要5分鐘左右。

經過對movechunk命令的分析，簡單講，該過程相當于把源shard上制定chunk的數據插入到新的shard下，影響插入過程的一般有索引，以及其他插入操作；

通過分析用戶表的索引和業(yè)務，發(fā)現用戶在某個表上有很多索引；同時，在balance時業(yè)務是不中斷的，因此我們模擬了類似的業(yè)務模型，驗證發(fā)現

1.索引對movechunk命令執(zhí)行速度有很大的影響，一般一個表上創(chuàng)建有5個以上索引，就會明顯影響movechunk的速度；

2.業(yè)務的讀寫也對movechunk命令有影響，如果chunk上有游標，則movechunk命令會等待游標結束才開始執(zhí)行，但是這個影響不是很明顯；

分析了以上原因后，根據用戶的業(yè)務，對用戶的索引進行了優(yōu)化，刪除了不必要的索引

用戶在均衡完成后發(fā)現，shard的磁盤使用率并沒有降低。

這是因為mongodb默認，不會把已申請到的磁盤空間返還給操作系統(tǒng)，因此磁盤的使用率沒有降低，但是mongodb會重新利用磁盤里的空間，也就是說，繼續(xù)插入數據時，mongodb首先使用它自己已經申請的磁盤，因此這個問題影響不大，不會造成磁盤空間浪費；

MongoDB 文檔數據庫服務 DDS

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發(fā)現本站中有涉嫌抄襲或描述失實的內容，請聯(lián)系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。