分片集群是指將資料橫向拆分，將乙個資料伺服器上將資料依據一定的規則分散到多台伺服器上。以降低單台伺服器的訪問壓力，提高資料服務的效能。幾乎所有的資料庫系統都能夠手動進行分片，但是這在路由管理上，以及各個分片的管理上都相對困難。mongodb支援自動分片，就可以擺脫手動分片管理困難的問題。集群自動切分資料，達到負載均衡。下面就詳細的做一些介紹。
mongodb分片的基本思想是將集合切分成小塊，這些塊分散到若干片裡面，每個片負責總數居的一部分。這對應用程式來說是透明的，應用程式不必知道資料對應儲存的片是哪乙個，甚至不需要知道資料已經被拆分了。所以分片集群需要提供乙個對分片集群的統一訪問入口，即路由程序：mongos。所有分片的資訊由該路由來維護。下面是分片和沒有分片的結構圖（圖一：來自《mongodb權威指南中文版》；圖二：來自
片鍵的選擇在分片的集群上是非常重要的，它是資料切分的依據。也是訪問資料庫時的路由依據。片鍵的選擇應該考慮分片以後對以下三個方面的影響：
其中最重要的一點是讀和寫的分布。如果你總是朝一台機器寫，那麼這台機器將會成為寫瓶頸，則你的集群的寫效能將會降低。這無關乎你的集群有多少個節點，因為所有的寫操作都只在乙個地方進行。因此，你不應該使用單調遞增的id或時間戳作為片鍵，這樣將會導致你一直往最後乙個副本集中新增資料。
相類似的是如果你的讀操作一直都在同乙個副本集上，那麼你最好祈求你的任務能在機器記憶體所能承受的範圍之內。通過副本集將讀請求劃分開能夠使你的工作資料集大小隨著分片數線性擴充套件。這樣的話你能夠將負載壓力均分到各台機器的記憶體和磁碟之上。
最後一點，如果能夠保證大部分的查詢請求都能夠命中盡可能少的分片那就最好了。對於乙個查詢請求來說，其延遲直接取決於最慢的那個命中伺服器的延遲；所以你命中的分片越少，那麼理論上來說查詢將會越快。這一點並不是硬性的規定，不過如果能夠做到充分考慮那麼應該是很有利的。因為資料塊在分片上的分布僅僅是近似的遵循片鍵的順序，而並不是嚴格的強制指定。
總結：mongodb的分片使用配置上因其是內建的不需要手動分片，因此使用上是相對簡單的。本篇部落格先做乙個簡要的介紹後續會有具體的搭建實現。
MongoDB集群分片及片鍵的選擇
1 因為專案所需，此處有六張表，分別是czgx ljgx qjjd sj wl wnjd這六張表，所用的片鍵選擇為 czgx 承載關係編號，時間，id qjjd 全域性節點編號，時間，id sj 網路層級，事件開始時間，id wl 網路編號，時間，id wnjd 網內節點編號，時間，id 2 在集群...
MongoDB集群分片
什麼是sharding？說白了就是把海量資料水平擴充套件的集群系統，資料分表儲存在sharding的各個節點上。mongodb的資料分開分為chunk，每個chunk都是collection中的一段連續的資料記錄，一般為200mb，超出則生成新的資料塊。構建sharding需要三種角色，shard伺...
mongodb分片 集群
目前在乙個機器上部署，ip 10.1.2.197，埠列表如下 埠埠埠路由服務 27061 路由服務 27062 路由服務 27063 配置服務 27071 配置服務 27072 配置服務 27073 副本集1 27011 副本集2 27021 副本集3 27031 副本集1 27012 副本集2 2...