MongoDB的需求目標
MongoDB是一款知名的NoSQL數據庫，其設計哲學是結合關係型數據庫的核心能力和NoSQL的關鍵技術。
上圖的左側即MongoDB目標實現的關係型數據庫的關鍵能力：
- 善於表達的查詢語言：用戶應能夠使用豐富的方法訪問和操作數據，以支持聯機應用和分析應用。
- 輔助索引：索引是高效訪問數據的關鍵，數據庫系統應提供對索引的原生支持。
- 強一致性：應用應當立即讀到提交到數據庫的數據。應避免漸近一致性數據模型(Eventually Consistent Model)導致的複雜應用開發。
- 企業級管理和集成：數據庫應當與企業的IT技術棧無縫的集合，滿足企業級的需求。組織需要數據庫是安全的、可監控的、自動化的，並且可與已有技術基礎架構、流程和人員(運維，DBA，分析師)集成。
上圖的右側，展示了MongoDB目標實現的NoSQL數據庫的技術，以滿足現代應用的需求：
- 靈活的數據模型：與傳統關係型數據庫相比，現代的NoSQL數據庫提供了靈活的數據模型，可以方便的存儲任何結構的數據，並且允許不停機且不影響性能的情況下修改Schema。
- 可擴展性和性能：NoSQL數據庫專注於可擴展性(Scalability)，都有某種形式的分片(sharding)或分區(partitioning)。這使得NoSQL數據庫可以在商用硬件上水平擴展，獲得幾乎無限的高吞吐量和低延時。
- 無中斷全球部署：NoSQL設計用爲持續可用系統，可爲全球用戶提供一直的高質量的體驗。NoSQL數據庫被設計用於在衆多結點間運行，可在服務器，機櫃，甚至跨地域的數據中心間自動同步數據。
MongoDB架構概覽
筆者暫時沒找到一張完整的架構圖可以體現MongoDB的組件和它們之間的關係。
MongoDB靈活存儲架構
存儲引擎是數據庫和硬件之間的接口，它負責處理用什麼數據結構存儲數據，以及如何寫入、刪除和讀取數據。不同的工作負載類型對於讀寫性能的需求不同，例如新聞網站需要大量的讀，而社交類網站需要大量的寫。MongoDB 3.0開始，提供了可插拔的存儲引擎API，使得用戶可以在MongoDB和第三方提供的多種存儲引擎之間切換。
在一個MongoDB複製集中，多種存儲引擎可以並存，可以滿足應用更復雜的需求。例如，使用In-memory存儲引擎進行低延時的操作，同時使用基於磁盤的存儲引擎完成持久化。
WiredTiger
目前MongoDB默認使用的是WiredTiger存儲引擎，WiredTiger是SleepyCat提供的一款開源數據引擎。通過使用現代編程技術，如Hazard指針和Lock-free算法，WiredTiger實現了多核可擴展性。
《MongoDB實戰》的作者在書中對WiredTiger和老的存儲引擎做了MMAPv1比較測試，WiredTiger要節省85%的存儲空間，開啓壓縮後比WiredTiger節省90%；寫操作時優勢不明顯；從磁盤順序讀時，WiredTiger要快69%，開啓壓縮後比WiredTiger快68%。
三方存儲引擎
RocketsDB是Facebook開發的一款鍵值存儲數據庫，通過使用LSM樹引擎，RocketsDB適合於需要高速寫入性能的應用，如社交媒體。
In-memory存儲引擎可爲實時分析應用提供極高的性能，MongoDB自帶的In-memory存儲引擎是企業高級版中才有的，Percona Server for MongoDB中提供了免費的In-memory存儲引擎，有需求的讀者可以試用。
複製——MongoDB的高可用方案
MongoDB提供了複製集（Replica Set）以提供數據保護、負載均衡和容災能力。複製集是一組配置成可自動同步數據和故障切換（Failover）的結點。早期版本MongoDB提供的主從（Master Slave）數據複製只支持數據同步，而不支持自動故障切換，已被複制集替代。MogoDB的Journaling日誌功能也提供了數據保護能力，與複製集相比，Journaling可以大幅提升故障後數據恢復的速度，常與複製集一起使用。雖然備份不能像複製一樣準實時進行，但是備份可以挽救邏輯錯誤，比如應用或運維人員誤刪除了數據，因此也需要在生成環境使用。
如圖所示，一個MongoDB複製集至少由3個節點組成，其中可寫可讀的主節點（Primary）有且僅有一個。副節點（Secondary）可以有一致多個，副結點使用長輪詢（Long Polling）技術準實時地從主節點local集合中獲取包含數據變化信息的Oplog，應用於副結點庫，這個過程是異步的，即複製故障不會影響主節點的讀寫。爲了減少複製數據，複製集中還可以添加仲裁節點（Arbiter），仲裁節點參與主節點的選舉，但不從主節點複製數據。
複製集中的節點每隔2秒會向複製集中的其它節點發出心跳請求（Hearbeat），以檢測和維護複製集。MongoDB複製集中有一個重要的概念是多數集（Majority），指的是複製集中超過50%的節點構成的集合。當複製集中的節點或網絡發生故障時，如果多數集中沒有主節點了，將在多數集中選舉新的主節點，同時不在多數集中的主節點將被降級爲副節點。爲了保持超過50%的節點，複製集中的節點數一般爲奇數，而最小複製集由3個節點組成。
關於數據一致性
MongoDB規定，只有當數據被複制到多數集以後，一個寫操作才能被認爲提交成功。發生故障導致沒有被複制到多數集的數據將被回滾。這樣就存在一種可能性，程序寫入數據時正常返回了，但因沒有複製到多數集，後續被回滾掉了。MongoDB提供了接口可以細粒度的控制複製集的讀寫，可以在寫入關鍵數據時設置數據被複制到多數集後再返回，可以避免這個問題。
水平分區——MongoDB的可擴展架構
水平分區（Sharding）指的是將數據庫分爲更小塊，以支持更大量的數據量存儲和負載。MongoDB提供了對水平分區的支持，對於應用是透明的，即應用可以向訪問單個MongoDB數據庫一樣訪問一個MongoDB分區集羣（Sharded Cluster）,如圖，MongoDB分區集羣由以下的組件構成：
- 分區（Shards)：存儲應用數據的MongoDB進程。在分區集羣中，應用不直接連接到分區。
- mongos路由器（router）：按照分區元數據將應用的操作路由到分區。爲了提高效率，路由器中緩存了分區元數據。
- 配置服務器（Config server）：持久化存儲分區集羣的元數據，包括哪些數據子集歸屬於哪個分區。
最小高可用部署
爲了保持MongoDB的高可用性，一個最小的分區集羣環境需要四臺服務器，如下圖所示：
最小高可用+容災部署
爲了支持容災，數據應當至少複製到一個異地的數據中心，如圖所示，在增加容災需求以後，部署一個最小的分區集羣至少需要六臺服務器：
分區鍵的選擇
在一個MongoDB分區集羣上創建一個新的數據庫時，新數據庫會被分配到一個分區中，而不會自動水平擴展到整個分區集羣。需要配置允許對數據庫上的集合分區，併爲集合設置分區鍵(Shard Key)，才能達到分佈式存儲的效果。分區鍵一旦選擇則無法修改，而不當的選擇分區鍵，可能引起集羣存儲或負載不均衡、查詢效率低等問題，因此要在規劃時合理的選擇分區鍵。
MongoDB的水平分區是基於分區鍵的範圍的，當DBA設置了集合的分區鍵以後，MongoDB按照分區鍵自動將集合劃分爲數據大塊（Chunk）,劃分時是基於值範圍的，如Abbot->Dayton分爲一個大塊，Dayton->Harris分爲一個大塊。隨着數據的增多，（默認大塊大於64MB時）MongoDB會將一個大塊切分爲兩個大塊，MongoDB也會將大塊從大塊數量較多的分區遷移到數量較少的分區，以保持整個分區集羣的平衡。
下面來結合兩個具體的例子看看如何選擇分區鍵：
例1：有一個數據集合中存儲了用戶的Office文檔，每個用戶都有唯一的userId。首先的想法是使用mongodb文檔的_id作爲分區鍵，_id是全局唯一的，可以避免產生無法分割的大塊問題，但_id是一個遞增序列，缺點是因分區是基於範圍的，寫操作將集中於最後的一個大塊，會造成集羣的負載不均衡；用戶的userId是查找用戶文檔時的常用條件，也是一個分區鍵的候選，但以userId爲分區鍵時，如果一個用戶存儲了大量的文檔（如超過10GB），這些文檔因分區鍵userId相同只能存在於一個分區，會造成集羣的存儲不均衡。在這個案例中，使用userId+_id的組合分區鍵是一個理想的選擇，可以對前兩個方案取長補短。
例2：有一個數據集合中存儲了用戶的郵件，郵件有一個發件人，一致多個收件人。可以發件人的userId來作爲分區鍵，但是在收件人收郵件時，需要查找所有的分區以找到收件人的所有郵件。反之，也可以以收件人的userId來作爲分區鍵，但是需要爲每一位收件人複製一份郵件的副本，會影響寫的速度並消耗更多的存儲。在這個案例中，因爲接收郵件比發送郵件是更高頻的場景，較理想方案是使用收件人的userId來作爲分區鍵。
強調一點，即使使用了合理的分區鍵，也要爲查詢創建適當的索引，分區鍵不能代替索引提供的能力。
參考資料
1. https://www.mongodb.com/mongodb-architecture
2. https://www.safaribooksonline.com/library/view/mongodb-in-action/9781617291609/
