MongoDB Sharding及數據庫設計
2024-07-21 02:53:12
供稿：網友
1、MongoDB Sharding基本共識隨機I/O轉為順序I/O；步驟越少，查詢越簡單，性能越高。多做不如少做，少做不如不做；大數據查詢，分布式并行查詢能力高；三個注意事項插入文檔必須帶上sharding key不接受修改片鍵值（讀取、刪除、插入新文檔）如果文檔中包含不同類型的值，排序規則，按照類型排序，同類型與大家期望相同；ChunkSize選擇默認64M；與線上實際引用有關；Chunk的分裂與遷移非常消耗IO資源；分裂時機（插入更新、更新文檔時，讀數據不會產生分裂）ChunkSize（數據預填充、浪費空間但是只在最初進行分裂，獲取平滑的查改性能）；小的遷移速度塊、分布均勻，但是數據均衡比較頻繁、塊分裂更頻繁、路由節點消耗更多資源定位；優點：塊分裂小、路由定位塊、避免虛假遷移；缺點：遷移時資源消耗比較大，抖動，數據分布不均勻；通常100-200M，不同系統磁盤介質不同（前十幾塊為64M，數據量大時將會變成設置）；Read10；centos，xfsMonogoDB支持修改ChunkSize；請測試確認后再進行調整；線上調整ChunkSize可能會導致災難性I/O；調小可能會引起過多分裂；調大時可能在達到閾值才進行調整；2、MongoDB Sharding存在問題及建議；重要兩點優化均衡器時間mongodb很lazy，但是腦殘；（均衡器執行器的執行過程可能很長，導致影響應用）Balacer設置（問題）count值布準確；唯一值不唯一update更新的記錄數出現問題；0~7點進行均衡，mongos進行設置，使用config表進行設置，$set,$unset;Sharding key選擇指定sharding key；chunk分布不均衡時導致chunk遷移；集群角色Mongos數據讀寫；config保存映射：key-》chunk，chunk-》node；路由節點通過config server獲取數據；路由節點判定是否超過具體大??；分片key路由到update進行操作；按分片查詢進行具體操作；不同分片會分別進行操作，然后進行結果聚合；Sharding key選擇遞增sharding key；數據文件挪動少（優勢）；數據文件遞增所以insert都會會放在最后一個分片，成為熱點；隨著最后的擴大導致分裂；隨機sharding key；數據分布均勻（優勢）；大量的隨機IO，磁盤壓力比較大；混合型sharing key，大范圍遞增key+隨機分布的key；大方向但調增不斷寫入新的文件，盡量不要讓寫放在多個節點上；小方向隨機分布保證數據均勻分布在分片上分攤寫壓力；Sharding key總結單一Sharding key導致分布不均勻，無法充分利用分片性能；使用復合Sharding key，符合Sharding key不可更改，并且在MaPReduce性能消耗；count在chunk移動時計數偏大，務必減少chunk移動；Balance穩定性不夠智能、穩定；Auto-Sharding key并不是很靠譜；3、MongoDB庫設計原則及實踐線上環境禁用Auto-Sharding；開啟庫級分片；特定庫制定到固定分片上；Collection級別手動Sharding；MongoDB數據模型選擇CAP原則CP，w=Replica Set，開啟SlaveOKw=1，slaveOk開啟；w=1，不開啟slaveOK；庫設計判斷業務增長速度，什么量級，之后是什么增長速度；sharding分片數；memory>index+hot data;索引和熱門數據要大于內存；local庫存放oplog，oplog需要消耗內存；高插入高更新，并帶有延時庫需要設置較大oplog如果沒有延時可選用小一些oplog
