MongoDB Replication
Primary 接受所有從client傳來的寫入操作
Replica set (副本集) 只會有一個 Primary,因為只有一個成員接受寫入操作。副本集提供嚴格的一致性,對所有從 Primary 的讀取。
為了支持複製操作,Primary 記錄其所有對其數據集的操作到他的 oplog (operations log)。
Secondaries 複製 Primary 的 oplog 到自己的數據集。
Secondaries 的數據集印射 Primary 的數據集。
如果 Primary 不能用,Replica set 會選出一個 Secondary 成為 Primary。
預設情況下,clients 從 Primary 讀取,但是 clients 可以指定一個喜好的來發送讀取操作到 Secondary。從 Secondaries 讀取返回的資料可能不會反射 Primary 的狀態。
你可以增加一個額外的 mongod 實例作為 replica set的 Arbiter (仲裁者)。它不用來維護數據集,只存在於選舉投票。
一個 Secondary 可能會經由一次選舉變為 Primary。
ps:
預設當作primary的server未經initiate()不會被設定為primary,無法在上面進行任何DB操作
作為secondary的server在arbiter未被建立前不會跟primary同步資料
MongoDB Sharding
Sharding 是將儲存資料跨不同機器的方法。
高查詢率會消耗 Server CPU 的能力,大型資料超過單一機器儲存的上限。
為了解決這些問題資料庫有兩種解決方式:
- Vertical scaling : 垂直擴展,就是增加 CPU、增加 Ram 跟增加更多的儲存資源。
- Horizontal scaling : 水平擴展,使用 sharding(分片)機制,分割數據集使之可以跨越在多個 Server 中,或shards(碎片)。
每個 shard 都是一個獨立的資料庫,很多個 shards 可以組成單一個邏輯資料庫。
Sharding 減少了每個 Server 需要儲存的資料量。當 Cluster(集群)增長時,每個 Shard 儲存了更少的資料量。
舉例來說,一個資料庫擁有 1TB 的資料數據,分成4個 shards 來存,每個需管理 256GB 的資料量。
假如分配給40個 shards,每個 shard 只需管理 25GB 的資料而已。
一個 MongoDB 的 Sharded Cluster 由以下元件組成 : shards, query routers 及 config servers。
Shards : 用來儲存資料,為了提高可用性和資料的一致性,在 production 的
Sharded Cluster 每個 Shard 通常是一個 Replica Set (副本集)。Query Routers : 在 MongoDB 裡稱為 mongos,作為讓 client 端可以直接操作到對應的 shards的一個介面。一個 Sharded Cluster 可以擁有多個 Routers 來分擔 client 發過來的要求。
Config servers : 儲存 cluster 的 metadata(用來描述資料屬性)
Data Partitions(資料分割)
Sharding partitions a collection’s data by the shard key.
Shard Keys
要對一個collection做分片(shard),需要選擇 shard key。
MongoDB 由 shard key 將資料分割成許多的 chunks 平均分佈在 shards。依據 range based 和 hash based 不同種的 shard key,可以對資料做不同的儲存策略。
Range Based Sharding
Hash Based Sharding
Customized Data Distribution with Tag Aware Sharding
維持分散資料平衡
MongoDB使用兩個背景程式處理確保一個 blanced cluster:splitting & balancer.
Splitting
Splitting,一個背景程式,確保 chunks 的成長不會太大。當一個 chunk 成長為指定的 chunk 大小(specified chunk size)時,會將 chunk 分成兩半。
MongoDB 預設的 chunk size 為 64 MB,你可以增加或減少 chunks size。
- 比較小的 chunks,會讓資料更均勻的分佈,但是在資料搬移時花費更多的成本。
- 比較大的 chunks,無論是從網路的角度和在內部開銷方面,讓資料做比較少的搬移。但是這些效率可能會造成資料分佈不均的代價。
- chunk 的大小,會影響每個 chunk 搬移(migrate)的最大文件數量。
Blancing
Blancer,一個背景程式,來管理 chunks 資料的搬移。Blancer 可以藉由 cluster 任何的 query routers 來被執行。
實作練習
使用 MongoDB 這樣做的優點,對延展(scaling)方便資料,並擁有一定的可靠度。當資料儲存空間快不足時,可以對其增加新的 shards,增加 cluster server 的儲存量。
已有三台可用的 server 機,利用這三台機器組成一個 Sharded Cluster Server。
目前規劃架構,每台機器各擁有一個 query router server (mongos) ,各一個 config server,這三台機器組成的 cluster server 擁有 3 個 cluster shards,每個 shard 都是一個副本集 (replica set),分散在3台機器裡。