背景：查閱了一下MongoDB的相關文檔，發現中文文檔還是比較少的，工作中需要用到MongoDB，而這本《MongoDB最佳實踐》是很好的選擇，所以就把這本手冊翻譯了一下，其中生澀的專業用語是參考MongoDB中文官網進行翻譯，校對的時間比較少，難免會有不合理的地方，懇請大家指正。 簡介 Mongo ...
背景：查閱了一下MongoDB的相關文檔，發現中文文檔還是比較少的，工作中需要用到MongoDB，而這本《MongoDB最佳實踐》是很好的選擇，所以就把這本手冊翻譯了一下，其中生澀的專業用語是參考MongoDB中文官網進行翻譯，校對的時間比較少，難免會有不合理的地方，懇請大家指正。
簡介
MongoDB是一款為廣泛的現代應用程式設計的高性能、可擴展、分散式資料庫系統。MongoDB可用於不同規模大小的組織，為那些對系統低延遲、高吞吐量以及可持續性有很高要求的應用提供穩定關鍵的服務。
儘管MongoDB與傳統的關係型資料庫的有些特性不一樣，但是對於之前部署和操作其他資料庫系統的人員來說，MongoDB的很多概念，比如操作、策略、存儲過程還是很相似的。公司的DBA和運營團隊可以在保持現有系統的前提下，直接把MongoDB集成到生產環境中，並且不需要定製操作流程和工具
本文檔為部署和管理MongoDB提供了最佳實踐的指導。看本文檔的前提需要你熟悉MongoDB的基本架構並理解企業軟體部署的相關知識。
關於文檔中的涉及到有些話題的更多詳情，可以訪問MongoDB的線上文檔：mongodb.com。本文檔也提供了相應的鏈接。
角色和職責
與其他資料庫系統一樣，部署在MongoDB的應用需要精心規劃以及公司IT團隊每個角色的協力合作才能保證穩定的部署。傳統資料庫中相關的角色以及角色的定位同樣適用於MongoDB：資料庫管理員、系統管理員、應用開發人員、網路管理員、需求分析人員以及數據架構師。
一般小公司中一個人員可能會擔當多個角色，而大公司中，每個角色都是由一個人或者一個團隊專門負責的。比如，在大的投資銀行中，DBA的職責和系統管理員的職責差別就很大。
DBA
與其他資料庫系統一樣，設計一套能達到理想性能和可用性的MongoDB系統需要考慮很多因素。DBA應該在項目早期就參與進來，討論數據類型、發佈到系統中的查詢類型、查詢容量、可用性、恢複目標以及期望的性能表現。
Sysadmin
MongoDB中的系統管理員的職責與其他管理員的職責是類似的，包括：升級軟硬體、管理系統存儲、系統監控以及數據遷移。MongoDB用戶反饋，MongoDB的系統管理員在學習部署、管理以及監控MongoDB中不會遇到任何困難，因為不需要特別的技能要求。
Application Developer
應用開發人員與項目團隊的其他成員協作保證功能、部署、安全、可用性這些需求能完全理解透徹。應用本身是由Java、C#、PHP、Ruby編寫的，數據在MongoDB中完成存儲、升級以及查詢，每種語言對應的驅動程式完成MongoDB與應用的信息交互。應用開發人員與資料庫架構師一起定義數據模型以及優化的數據查詢模型，並與DBA、系統管理員、網路管理員一起確認系統的部署以及可用性需求。
Network Administrator
一般MongoDB是部署在一個或者多個數據中心中的多個分散式伺服器中的，因此網路資源是MongoDB系統的非常重要的考慮因素。儘管與其他資料庫系統相比，MongoDB不需要很多自定義的配置，但是也應該咨詢網路管理員以保證項目有合理的策略、存儲過程、配置、容量以及安全設置。
Data Architect
MongoDB中設計數據模型與關係型資料庫系統類似，數據模型一般都有多種選擇，每種選擇都需要在性能、資源利用、易用性以及其他因素做出權衡。數據架構師需要與開發團隊一起精心權衡這些選擇並針對模式設計做出明智的選擇。一般情況下，數據架構師的職責更加主動，而系統上線後，DBA的職責就比較被動了。
Business Analyst
業務分析人員需要從MongoDB的數據中汲取簡介以便驅動業務的發展。尤其是需要從多個角度審視數據，通常需要把多個集合或者多個資料庫中的數據進行組合。業務分析師如果可以保證實時分析需求的索引合理，就可以獲益良多。
MongoDB部署的準備工作
MongoDB可插拔存儲引擎
MongoDB提供了一個存儲引擎API，作為可插拔存儲引擎的介面，使用可插拔存儲引擎可以擴大MongoDB的性能，在有限的硬體架構的基礎上達到最佳的使用效果。MongoDB提供了多種存儲引擎。
l 預設的WiredTiger存儲引擎。對於大多數應用來說，WiredTiger的顆粒度併發性以及本地壓縮的功能可以提供完美的性能表現和高效的存儲表現。
l Encrypted存儲引擎可以在脫離單獨的文件加密系統的情況下為敏感數據提供加密服務。Enctypted引擎是基於WiredTiger引擎的，所以這篇文章中涉及到WiredTiger引擎的表述同樣適用於Encrypetd引擎，此引擎是MongoDB Enterprise Advanced版本的一部分。
l In-Memory存儲引擎，可以為高要求的應用可預測的潛在因素以及實時性能分析，此引擎也是MongoDB Enterprise Advanced版本的一部分。
l MMAPv1存儲引擎，是MongoDB3.x以及以前版本中使用的存儲引擎的升級版本，MMAPv1是MongoDB3.0及以前版本預設使用的存儲引擎。
在所有資料庫中，MongoDB是唯一允許用戶在一個MongoDB集群中使用多個存儲引擎的資料庫系統。這種靈活性可以提供一種更簡單更可靠的方法來滿足數據的多樣化應用需求。通常，為了滿足數據多樣化，需要使用不同的資料庫系統，並且為了保證一致性以及安全性，需要加入很多複雜的、自定義的代碼使數據在不同資料庫系統間進行遷移。儘管每個存儲引擎對不同的工作負載進行了優化，用戶仍然可以在不同的存儲引擎中使用相同的MongoDB查詢語言、數據模型、擴展方式、安全性以及操作工具。因此，此文檔中的最佳實踐適用於所有支持的存儲引擎。不同存儲引擎的使用建議中的不同之處，文檔也會做提醒。
在MongoDB複製集中使用多引擎能簡化評估以及遷移數據的工作。升級到WiredTiger引擎多現有的複製集是沒有影響的；應用會100%相容系統，使用滾動升級，能在零宕機的情況下完成遷移工作。MongoDB3.2預設的存儲引擎就是WiredTiger；如果要使用其他引擎，可以在啟動mongod的時候使用—storageEnginge選項。如果使用的是3.2+以上的版本啟動的mongod,，並且存在一個或者多個資料庫系統，則可以使用任意的資料庫創建是使用的存儲引擎。
模式設計
開發人員和數據架構師在項目初期就應該一起討論開發合理的數據模型。數據模型、升級以及MongoDB系統的查詢使用應用的需求來驅動的。考慮到MongoDB的動態模型設計特性，開發人員和數據架構師也可以在開發和部署的過程中對數據模型進行迭代以優化性能、存儲高效性以及應用特性需要的其他支持。所有這些工作都不需要大規模修改模式。
模式設計的話題討論是很有意義的，但是本文檔不會做深入的討論。網上有很多相關的資源，包括MongoDB解決方案架構師以及用戶的會議演示，還有MongoDB大學的免費網上培訓。MongoDB全球咨詢服務中的Development Rapid Start service有關於模式設計的咨詢。模式設計的幾個關鍵概念如下。
文檔模型
MongoDB把數據以BSON這種二進位方式存放在文檔中。BSON編碼擴展了流行的JSON格式以支持int、long、decimal和date類型。BSON文檔包含一個或者多個鍵，每個鍵對應一個值。值的類型包含數組、嵌入式文檔和二進位數據。文檔大概類似於關係型資料庫中的行，而鍵大概類似於關係型資料庫中的列。MongoDB一個文檔可以包含所有相關的數據，而關係型資料庫中相關聯的數據通常是在多個表中的多個行里。比如，在關係型資料庫中放在兩張表中的父子關係這種數據在MongoDB中可以放在一個文檔中。
集合
很多文檔組合在一起就形成了集合。一般來說，一個集合中的所有文檔的作用對應用來說都是類似的或者說有相關聯繫的。集合可以理解為關係型資料庫中的表。
動態圖表以及文檔驗證
MongoDB的文檔在結構上是可以變化的。例如，一張用戶表可能包含用戶ID以及用戶最近登錄系統的時間，但是只有一部分文檔可能會包含用戶的購物地址，有些甚至還包含多個用戶購物地址。MongoDB不會強制所有的文檔保持同樣的結構。因此文檔的結構是不需要事先聲明的——文檔是自描述的。
文檔驗證功能可以對文檔結構、數據類型、數據範圍以及欄位是否強制存在進行檢查，從而允許DBA對數據進行強制性管理。這樣一來，DBA就可以管理數據標準，而開發人員就可以享受靈活性文檔模型帶來多種好處。這些內容在以下博客中有所涉及：《文檔驗證：》
MongoDB Compass幫助識別有用的驗證規則，然後可以在GUI中創建這些規則。
索引
MongoDB使用B樹索引來優化查詢。索引是在文檔級別定義的。MongoDB支持很多類型的索引，包括混合索引、地理索引、TTL、文本搜索、偏重索引、唯一所以以及其他的。詳情看後文的索引章節。
事務
更新操作的原子性會影響你應用的模式設計。MongoDB可以在文檔級別保證更新的ACID原則。一個原子操作不可能更新多個文檔，但是，和JOIN一樣，把關係型數據嵌入到MongoDB文檔中就可以解決這種需求。
模式設計的深入詳情可以在MongoDB文檔中查看Data Modeling Considerations for MongoDB
使用MongoDB Compass可視化模式並增加驗證規則
MongoDB Compass GUI可以讓用戶清楚明瞭的瞭解資料庫中的數據結構，即使不掌握MongoDB的查詢語言，也可以對數據進行特定的查詢。這些用戶通常是創建一個新的MongoDB項目的架構師，或者從開發團隊接手過來的已有資料庫系統，並且需要在生產環境中維護的。你需要理解資料庫中存在哪些數據，怎麼定義合適的索引，確認是否需要創建文檔驗證規則以保證文檔結構的一致性。
不用MongoDB Compass，如果想瞭解數據的大致情況，就需要連接到MongoDB shell，並使用查詢語句把文檔結構、欄位名、數據類型反饋給工程師。同樣，需要進行自定義查詢，就必須要理解MongoDB的查詢語言。
MongoDB Compass會採樣集合的子文檔中的數據並以圖形化的方式展現給用戶。通過採樣，MongoDB可以在最小化消耗資料庫負載的情況下及時的把結果展現給用戶。
文檔驗證可以讓DBA對文檔結構、數據類型、數據範圍、必填欄位進行強制性管理。具體的驗證規則現在也可以在Compass的GUI中進行管理。通過點擊幾下滑鼠就可以創建並修改驗證規則，違反規則的文檔也可以清晰的展示出來。DBA使用Compass的CRUD功能解決單個文檔中的數據質量問題。
文檔大小
MongoDB中BSON文檔最大支持16M，用戶應該避免一些特定的應用程式無限制的使文檔增大。例如，電商平臺應用中，很難估算每個商品可能會收到多少用戶評價，所以，通常的做法是只顯示一部分商品評價，比如最近的以及最廣泛的評價。相比把商品和評價放在一個文檔中，把每個評價或者一組評價單獨放在一個文檔中會更方便，同時，在存放商品的文檔中存放一些主要的評價以便快速訪問即可。
GridFS
大於16M的文件，MongoDB提供了GridFS這種功能，所有的驅動程式都支持這種功能。GridFS可以自動地把大的數據分成多個塊，每個塊256KB，同時維護這些塊的元數據。GridFS能檢索單個塊也能檢索整個文檔。比如，應用可以快速的跳轉到一段視頻的具體某個時間戳的位置。GridFS通常用來存儲照片以及視頻這些比較大的二進位文件。
空間分配調整（僅與MMAPv1存儲引擎相關）
在MongoDB MMAPv1存儲引擎中更新文檔時，如果有足夠的空間，數據就地更新。如果更新的文檔比分配的空間大，那麼文檔就需要重新寫在新的位置。遷移文檔並更新相關索引的過程會消耗很大的I/O並引起一些本可避免的性能問題。
為了預測數據未來的數據量，預設情況下，每個集合的usePowerOf2Sizes屬性是開啟的。預設情況下（從MongoDB3.0開始），MongoDB會把分配空間四捨五入成2的冪（比如2,4,8,16,等等），這樣會減少由於文檔遷移造成I/O增大的幾率，代價就是需要增加額外的存儲。如果你明確數據添加後不會增加，那可以把noPadding設定為true來節省空間。
另外一種做法是設置noPadding為true，並手動為文檔進行空間預留以保證文檔有足夠的空間。如果應用以可預測的方式把數據加入文檔中，則可以先添加文檔的鍵，再添鍵對應的值，這樣可以在文檔創建的過程中分配合理的空間。空間預留會最小化文檔遷移帶來的性能損耗，因此能最小化負載。
以上所涉及的內容僅限於MMAPv1存儲引擎，不適用WiredTiger引擎以及以WiredTiger為基礎的其他引擎，比如Encrypted引擎，它會為每個更新操作進行重寫。
數據生命周期管理
MongoDB可以管理數據的整個生命周期，包括TTL索引以及capped集合。除此之外，使用MongoDB Zones管理員可以創建高效的分層存儲模型以管理數據生命周期。管理員把分片分配到Zones中，就通過存儲密度來平衡潛在的查詢壓力，同時，基於時間戳這樣的值，把數據集分片到指定的存儲設備中可以平衡查詢消耗：
l 最新的以及訪問頻率高的數據可以放在高性能的SSD硬碟中，並開啟壓縮機制。
l 舊數據訪問頻率低的數據可以放在性能低的硬碟中，並使用zlib壓縮，這樣達到最小的存儲代價
l 當數據不斷增加時，MongoDB會自動在存儲層級之間遷移數據，不需要管理員創建工具或者ETL進程來管理數據遷移。
TTL
如果集合中的文檔只是在固定的時間段內有效，那麼TTL特性可以用來自動刪除過期文檔也不用查看所有文檔的日期併進行一系列的刪除操作。比如，如果用戶session只能在系統中存在一個小時，那麼可以為文檔中的lastActivity數據欄位的TTL設置成3600秒。後臺進程會自動檢測所有文檔並刪除時間超過3600秒的文檔。TTL最常見的一個例子就是在特定時間後就會過期的價格。
Capped Collections
Capped Collections是固定大小的集合，支持高流量的數據讀寫。Capped Collections類似於迴圈緩衝區：數據按照插入的順序依次插入文檔中，當集合的大小達到設定的閾值後，最先插入的數據會被刪除掉，為最新插入的數據騰出空間。例如，把日誌信息存儲在一個高容量的Capped Collections集合中，就可以快速的檢索到最新的日誌信息。
刪除集合
MongoDB中刪除集合的操作是非常高效的。如果你的數據生命周期要求周期性刪除大容量的文檔，那麼涉及數據模型時，最好把這些文檔放在單個集合中。刪除一個集合要遠比刪除集合中所有文檔要高效的多。這就類似於在關係型資料庫中刪除一個表要比刪除表中所有的行要更高效。
使用WiredTiger時，刪除集合後硬碟空間會自動回收，在MMAPv1中刪除集合後空間會自動釋放，並會用於新文檔的使用。
索引
和其他大多數資料庫管理系統一樣，索引是MongoDB中優化系統性能的重要機制。雖然索引可以把操作的性能提升一個或者多個數量級，但是也會為更新操作、磁碟空間、記憶體帶來不小的負荷。用戶任何時候都需要為查詢創建合適的索引，但是不應該維護一些沒有必要的索引。這對那些需要頻繁寫入的應用來說尤其重要。
為了操作的簡單性，MongoDB Ops Manager 和Cloud Manager平臺可以識別丟失的索引並且在不影響應用的情況下自動處理這些索引。
要想瞭解已存在的索引的使用高效性，可以開啟$indexStats這個聚合狀態，以便確定索引使用的頻率。MongoDB Compass可以把索引情況可視化，讓你知道哪些欄位使用了索引，他們的索引類型以及使用的頻率。
查詢優化
MongoDB可以自動對查詢進行優化並儘可能高效的對查詢進行評估。評估通常包括基於謂詞的數據選擇和基於排序類別的數據排序。查詢優化器會周期性的執行多種查詢計劃並選擇性能變現最好的索引。這種經驗式測試結果會以緩存查詢計劃存儲下來並周期性執行。
MongoDB有explain工具，可以顯示每個查詢優化前後的信息，包括：
l 文檔返回數
l 文檔讀取數
l 使用了哪個索引
l 查詢是否被覆蓋，如果覆蓋了，則文檔不需要讀取以返回數據
l 記憶體排序是否執行了，如果執行了，就意味著加入索引會更高效
l 索引掃描數量
l 查詢多長時間可以返回結果（僅限於使用executionStats模式）
l 那個可選擇的查詢方案被否決了（僅限於allPlansExecution模式）
如果查詢的過程花費不到1ms，那麼解釋計劃會顯示0ms，通常，在一個優化過的系統中，查詢時間就不應該超過1ms。執行計劃確定後，之前的緩存查詢計劃就會放棄，但是多樣的測試索引計劃還是會重覆執行保證最佳的執行計劃會得到實施。查詢計劃可以在不執行查詢的前提下對查詢過程進行估算並返回結果，DBA不需要等到查詢過程執行完就可以評估使用哪個查詢計劃。
MongoDB Compass能可視化解釋計劃的過程，提供查詢過程的一些關鍵信息，比如返迴文檔數、執行時間、索引使用情況等等。每個執行管道的狀態會當做一個節點展現在一個樹壯圖中，方便查看多節點的解釋計劃。
如果索引在應用中會經常使用到，就可以設置notablescan選項，當一個查詢要掃描整個文檔時就拋出一個異常。
歸檔
MongoDB有一個資料庫歸檔器的功能，可以記錄資料庫操作的細粒度的信息。歸檔器可以記錄所有事件的信息，也可以記錄那些執行時間超過設定閾值（預設的是100ms）的事件。歸檔數據會存放在一個封頂集合中，並可以很方便的查詢到相關數據。查詢這個集合中的內容往往比翻找日誌文件要方便的多。
如果出現慢查詢，用MongoDB Ops Manager 和Cloud Manager（後文會提到）可以把歸檔器的輸出信息可視化。Visual Query Profiler為運維人員和DBA提供快速簡便的方式來分析具體的查詢語句。Visual Query Profiler會展示查詢和寫入的延時的隨時間變化趨勢，這。樣就可以方便的識別出那些是慢查詢以及那些查詢的延遲最高。在Ops Manager的圖形界面中點擊一下滑鼠就可以開啟歸檔器，會在一個界面中展示並整合所有節點的信息。
Visual Query Profiler會分析系統推薦的索引，並通過自動滾動索引創建選擇性的添加索引。
主索引和輔助索引
所有文檔都會有一個叫做_id的唯一索引。文檔插入時，MongoDB會自動的創建一個_id欄位，如果用戶沒有給這個欄位知道值，MongoDB會自動為它分配一個值。所有用戶定義的索引都叫做輔助索引。MongoDB支持很多類型的輔助索引，並且可以定義在文檔中的任何欄位上，包括數組以及子文檔。索引類型如下：
l 混合索引
l 地理索引
l 文本搜索索引
l 唯一索引
l 數組索引
l TTL索引
l 稀疏索引
l 偏重索引
l 哈希索引
l 針對不同語言的校對索引（MongoDB3.4以後的版本才有）
索引創建選項
MongoDB中索引和數據是同時更新的，保證在索引上的查詢不會返回舊的數據或者刪除的數據。模式設計的過程中就應該考慮如何設計合理的索引。MongoDB中預設情況下，索引的創建是個阻塞性操作。由於創建索引會消耗很多時間和資源，所以在複製集的主次節點上，索引的創建都可以在後臺進行操作。當開啟後臺操作後，索引創建的總時間會比前臺操作的時間要長一些，但是創建索引的過程任然可以對資料庫進行查詢操作。
一個通常的經驗是，在前臺創建索引，先在此節點上，再在降級的主節點上創建。這些過程在Ops Manager 和 Cloud Manager中可以自動實現。
除此之外，在後臺可以同時創建多個索引。關於索引創建需要考慮的因素已經索引線上維護的更多信息，請參考Build Index on Replica Sets documentation。
在WiredTiger存儲引擎中管理索引
所有的存儲引擎都在支持MongoDB豐富的索引功能。使用WiredTiger時，有以下幾個可供使用的優化意見：
l WiredTiger預設會開啟壓縮功能以減少永久性存儲和RAM上的索引占用。這使得管理員可以分配更多的工作集用來管理那些訪問頻率高的文檔。壓縮比率一般是50%左右，但是鼓勵用戶通過測試他們自己的工作負荷來確定實際的壓縮比例。
l 管理員同樣可以把索引放在單獨的存儲捲上，以帶來更快的硬碟換頁以及避免資產爭奪。
索引限制
跟其他資料庫系統一樣，MongoDB中的索引也會占用硬碟空間以及消耗記憶體，所以需要的時候再用索引。索引會影響更新操作的性能。每個更新操作需要先定位到要修改的數據，這個時候就會使用索引，但是索引本身的維護也是需要開銷的，這就會降低更新操作的性能。
部署MongoDB時有幾個限制因素需要考慮：
l 一個文檔最多只能建64個索引
l 索引不能超過2014比特
l 索引名字不能超過125個字母（包括命名空間）
l 沒有索引的記憶體數據排序不能超過32M，這種操作很消耗CPU，記憶體數據排序最好是創建索引來優化查詢
索引的常見錯誤
下列的使用意見可以避免索引常見的問題：
l 使用混合索引而不用索引交叉：通過多個欄位查詢內容時，使用混合索引可以提供更好的性能。
l 混合索引：混合索引是通過欄位來定義和排序的。所以，如果索引定義在last name、first name、city這三個欄位上，查詢last name或者查詢last name和first name的時候就可以使用剛纔創建的索引，但是，如果查詢是基於city欄位的，則使用剛纔的索引並不會起到索引的效果。另一個經驗是刪除是其他所以首碼的索引。
l 低選擇性索引：索引應該建立在那些選擇範圍比較大的欄位上。例如，在性別這個欄位上創建索引效果的不明顯，不如把索引創建在zip代碼或者電話號碼這樣的欄位上。
l 正則表達式：索引是按照值來排序的，所以，前置通配符的效率並不高，還很可能導致全索引掃描。如果表達式中有足夠多的區分大小寫的字母，則使用後置通配符會更高效。
l 清除不必要的索引：索引會消耗很多資源，它們會占用RAM，欄位的值更新時，相關聯的索引也需要同時更新，就會導致額外的磁碟I/0消耗。使用$indexStats聚合狀態可以決定索引使用的頻率，從而查看每個索引的使用高效性。如果有些索引使用不到，就可以刪除它以便減少磁碟占用並加快寫入速度。在MongoDB Compass GUI中可以查看索引的使用情況。
l 偏重索引：如果一個索引只會被特定的一些文檔使用到，則可以通過指定一個過濾條件為索引這是偏重選項。比如，如果一個定義在userId欄位上的索引只是在查詢未完成訂單時才用到，那麼，可以為它增加一個訂單狀態時正在交易中這樣的條件。這樣，偏重索引可以增加查詢性能並減少系統負荷。
工作集
MongoDB會充分使用RAM以加速資料庫操作。所有數據的讀取和操作都是在記憶體中完成的。WiredTiger存儲引擎使用內部緩存管理數據。MMAPv1使用記憶體映射文件。從記憶體中讀取數據的時間是以納秒來度量的，而從硬碟中讀取數據的時間是以毫秒來度量的，從記憶體中讀取數據的速度是從硬碟中讀取數據的1000000多倍。
通過正常操作獲取的數據集合索引叫做工作集。最理想的效果是所有的工作集都是在RAM中。有時候，工作集只代表整個數據的一部分，比如在最常訪問的數據是最新以及最受歡迎的產品的應用中。
當MongoDB試圖獲取不在記憶體中的數據時就會發生頁面錯誤。如果有空閑的記憶體，則操作系統會定位到硬碟上的頁面中並把數據直接載入到記憶體中。然而，如果沒有足夠的記憶體，操作系統必須把記憶體中的某個頁面數據寫入硬碟中，當應用取數據時，把需要的數據頁讀到記憶體中。這個過程很耗時，比直接從記憶體中取數據要慢的多。
有些操作會無意間清楚很多記憶體中的工作集，這會嚴重影響系統性能。比如，有一個查詢操作掃描了資料庫中的所有文檔，文檔中的數據量超過了RAM的容量，這就會導致文檔的所有數據被讀取到記憶體中並導致記憶體中的工作集別擠出記憶體到硬碟中。其他一下資料庫維護的操作也會引起這樣的問題，比如資料庫優化或者資料庫恢復以及索引重建。
如果你資料庫工作集超過了系統RAM的容量，可以考慮增大RAM容量或者增加資料庫分片數量。有關這方面的討論話題，請參考Sharding Best Practices中的有關章節。系統資源達到瓶頸之前部署分片是非常容易的，所以容量規劃是一個成功項目的中的一個重要環節。
使用預設的WiredTiger存儲引擎時，配置WiredTiger內部緩存大小可以參考https://docs.mongodb.com/manual/administration/production-notes/#id3
如果配置了MMAPv1，關於如何配置RAM大小可以參考：https://docs.mongodb.com/manual/faq/diagnostics/#how-do-i-calculate-how-much-ram-i-need-for-my-application
MongoDB啟動和配置
啟動
MongoDB同時提供了.ded和.rpm的包用戶系統安裝、升級、系統遷移以及系統配置。MongoDB的Windows安裝包可以通過MSI下載的二進位文件安裝，OS X的二進位文件也在tarball2中提供。
資料庫配置
用戶應該把資料庫的配置信息存放在mongod的配置文件中。這樣系統管理員可以為整個集群實施合理的配置信息。配置文件支持mongod命令行提供的所有選項。MongoDB支持流行的自動化管理工具比如Chef和Puppet。Ops Manager 和 Cloud Manager平臺可以自動配置複製集合分片集群的複雜拓撲，這些內容文檔後面會提到。
升級
建議用戶經常升級資料庫系統，不僅可以使用新系統中的最新特性以及穩定性，還能修複系統bug。系統升級應該現在非生產環境中測試。
MongoDB支持滾動升級，在不宕機的情況下完成升級，複製集中每個成員都可以單獨升級，不會影響資料庫的可用性。複製集中的每個成員可以運行不同版本的MongoDB，也可以配置不同的存儲引擎。作為保障，升級前最好參考MongoDB版本說明，看各個版本升級是否有特定的順序要求，或者兩個版本之間是否存在不相容。Ops Manager 和Cloud Manager中，這些操作可以自動完成。
數據遷移
用戶應該進行評估併為應用做出設計出最佳數據模型，而不是簡單的把原有系統的數據直接導入MongoDB中。傳統關係型資料庫中，數據更多的是以CSV這樣的文件類型在系統之間進行遷移。MongoDB資料庫可以接受CSV類型的文件系統，但是這隻是數據遷移的第一步工作。通常來說，MongoDB的文檔數據模型有很多優勢和選擇性，而這在關係型資料庫是沒有的。
Mongoimport 和mongoexport工具可以把JSON或者CSV文件導入或者導出到MongoDB文件系統中。這些工具只是在數據初始化的時候有用。Mongodump和mongorestore工具或者Ops Manager以及Cloud Manager備份工具可以在MongoDB系統之間數據遷移的時候用到。
把JSON文件導入系統中有很多選擇，包括mongoimport，自定義腳本、ELT工具。
硬體
以下的意見旨在為你的MongoDB系統的硬體提供高質量的指導。硬體的具體配置還要依賴於你的數據、查詢頻率、性能SLA、訪問量以及底層硬體設施的容量。MongoDB有非常豐富的經驗幫助客戶選擇合適的硬體併進行配置，我們會經常協助客戶進行容量規劃以及優化他們的MongoDB系統。當你為項目選擇硬體時，可以查考以下資料，會有很大的幫助：Health Check、Operations Rapid Start, 以及Production Readiness consulting packages。
MongoDB對商業硬體支持度很高，對硬體需求和限制很少。通常來說，MongoDB會最大程度的利用RAM和CPU時鐘速度。
記憶體
MongoDB會最大程度的使用RAM以增加系統性能。一般來說，RAM越大越好。跟其他資料庫一樣，當工作負載開始請求不在RAM中的數據時，MongoDB的性能下降。MMAPv1會讓操作系統自己去管理RAM的使用，而預設的WiredTiger存儲引擎則是更多的由用戶決定分配多少RAM給WiredTiger內部緩存，預設的是RAM*60%-1G，WiredTiger也會利用操作系統的文件緩存系統，而文件緩存系統則會利用系統中剩餘的可以記憶體。
存儲
MongoDB不需要共用存儲，可以使用本地附加的存儲以及固態硬碟。MongoDB中的大多數磁碟訪問模式都沒有順序屬性，因此客戶可能會使用SSD來獲得大幅的性能提升。由於MongoDB的非順序訪問模式，商用SATA旋轉硬碟的表現可以跟昂貴的旋轉驅動器相媲美，與其把預算花在更貴的旋轉驅動上，不如把這些開支放在增加RAM以及使用SSD上來的更高效。使用SSD的另一個好處是，如果記憶體中的工作集滿了，則硬碟中的快閃記憶體會提供性能優勢。
儘管使用SSD可以獲取高性能，MongoDB中的日誌功能由於其連續寫入機制，可以為系統提供更快更方便的硬碟體驗。本文檔中後續關於日誌的章節會有更多的介紹
建議MongoDB部署時使用RAID10。RAID5和RAID6由於其本身顯示提供不了足夠的性能。RAID0可以提供良好的讀寫性能，但是系統冗餘性不足。MongoDB的複製集可以為數據提供高可用性，要滿足系統的高可用，應該考慮複製集、RAID機制以及其他因素。
壓縮
使用預設的WiredTiger存儲引擎時，MongoDB本身就支持壓縮功能。壓縮機制能大概減少80%的存儲占用，由於從硬碟中讀取的數據位元組少，能提供更高的存儲I/O擴展性。與其他壓縮演算法一樣，管理員使用壓縮功能，雖然提供了存儲能力，同時帶來了較高的CPU負載，因此在你自己的環境中對壓縮帶來的影響進行測試是非常重要重要的。
MongoDB為文檔、索引、日誌提供了豐富的壓縮選項。預設的Snappy壓縮演算法在較高的文檔以及日誌壓縮比率（一般是70%，具體要看數據）和較低的CPU負載之間提供了很好的平衡性，zlib演算法雖然壓縮比率高，但是當數據寫入硬碟以及從硬碟中讀取時也會導致較高的CPU周期。WiredTiger的索引使用首碼壓縮，減少記憶體中的索引存儲的占比，為那些經常訪問的數據騰出空間。管理員可以修改預設的壓縮設置。壓縮機制也可以根據集合的創建指定在特定的集合上使用。
CPU
MongoDB在更快的CPU上能提供更好的性能。MongoDB的WiredTiger存儲引擎比MMAPv1能更豐富的利用多核處理器資源。Encrypted存儲引擎由於一部分CPU要用來進行加密和解密的工作，會比WiredTiger多平均15%的系統負載，具體的數量還要看你的數據集大小。
每個主機的進程
要獲取最佳性能，建議用戶在每個主機上單獨運行一個mongod。使用虛擬化和容器技術為系統分配合理的容量和資源，這樣在單個伺服器上就可以運行多個MongoDB進程且不存在資源爭奪。使用WiredTiger存儲引擎時，管理員需要估算每個實例使用總RAM的比例，併為每個實例分配合理的緩存大小。
為了系統可用性，同一個複製集的多個成員不應該部署在同一個硬體設備上，也不應該共用任何單一的故障資源，比如電源。如果系統部署在雲上，確保虛擬化廠商的跨可用性部署能力，以保證每個複製集的成員在物理上是隔離的，不會共用一個電源、應用程式或者網路。
虛擬化以及IaaS
在虛擬化以及雲環境中，用戶可以把MongoDB部署在裸機之上。一般來說，部署在裸機上的系統其性能表現是最好的，儘管很多MongoDB用戶會考慮IaaS平臺，比如AmazonWeb Services' Elastic Compute Cloud (AWS EC2), Google Compute Engine, Microsoft Azure, Rackspace以及其他的。
調整mongos和配置伺服器進程
對於分片系統，除了數據存儲進程，還需要另外部署兩個系統：mongos查詢路由以及配置伺服器。分片伺服器是物理隔離的多個伺服器。關於分片的更多信息，詳見水平擴展相關的章節。所有查詢操作會被一個叫做mongos的路由進程路由到合適的分片伺服器上。Mongos決定一個查詢怎麼路由，配置伺服器維護的是元數據。Mongos和配置伺服器是同樣重要的，但是兩個都有不同的尺寸要求。
分片中，MongoDB會把文檔分成塊。MongoDB把塊與分片伺服器之間的關係當做元數據存放在配置伺服器中。每個分片部署中，最少有單個配置伺服器以保證任何時候元數據的可用性。分片的元數據訪問頻率比較大：每個mongos維護一部分緩存數據，這些緩存數據會周期性在後臺進行更新，一般是由集群擴張引起的數據平衡操作時。因此配置伺服器的硬體配置就尤其需要考慮可用性使用冗餘電源、冗餘RAID控制器以及冗餘存儲。配置伺服器可以部署成複製集，但是最多只能有50個成員。
一般MongoDB分片系統中會有多個mongos實例。很少有用戶為每個應用部署一個mongos實例。Mongos伺服器的最佳數量取決於應用的具體負載：有些場合下mongos只是查詢路由到合適的分片上，有些場合下mongos除了路由查詢還需要把結果集進行合併。評估每個mongos的記憶體需求時，需要考慮如下幾個方面：
l 在mongos中緩存的分片元數據的總大小
l 每個應用鏈接會消耗1MB
Mongos進程使用的RAM是有限的，CPU越快或者網速越快mongos的表現越好。
操作系統和文件系統
Linux的配置
MongoDB只支持64位的操作系統。安裝MMAPv1存儲引擎的MongoDB支持32位系統，但是僅僅是為老系統提供向後相容的作用。WiredTiger存儲引擎的MongoDB不支持32位操作系統。
生產環境中MongoDB應該部署在Linux2.6.36內核版本或者以上版本中，使用EXT4或者XFS文件系統；避免使用EXT3，EXT3文件系統是非常古老的文件系統，對資料庫系統來說不是最佳的選擇。比如，MMAPv1會為數據預分配空間。EXT3文件系統中，預分配操作實際上會寫0s到硬碟中以實現空間分配，這是非常耗時的。EXT4和XFS文件系統中，預分配是當做邏輯操作執行的，所以更高效。
使用WiredTiger時，強烈建議使用XFS避免使用EXT4時出現的性能問題。
Linux中部署MongoDB時可以參考以下推薦的配置：
l 關閉資料庫文件存儲捲的atime屬性
l 不要使用HugePages這樣的虛擬記憶體頁，使用正常的虛擬記憶體頁MongoDB會表現更好
l 在BIOS中關閉NUMA或者在mongod中禁用UNMA
l 確保存儲數據文件的塊設備的readahead屬性相對較小，因為大部分讀取都是非順序的。比如，可以把readahead設置成32（16KB）。
l 使用NTP這樣的同步伺服器保證各個主機之間的時間同步，這在分片集群中尤其重要。在虛擬機上部署的MongoDB同樣需要註意這個問題。
Linux系統可以控制每個進程和每個用戶上打開的文件以及資源的數量。預設的設置堆MongoDB系統是足夠用的。通常情況下，一個操作系統、虛擬機和容器上應該只運行MongoDB進程以保證MongoDB不用跟其他進程進行資源搶奪。
由於每個部署的系統對資源的要求都是獨一無二的，以下的幾個推薦配置可以用在mongod和mongos實例中。使用ulimit屬性來應用這些設置：
l -f（文件大小）：不限制
l -t（CPU時間）：不限制
l -v（虛擬記憶體）：不限制
l -n（打開文件數）：大於20000
l -m（記憶體大小）：不限制
l -u（進程數量）：大於20000
使用ulimit為MongoDB進行資源限制的更過信息可以參考MongoDB文檔中Linux ulimit Settings章節
網路
管理員需要永遠保證MongoDB運行在一個可信任的網路環境中，防止未知應用對資料庫進行訪問。與MongoDB系統進行交互的預知進程是有限的：應用伺服器、監控進程、以及運行在複製集和分片集群上的其他MongoDB進程。
MongoDB的進程預設都是與系統上的網路介面進行綁定的。如果你的系統不止一個網路介面，你就需要把你的MongoDB進程與私有介面或者內部網路介面進行綁定。
MongoDB Security Tutorials章節中有關於MongoDB預設埠數量、MongoDB防火牆設置、VPN以及相關話題的更多詳情。本手冊後面的內容也會提及系統部署的安全方面的最佳實踐。
在虛擬機上運行時，使用半虛擬化驅動程式來實現優化的網路和存儲介面，以最小的開銷在虛擬機和管理程式之間傳遞指令
集群內網路壓縮
作為分散式資料庫系統，MongoDB依賴於查詢路由與複製集節點指點高效的網路傳輸。MongoDB3.4引進了一種新的方式對集群之間的信息往來進行網路壓縮。基於snappy壓縮演算法，網路壓力可以被壓縮到70%以上，不僅可以在寬頻有限的環境中提高性能，還能減少網路消耗。
壓縮功能預設是關閉的，可以設置networkMessageCompressors為snappy以打開壓縮功能。壓縮和解壓縮會增加CPU的負載，一般會占用百分之幾的負載。在CPU資源比較足但是寬頻成為性能瓶頸的環境中使用壓縮功能是非常理想的。
生產驗證的建議
關於操作系統、文件系統、存儲設備以及其他相關話題的配置的最新意見可以參考MongoDB Production Notes。
持續可用性
正常操作情況下，MongoDB系統的表現會根據性能以及功能需求來確定。但是，總會有一些必然的故障或者意外的操作會以不同的方式對系統造成影響，硬體、網卡、電源以及其他的硬體組間都存在故障的風險。這些風險可以通過硬體冗餘來避免。同時，MongoDB系統也可以在軟體層面實現數據冗餘性。
日誌
MongoDB通過預寫日誌操作以實現存儲引擎的快速災備恢復以及持久性。伺服器宕機的情況下，日誌系統可以在系統重啟後對數據進行恢復。
日誌系統的具體表現取決於配置的存儲引擎：
l WiredTiger存儲引擎能保證在兩個檢查點之間寫操作可以持久性寫到到硬碟中。WiredTiger引擎使用檢查點實現數據刷入硬碟中，預設情況下，每60秒或者寫入數據達到2G時，就會進行一次刷入操作。所以，如果不開啟日誌屬性的話，WiredTiger會丟失60秒以上的寫入數據，儘管這些風險可以通過複製集來避免。
l MMAPv1預設每100ms就會把數據寫入到硬碟中，如果日誌系統部署在分立的設備中，則預設是30ms。除了可以保證持久性，日誌功能還可以防止系統在未知宕機的情況下的數據腐敗。MMAPv1預設是開啟日誌功能的。生產環境中都應該開啟日誌功能。
WiredTiger和MMAPv1共有的一個特性是壓縮功能，以減少存儲容量。
為了額外的保證，管理員可以配置日誌寫關註，這樣MongoDB只會在數據寫入日誌後才確認。
數據冗餘
MongoDB使用本地複製集會維護多個數據副本。建議用戶使用複製集防止數據系統掉線。MongoDB中的複製集故障轉移是全自動的，不需要人工進行干預。
複製集由多個複製集成員組成。任何時候，一個成員充當主節點，其他成員充當此節點。如果主節點由於各種原因（比如主機宕機）出現故障，其中的一個次節點會自動被選舉為主節點並接受所有的寫入操作。
選舉的過程是由複雜的演算法控制的，保證所有次節點中最合適的成員被推舉為主節點以較少不必要的故障風險。選舉演算法包含很多變數，包括分析歷史數據確認哪些複製集成員從主節點哪裡過去到最新的數據，心跳以及連接狀態，還有其他用戶定義的優先順序。例如，管理員可以設置，次數據中心的副職及成員只有在主數據中心的主節點故障後才能被推舉為主節點的候選人。一旦新的主節點被選舉出來，其餘的次節點就會自動的從新的主節點同步數據。如果之前的主節點重新上線了，會發現自己已經不再是主節點，並充當次節點的角色。
MongoDB複製集中的成員是可配置的，複製集成員越多，就可以為系統提供越大的保障。一個節點宕機，系統還是會正常運行。遇到故障後，DBA和系統管理員應該及時恢復或者替換有故障的設備以減輕系統暫時的彈性壓力。
多數據中心複製集
MongoDB副本集允許在數據中心內部和跨數據中心進行靈活的部署設計，從而解決伺服器，機架和區域級別的故障。如果MongoDB複製集是跨多個機房部署的，則遇到自然或人為災難，單個機房的故障可以在不宕機的情況下得到解決。
寫關註
MongoDB中，當把數據寫入資料庫中時，管理員可以使用寫關註這個功能保證數據的持久性，並可以指定不同的級別。下麵介紹的這幾個選項可以在每個鏈接、每個資料庫、每個集合甚至每個操作中進行配置。
l Write Acknowledged:這是寫關註預設的配置。Mongo會去確認寫操作的執行結果，並把網路、主鍵重覆、文檔重覆以及其他異常反饋給客戶端。
l Journal Acknowledged：只有數據被寫入到主節點的日誌後，mongod才會確認寫操作的執行結果。這個配置能保證mongod在意外宕機的情況下寫操作仍然可以寫入到磁碟中。
l Replica Acknowledged：也可以等到數據同步到其他複製集成員後再確認，並且支持指定到具體那幾個成員中。這就可以保證寫操作寫入到此節點的日誌中。由於複製集成員可以在一個數據中心跨機架部署，也可以跨機房部署，所以把寫操作執行到其他複製集成員中可以提供極大的耐用性。
l Majority：這種寫關註的配置會等數據應用到複製集中的大多數成員中後，才確認。也能保證數據寫入這些複製集成員的日誌中。
l Data Center Awareness：使用標簽集，可以創建複雜的策略保證數據可以寫入具體的複製集組合中。比如，你可以創建這樣一條策略，要求數據至少寫入兩個洲的三個數據中心才行，或者一個數據中心分佈在不同機架的兩個伺服器中。詳情見Data Center Awareness。
複製集讀選項
預設情況下，讀取是從主節點讀取的，這樣能保證一致性。如果系統讀取量比較大，建議使用MongoDB的自動分片功能，把讀取操作分散到多個主節點上。
有些應用的複製集可以提高MongoDB系統的容錯性。比如，分析系統以及商務智能系統這類的應用就可以在次節點上進行查詢操作，這樣就可以較少主節點上的負載，實現在單個系統中提供業務和分析操作。還可以直接把讀取操作路由到離用戶最近的複製集上，對於全球分佈部署的應用來說就可以有效的減少讀取延遲。
primaryPreferred配置選項是個非常實用的選項，它的作用就是只有在主節點故障時把讀取路由到次節點上。在故障轉移的過程中實現讀取的可持續性。
讀關註
為保證數據的隔離性和一致性，把readConcern配置為majority就可以保證，只有主節點的數據被寫到大多數複製集成員後，應用才能讀取到主節點的數據，並且在故障的時候不能回滾。
MongoDB3.4的讀關註增加了“linearizable”屬性，這個屬性保證當次節點被暫時選為主節點的時候，主節點的數據不會被回滾。配置這個屬性會在一定程度上影響系統的延遲性，因此，需要設置一個maxTimeMS值，保證操作不會長時間執行。
MMAPv1中，沒有readconcern這個屬性。
主節點選舉
主節點不可達的時候，如果你使用了read preperence屬性而不是預設的primary屬性，那麼系統任然可以讀取數據，但是不能寫入數據到複製集中，除非出現以下情況：
l 主節點恢復
l 舉行選舉後，其中一個此節點選舉為主節點
如果主節點只是短時間內不可達（比如，短暫的網路故障），那麼最好的方式就是等待主節點重新恢復故障。然而，如果主節點在短時間內恢復不了，那麼最好是系統可以快速選舉出新的主節點接管主節點的工作。很顯然，這些情況在實際中都需要權衡。
MongoDB3.2引進了一種增強的複製集協議，可以在主節點出現故障後快速的實現服務恢復，同時保證系統持久性。增強的複製集協議擴展了Raft一致演算法，增強了系統部署的靈活性，同時保證對原有複製集結構的相容性。尤其是，這種協議支持replica set arbiters, replica set member election priorities。
增強協議通過優化演算法，可以在主節點故障時快速的選舉中合適的次節點。故障轉移的時間又很多因素決定，比如網路延遲。避免系統出現不必要的故障是非常重要的，使用electionTimeoutMillis參數可以調整故障恢復時系統的表現：
l 參數值越大，故障恢復時間越長，但是可以減小系統對網路延遲的敏感性以及主節點上的負載
l 參數值越小，故障恢復時間越短，但是會增加系統對網路延遲的敏感性以及主節點上的負載。
MongoDB系統擴展
用分片進行水平擴展
MongoDB使用分片技術來實現資料庫水平擴展的目的，分片對應用來說是透明的，不可見的。分片可以把系統的數據分佈在多個複製集中，通過自動數據平衡功能，MongoDB保證在數據體積增大或者集群擴大或者減少的情況下，數據可以平均的分佈在各個分片伺服器中。MongoDB分片的好處就是在不增加應用的複雜性的前提下，可以突破單個伺服器RAM和I/O的瓶頸限制。
MongoDB提供三種分片策略以支持多樣化的查詢模式：
l Range-based 分片：系統會根據片鍵把文檔分配到不同的分片伺服器上。片鍵值相似的文檔有可能會被分配到同一個分片伺服器上。這種方式適合於那些基於範圍的查詢的應用。
l Hash-based 分片：在這種分片方式下，文檔會根據片鍵的MD5哈希值平均的分配到各個分片伺服器上。片鍵值大小差不多的文檔一般不會被分配在位置相鄰的分片伺服器中。這種方法保證了在分片之間均勻分佈的寫入 - 只要分片密鑰具有較高的基數 - 使其成為寫密集型工作負載的最佳選擇。
l Zones:MongoDB Zones可以精確控制物理存儲數據的位置，適應很多部署場景，比如地理位置、硬體以及配置，或者應用。管理員可以修改片鍵範圍來不斷的完善數據存放規則，MongoDB也會自動的把數據遷移到新的域中。MongoDB3.4添加了新的幫助功能以及Ops Manager and Cloud Manager中額外的選項以便配置Zones，用以管理龐大的系統部署。
儘管分片的功能強大，但是同時也會為系統部署帶來一定的複雜性，並且它也會對基礎架構提出一定的需求。所以，只要在需要的時候才可以根據實際的需求對系統進行分片。
在如下幾個場景下用戶就應該考慮使用分片。
l RAM有限制：系統活躍工作集以及索引如果超過系統RAM的最大容量，則可以考慮使用分片
l 硬碟I/O有限制：系統有大量的寫入操作，並且系統寫入速度遠遠不能滿足需求或者I/O已經限制了數據刷入硬碟的速度。
l 存儲限制：數據集的容量超過系統單個節點所能承受的壓力。
l 對地理位置有需求：數據需要被分配到指定的數據中心以實現讀寫的低延遲。或者，創建多溫度存儲設施，把熱數據和冷數據分離開。
如果遇到上述的場景，或者可能在以後會遇到上述場景的，就應該及時使用分片，不要等到容量已經不夠用的時候在分片。使用分片設計數據模型的時候，需要考慮在那個集合上進行分片，以及使用哪個聯合片鍵。如果系統已經達到了最大容量值，那麼在不影響應用的前提下對系統進行分片是很有挑戰性的。
分片最佳實踐
使用分片時可參考如下實踐:
選擇合適的片鍵：選擇片鍵需要考慮如下三個方面：
- 基數：數據分區預設是由64M的塊來管理的。片鍵基數底（比如用戶的家鄉）會把文檔分散在較小範圍的幾個分片上，這樣可能就需要頻繁的對塊進行重新平衡。所以，片鍵的基數需要大些。
- 寫入分片：數據寫入應該最終分散到所有分片伺服器上。如果片鍵是單調增長的，那麼即使片鍵的基數大，數據也會寫入到單個伺服器上，這樣會產生寫入高峰點。所以片鍵應該最終都分佈開來。
- 查詢隔離：查詢應該被指定到具體的分片上以最大化系統的擴展性。如果查詢不能分離到具體的分片上，那麼所有的片鍵會在一種分散/集中的模式下進行查詢，這樣查詢的效率很低。
在需要之前就提前進行容量擴展：在系統過載前對系統進行容量擴充，那麼集群更易於維護及管理。
至少運行三台配置伺服器以便保證系統的冗餘性：生產環境至少運行三台配置伺服器，並且伺服器放在可以應對各種故障的網路拓撲里。
使用複製集：複製集和分片是完全可以相容的。所有的部署都應該使用複製集，有需要的情況下再使用分片。分片允許資料庫使用多個伺服器以便滿系統的冗餘性。複製集則可以在伺服器間、服務集群間甚至數據中心之間維護多份數據樣本。
使用多個mongos實例。
使用最佳實踐實現批量導入：提前把數據分散到多個數據塊中，在寫入過程中不需要進行數據平衡。或者，在批量數據導入的過程中禁用數據平衡器。同樣，使用多個mongos實例平行導入，也能減少壓力。
動態數據平衡
數據導入MongoDB系統後，系統會通過集群中的平衡器這一進程對數據進行動態平衡。平衡器同一時間只會移動文檔中的一個數據塊並且只會在數據塊的容量超過允許值後才進行操作，這樣可以最小化平衡操作對系統造成的影響。當然，也可以禁用平衡器或者對其進行配置使其更小化的影響系統性能。
地理分佈
MongoDB中可以把具體的片鍵範圍分配到具體的物理分片中。Zones分片可以讓管理員控制集群中文檔的地理位置。
系統管理員可以結合複製集、Zones分片、讀偏好以及寫關註這些特性來部署地理分散式集群，這樣用戶可以直接在本地數據中心進行數據讀取。管理員可以把分片集合限制到具體的分片伺服器中，有效的為不同的用戶提供分片服務。比如，我們可以把所有關於USA的數據分配到位於美國的分片伺服器上。
MongoDB管理：規劃、監控、災備恢復
Ops Manager是由開發MongoDB資料庫系統的工程師開發的一款管理工具，也是運行MongoDB的最簡單的一種方式，運營團隊使用Ops Manager可以方便的部署、監控、備份以及擴展MongoDB系統。Ops Manager中的很多功能在MongoDB Cloud Manager服務中也是可用的。Cloud Manager支持數以千計級別的部署。使用MongoDB Enterprise Advanced的組織可以選擇使用Ops Manager或者Cloud Manager。
Ops Manager和Cloud Manager提供了最佳實踐以保證資料庫系統的健康及優化。通過可靠的自動的滑鼠操作或者API來代替繁複的手動操作任務。
l 部署：任何結構任何規模的都可以
l 升級：不宕機，幾分鐘即可完成
l 擴容：應用不下線的前提下完成系統擴容
l 例行性備份：災難是不可預測的，但是在Ops Manager和Cloud Manager中只需要點幾下滑鼠即可實現集群在運行的情況下恢復到任何備份的時間點。
l 性能警告：可支持監控100台以上的節點，為系統提供預警信息。
l Roll Out Indexes：從備節點開始到主節點逐個增加索引，避免增加索引的時候影響應用的性能
l Manage Zones:配置Zones以決定數據存儲在什麼位置
部署、升級
Ops Manager通過安裝在每個伺服器上的代理與伺服器進行數據交互，因此它可以協調MongoDB系統中伺服器的關鍵操作任務。伺服器可以部署在公有雲上也可以部署在私有數據中心。Ops Manager能高效可靠的完成傳統上需要管理員手動完成的操作，比如部署新的集群、系統升級、創建新的備份時間點、遷移索引等等。
Ops Manager能持續的評估系統並做出調整來應對系統中出現的問題。
l 在各個伺服器中安裝Ops Manager代理，也可以通過Chef或者Puppet這樣的配置工具進行安裝。
l 管理員為系統創建一個調整目標或者修改目標（比如系統升級、oplog的大小調整、增加新的分片等）
l 代理周期性檢查Ops Manager服務中心是否有更新，如果有就接受調整指示。
l 代理接受調整指示後會按照指示目標去實現。通過複雜的規則引擎，調整目標改變後，代理會及時調整自己的目標計劃。如果遇到宕機情況比如重大事故或者網路問題，代理就會修改目標計劃，達到一個安全狀態。
l 幾分鐘之後，調整目標系統就會安全可靠的實現。
除了部署新的資料庫系統外，Ops Manager和Cloud Manager可以導入已經存在的MongoDB系統並接管他們的控制權。
除了初始化部署外，Ops Manager和Cloud Manager還可以動態的調整系統容量—增加分片和複製集的數量。其他維護任務，比如MongoDB升級或者調整oplog的大小這些複雜的手動操作，在Ops Manager和Cloud Manager中都可以通過點擊滑鼠來輕鬆實現，並且全部是在不影響業務系統的情況下。
DBA的日常工作需要在生產環境中遷移新的索引。為了最小化影響生產環境，最好是進行滾動索引創建，也就是現在次節點進行操作，再把主節點降為次節點並對其進行索引創建。這些操作可以手動完成，但是在Ops Manager 和Cloud Manager中，這些操作是完全自動化的，減少操作失誤以及發生故障的幾率。
管理員可以直接使用Ops Manager的圖形化界面，也可以從已有的企業工具，比如流行的監控軟體以及架構框架中調用Ops Manager的API介面。
監控、容量規劃
對於MongoDB應用，系統性能和容量規劃都兩個很重要的話題。規劃應該為以下幾方面建立一個基線：數據體積、系統負載、系統性能、系統容量使用率。這些基線應該能反應出你期望的系統在生產環境中所表現的負載。而且要周期性的拿出來作為你修改用戶數量、應用特性、性能以及其他配置的參考數據。
基線可以幫助你瞭解系統何時按照設計的方式運行，何時會出現影響用戶體驗的問題。監控系統的不同尋常的變現可以避免系統出現問題。下麵會介紹監控MongoDB常用的監控工具以及需要監控的不同方面。
使用Ops Manager 和Cloud Manager對系統進行監控
Ops Manager可以監控100多個關鍵資料庫以及系統的監控指標，包括操作計數器、記憶體、CPU、複製集狀態、打開連接數、隊列以及節點狀態，並且可以使用圖標、自定義儀錶盤展示，還可以自動發出告警。
各種指標可以在瀏覽器中進行處理、聚合、報警提示以及視圖化展示，使管理員輕鬆的掌控MongoDB的實時監控狀況。查看的視圖可以添加明確的許可權控制，不同的項目團隊只能看自己的應用，系統管理員可以查看所有的組織的內容。
MongoDB3.4中系統每隔10秒就可以收集數據，之前的系統則是每隔60秒。
歷史性能數據可以用來創建操作基線以供容量規劃使用。通過Ops Manager的API介面與已有的健康工具進行集成也很方便。
監控指標很多時，管理員可以自定義告警。告警的通知方式也多種多樣，有SMS、郵件、webhooks、Flowdock, HipChat, 和Slack，或者集成到PagerDuty這樣的管理系統中，這樣可以在小問題升級成故障前主動預警潛在的問題。
使用Cloud Manager時，MongoDB的技術支持工程師也可以獲取到監控數據，省去不同團隊之間發送日誌文件的過程，快速解決問題
硬體監控
Munin node是一款開源軟體，可以監控磁碟以及RAM利用率等指標。Ops Manager可以從Munin node中收集監控數據，並且可以把Ops Manager中可用的數據提供給Munin node。由於每個應用以及部署都是獨一無二的，建議用戶為所有監控指標設置合理的監控閾值。
Mongotop
mongotop是MongoDB自帶的一個功能組件。可以跟蹤並展示MongoDB集群當前讀寫性能。mongotop可以在集合層面提供統計數據。
Mongostat
mongostat是MongoDB自帶的一個功能組件。能展示MongoDB系統中所有伺服器的實時分析數據。mongostat可以綜合展示系統所有操作，比如更新、插入操作的數量、缺頁、索引缺失以及系統其它的健康因素。mongostat類似於Linux操作系統中的vmstat工具。
MongoDB Compass
對輸出的文字信息進行解析能快速的解決查詢性能問題。MongoDB Compass可以把mongotop和mongostat生成的實時數據圖形化展示，允許DBA生成伺服器狀態和查詢性能的即時快照。
其他常用工具
對於很多常用的開源監控工具，MongoDB都有可用的插件。如果MongoDB配置的存儲引擎是WiredTiger,請確保下列工具使用的是WiredTiger編譯過的驅動：
l Nagios
l Ganglia
l Cacti
l Scout
l Zabbix
l Datadog
Linux工具
可以用來監控MongoDB系統其他方面性能的常用工具如下：
l iostat:為存儲子系統提供使用情況分析數據
l vmstat:監控虛擬記憶體的使用情況
l netstat:監控網路狀態
l sar:周期性獲取系統的趨勢數據並存儲下來方便分析
Windows工具
Windows系統中，性能監控器對監控系統狀態是個不錯的選擇。
監控相關
Ops Manager 和Cloud Manager可以監控資料庫指定的指標，包括頁面錯誤、ops計數、隊列長度、連通性以及複製集的狀態。每個監控指標都可以設定告警，在系統出現問題之前主動的給管理員提供預警信息。
應用日誌和資料庫日誌
應用日誌和資料庫日誌是系統排錯的主要依據。有時候為了確認系統的故障是否是由應用引起的，就需要把應用日誌和資料庫日誌關聯起來。比如，用戶寫入高峰期會增加MongoDB系統寫入容量，就會使底層存儲過載。如果不把應用日誌和資料庫日誌關聯起來排錯，遇到上述問題很可能認為是MongoDB的運行的程式引起的，而不會想到是應用引起的這個問題。
如果遇到錯誤或者意外的情況發生，提技術case的時候應該同時提供日誌信息。主次節點以及mongod伺服器、配置伺服器上的日誌信息會幫助技術支持軟對快速的定位的問題的發生原因。
