為什么要用sharing？
Sharding: 優點
越來越大的數據集及不斷提升吞吐量的應用程序對單台mongodb服務器來講是一個挑戰————大量的查詢很快即能耗盡CPU的計算能力，而較大的數據集存儲需求也有可能很快超出單節點的存儲能力。最終，工作集的大多超出了系統的RAM並給I/O帶去巨大壓力。數據庫管理系統界解決此類問題通常有兩類方案：向上擴展和水平擴展。
sharding即是水平擴展的一種解決方案。它通過將數據集分布於多個也稱作分片(shard)的節點上來降低單節點的訪問壓力。每個分片都是一個獨立的數據庫，所有的分片組合起來構成一個邏輯上的完整意義的數據庫。因此，分片機制降低了每個分片的數據操作量及需要存儲的數據量。
mongodb的每個分片默認64M
mongodb的復制原理：
replica Set復制原理：
mongod復制原理同mysql
主節點將所有操作記錄在本地的一個成為oplog的日志文件中，從節點定期去主節點復制這些寫操作，然后對自己的數據副本執行這些操作，從而保證從節點的數據與主節點一致。
replica Set
（圖片來源於互聯網）
replica Set使用的是n個mongod節點，構建具備自動的容錯功能(auto-failover),自動恢復的(auto-recovery)的高可用方案。
使用Replica Set來實現讀寫分離。通過在連接時指定或者在主庫指定slaveOk，由Secondary來分擔讀的壓力，Primary只承擔寫操作。
對於Replica Set中的secondary 節點默認是不可讀的。
sharding
（圖片來源於互聯網）
mongodb的sharding功能是指mongodb通過mongos自動建立一個水平擴展的數據庫集群系統，將數據庫分表存儲在sharding的各個節點上。
通過把Sharding和Replica Sets相結合，可以搭建一個分布式的，高可用性，自動水平擴展的集群。
要構建MongoDB Sharding Cluster，需要三種角色：
Shard Server: mongod 實例， 使用 Replica Sets，確保每個數據節點都具有備份、自動容錯轉移、自動恢復能力。用於存儲實際的數據塊，實際生產環境中一個shard server角色可由幾台機器組個一個relica set承擔，防止主機單點故障
Config Server: mongod 實例，使用 3 個配置服務器，確保元數據完整性(two-phase commit)。存儲了整個 Cluster Metadata，其中包括 chunk 信息。
Route Server: mongos 實例，配合 LVS，實現負載平衡，提高接入性能(high performance)。前端路由，客戶端由此接入，且讓整個集群看上去像單一數據庫，前端應用可以透明使用。
oplog介紹
主節點的操作記錄稱為oplog(operation log)，oplog存儲在local數據庫中(local數據庫不會被復制，用來存放復制狀態信息的)。
oplog中的每個文檔代表着主節點上執行的操作。oplog只作為從節點與主節點保持數據同步的機制。
默認情況下，64位的實例將使用oplog 5%的可用空間，這個空間將在local數據庫中分配，並在服務器啟動時預先分配。切啟動之后設置不生效
如果從節點落后主節點很遠了，oplog日志從節點還沒執行完，oplog可能已經輪滾一圈了，那么從節點將會追趕不上主節點了，復制將會停止。從節點需要重新做完整的同步，可以用{resync:1}命令來手動執行重新同步或在啟動從節點時指定--autoresync選項讓其自動重新同步。重新同步的代價昂貴，應盡量避免，避免的方法就是配置足夠大的oplog。
sharding特性：
主要是把數據和元數據進行分離
config server存儲元數據
sharding存儲數據.
mongos代理
讀操作：客戶端請求進入mongos之后需要去configserver上去獲取數據具體在哪個分片上，然后在和相應的節點進行通信然后再把數據在本地整合起來返回給客戶端
寫操作：對於分片集群分片集合，mongos將應用程序的寫操作直接特定到指定的分片。mongos從config server使用集群元數據將寫操作路由到適當的分片上。基於片鍵將數據分區，然后，MongoDB將這些塊分片到分片上， 片鍵決定塊分片的分布情況。這可能會影響集群寫操作的性能。
