如果你已經完成了自己新的MongoDB應用程序的開發，并且現在正準備將它部署進產品中，那么你和你的運營團隊需要討論一些關鍵的問題：

• 最佳部署實踐是什么？
• 為了確保應用程序滿足它所必須的服務層次我們需要監控哪些關鍵指標？
• 如何能夠確定添加分片的時機？
• 有哪些工具可以對數據庫進行備份和恢復？
• 怎樣才能安全地訪問所有新的實時大數據？

本文介紹了硬件選擇、擴展、HA和監控。在查看詳細信息之前，首先讓我們處理一個最常見的問題：

部署MongoDB和部署RDBMS有什么不同？

你會發現MongoDB作為一個文檔數據庫，它和你已經熟悉的關系型數據庫分享了很多同樣的概念、操作、策略和過程。監控、索引、調整和備份等內容的流程和最佳實踐可以應用到MongoDB。同時如果你想要開始自己的培訓，那么可以從 MongoDB大學 中獲取到來自于開發者和DBA的免費在線課程。

系統性能和容量規劃是兩個重要的主題，任何部署都需要處理這兩個問題，無論是RDBMS還是NoSQL數據庫都是如此。作為規劃的一部分我們應該對數據卷（volume）、系統負載、性能（吞吐量及延遲時間）和容量利用建立基線。這些基線應該反映你對數據庫在產品環境中執行的工作負載的期望，它們應該隨著用戶數、應用程序功能、性能SLA或者其他因素的變化定期地調整。

基線將幫助你理解系統哪些時候是按照設計運行的，哪些時候可能會影響用戶體驗質量或者其他決定性系統因素的問題開始浮現。

下面將會討論關鍵的部署要素，包括硬件、擴展和HA，同時還會討論為了維持最佳的系統性能你應該監控哪些內容。

清楚自己的工作集

在為部署MongoDB優化硬件預算的時候，RAM應該是或者接近于列表的第一位。

為了實現低延遲的數據庫操作MongoDB中廣泛使用了RAM。在MongoDB中，所有的數據都是通過內存映射文件讀取和操作的。從內存中讀取數據是使用納秒來度量的，而從磁盤中讀取數據則是使用毫秒度量的，所以從內存中讀取數據幾乎比從磁盤中讀取要快了十萬倍。

在正常操作期間最頻繁訪問的數據和索引的集合稱為工作集，在理想的情況下它們應該在RAM中。工作集可能是整個數據庫的一小部分，例如最近的事件所關聯的應用程序數據或者最常訪問的熱門產品。

MongoDB試圖訪問數據時發生的頁面錯誤并不會被加載到RAM中。如果有空閑內存，那么操作系統將定位到磁盤上的頁面并將它們直接加載到內存中。但是如果沒有空閑內存，那么操作系統必須將內存中的一個頁面寫入磁盤，然后將被請求的頁面讀取到內存中。這個流程比訪問已經存在于內存中的數據要慢。

有些操作可能會在不經意間從內存中清除大量的工作集，這樣會對性能產生嚴重影響。例如，對于一個瀏覽數據庫中所有文檔的查詢而言，如果數據庫比服務器上的RAM大，那么將會導致文檔被讀入內存而工作集被寫出到磁盤。在項目的模式設計階段為自己的查詢定義合適的索引將會極大地降低這種風險發生的可能性。MongoDB 說明 操作能夠為查詢計劃和索引的使用提供信息。

MongoDB 服務狀態 命令 中包含了一個有用的輸出： 工作集 文檔 ，它提供了一個MongoDB實例工作集的估算大小。運營團隊可以按照給定的時間跟蹤實例訪問的頁面數，包括工作集中最舊的文檔到最新的文檔之間的運行時間。通過跟蹤這些指標我們能夠發現什么時候工作集會接近現在的RAM限制從而積極地采取行動確保系統是可擴展的。

MongoDB管理服務 和 mongostat 能夠幫助用戶監控內存的使用情況，下面我們將會對此進行詳細地討論。

存儲和磁盤I/O

MongoDB不需要共享存儲（例如存儲區域網絡）。MongoDB能夠使用本地附加的存儲和固態硬盤（SSD）。

MongoDB中的大部分磁盤訪問模式并沒有順序屬性，這樣做的結果便是客戶可以通過使用SSD獲得巨大的性能收益。我們已經觀察到使用SATA SSD和PCI獲得的良好結果和強大的性能。商業SATA旋轉驅動器可以媲美成本更高的旋轉驅動器，這得益于MongoDB的非順序訪問模式：應該更有效地使用預算將其用于更多的RAM或者SSD上，而不是更多地用于昂貴的旋轉驅動器上。

在數據文件受益于SSD的同時，MongoDB的日記文件由于其自身的高順序的寫屬性成為了快速常規磁盤的一個很好的候選。

大多數MongoDB部署應該使用RAID-10。RAID-5和RAID-6沒有提供足夠的性能。RAID-0提供了很好的寫性能，但是讀性能有限，容錯能力也不足。部署的MongoDB可以通過副本集（下面將會討論）提供很強的數據可用性，同時用戶應該考慮使用RAID和其他因素滿足想要的SLA可用性。

雖然我們應該設計MongoDB系統讓它的工作集適合于內存，但是磁盤I/O依然是一個關鍵的性能考慮。MongoDB會定期地將寫操作刷新到磁盤并提交到日記，所以在寫負載較重的時候基礎的磁盤子系統可能會變得不堪重負。iostat命令可以用于顯示高磁盤利用率和過多的寫隊列。

CPU選擇——速度還是內核？

MongoDB的性能通常不會綁定到CPU上。因為MongoDB很少會遇需要利用大量內核的工作負載，比起時鐘速度較慢的多核服務器最好的選擇是有更快的時鐘速度。

無論是什么系統，測量CPU的利用率都是非常重要的。如果觀察到CPU的利用率很高但是并沒有出現磁盤飽和或者頁面錯誤這樣的其他問題，那么系統中可能會存在不尋常的問題。例如，一個存在無限循環的MapReduce工作或者一個沒有建立良好索引就對工作集中的大量文檔進行排序和過濾的查詢都可能會導致CPU利用率的飆升，但是它們卻不會引發磁盤系統問題或者頁面錯誤。用于監控CPU利用率的工具將在下面介紹。

擴展數據庫——何時擴展和如何擴展？

MongoDB通過一種稱為 Sharding 的技術提供了水平擴展能力。Sharding能夠在多個物理分區（稱為片）之間分發數據。Sharding可以讓MongoDB的部署解決單個服務器的硬件限制而不需要增加應用程序的復雜性，解決的硬件限制包括RAM和磁盤I/O的瓶頸。

MongoDB 自動分片和應用程序的透明度

在系統資源變得有限之前實現分片是非常容易的，因此容量規劃和主動監控在需要成功地擴展應用程序時是非常重要的元素。

在下面的場景中用戶應該考慮部署一個分片的MongoDB集群：

• RAM 限制： 系統活動工作集的大小很快就會超過系統RAM的最大容量。
• 磁盤 ?I/O 限制： 系統有大量的寫活動，但是操作系統寫數據的速度不夠快，無法滿足需求；同時/或者I/O帶寬限制了數據寫入磁盤的速度。
• 存儲限制： ? 數據集接近或者超過了系統中的單個節點的存儲容量。

Sharding的目標之一就是在多臺服務器之間一致地分發數據。如果服務器資源的利用率并不是近似地相等，那么可能會存在引發調度錯誤的潛在問題。例如，選擇一個糟糕的分片鍵可能會導致不平衡的數據分發。在這種情況下，即便不是所有的但是大部分查詢也會被導向到正在管理數據的那個單獨的MongoDB。

另外，MongoDB可能會試圖重新分發文檔從而在服務器之間實現更加理想的平衡。雖然重新分發最終會實現一種更加令人滿意的文檔分發，但是有大量與重新平衡數據相關的工作，這些工作本身就有可能會產生影響導致無法實現預期性能的SLA。

通過運行 db.currentOp() 命令，你將能夠了解集群現在正在執行哪些工作，包括跨分片的文檔再平衡。

為了確保數據能夠在集群中的所有分片間均勻地分發，選擇一個優秀的分片鍵是非常重要的。MongoDB文檔中包含了一個關于 如何選擇優秀分片鍵的教程 。

MongoDB復制集的高可用性

MongoDB使用本地復制維護 復制集 之間的多個數據副本。復制集可以通過發現錯誤（服務器、網絡、OS或者數據庫）和自動化故障修復避免停機時間。推薦的做法是：所有的MongoDB部署都應該配置復制。

（單擊放大圖片）

使用MongoDB復制集自恢復

對主節點數據庫的修改操作會通過名為 oplog 的日志被復制到其他二級節點上。oplog包含了一個排序的冪等操作的集合，該集合中的操作會在二級節點上重放。oplog的大小是可配置的，默認是可用磁盤空間的5%。

正如下面的圖表所闡述的，可以通過定位副本為服務器、機架、數據中心故障和網絡分區提供容錯性。

（單擊放大圖片）

復制延遲是作為正常運行的一部分來監控的。它表示的是將主節點上的一個寫操作復制到二級節點上所花費的時間。一定的延遲是正常的，但是如果復制延遲增長，則可能會引發問題。復制延遲產生的典型原因包括網絡延遲、連接問題和磁盤延遲（例如二級節點的吞吐量劣于主節點）。

復制狀態和復制延遲可以通過 replSetGetStatus 命令重新恢復。

日志概述

作為所有部署的一部分，應該監控應用程序和數據庫的日志以便發現錯誤并查看其他的系統信息。將應用程序和數據庫的日志關聯起來是非常重要的，因為這樣才能決定應用程序中的活動最終是否需要對系統中的其他問題負責。例如，用戶寫入峰值可能會增加寫入MongoDB的容量，這反過來可能會壓垮下面的存儲系統。如果沒有應用程序和數據庫日志的關聯，那么可能要花費更多的時間才能夠確定寫入容量的增長是應用程序的問題而不是運行在MongoDB中的某些進程的問題。

MongoDB 監控工具

MongoDB包含了各種監控工具，讓你能夠積極地管理系統的運行和性能。

MongoDB管理服務 (MMS)

MongoDB管理服務（MMS） 提供了云監控和備份服務，幫助用戶優化集群、解決性能問題、減輕運維風險。MMS備份服務將在以后的文章中討論。

MMS監控支持圖表、自定義儀表盤和自定義警告。MMS僅需要最低限度的安裝和配置。用戶在所有的 MongoDB 實例上安裝一個本地代理，該代理會跟蹤與數據庫使用情況相關的數百個關鍵的健康指標，包括：

• 操作數（Op Counters）—每秒鐘執行的操作的數量
• 內存（Memory）—MongoDB正在使用的數據量
• 鎖百分比（Lock Percent）—寫鎖消耗時間的百分比
• 后臺刷新（Background Flush）—將數據刷新到磁盤消耗的平均時間
• 連接（Connections）—MongoDB當前打開的連接的數量
• 隊列（Queues）—等待運行的操作的數量
• 頁面錯誤（Page Faults）—磁盤的頁面錯誤數
• 復制（Replication）—主節點操作日志的長度以及復制延時
• 日志（Journal）—寫入日志的數據量

（單擊放大圖片）

這些指標會被安全地報告給MMS服務，告訴它它們是在哪里處理、聚合、通知的，并在瀏覽器中可視化顯示。用戶能夠容易地根據各種性能指標了解他們集群的健康狀況。

硬件監控

Munin node 是一個開源軟件程序，它可以監控硬件并報告磁盤和RAM的使用情況這樣的指標。MMS能夠收集Munin node產生的這些數據，并在MMS儀表盤中將這些數據和其他數據一起展現給用戶。因為每一個應用程序和部署都是唯一的，所以用戶應該為磁盤利用率的峰值、網絡活動的主要變化和平均查詢長度/響應時間的增長創建警報。

數據庫分析工具

MongoDB提供了一個 性能分析工具 ，該工具能夠記錄數據庫操作相關的細粒度信息。分析工具可以記錄所有事件的信息，也能夠只記錄那些持續時間超出了配置閾值的事件的信息。分析數據存儲在一個固定集合中，用戶能夠很容易地從中搜索相關的事件——查詢這個集合可能比嘗試著去解析日志文件更加容易。

其他的監控工具

有各種各樣的監控工具讓你能夠從其他的方面深入理解MongoDB系統。

• mongotop ?是隨MongoDB提供的一個工具，它能夠跟蹤并報告一個MongoDB集群當前的讀、寫活動。
• mongostat ?是隨MongoDB提供的另一個工具，它為所有的操作提供了一個全面概覽，包括更新、插入的計數，頁面錯誤、索引的丟失情況以及很多其他的關系到系統健康的重要指標。
• Iostat、vmstat、netstat和sar這樣的Linux工具也能為深入探索MongoDB系統提供有價值的信息。
• 對于Windows環境上的用戶而言，性能監控器（Performance Monitor，一個Microsoft管理控制臺單元）是一個非常有用的工具，可以用來測量各種指標。

如果想要獲取更多與監控工具和監控內容相關的信息，可以查看MongoDB文檔中的 監控數據庫系統 頁面。

配置MongoDB

用戶應該將配置選項存儲到MongoDB的配置文件中。sysadmins能夠通過這種方式在整個集群之間實現一致性的配置。配置文件支持MongoDB命令行所支持的所有選項。安裝和升級應該通過流行的工具（例如Chef和Puppet）自動完成，同時MongoDB社區還提供并維護了這些工具的示例腳本。

一個基礎的MongoDB配置文件類似于下面的內容：

• fork = true
• bind_ip = 127.0.0.1
• port = 27017
• quiet = true
• dbpath = /srv/mongodb
• logpath = /var/log/mongodb/mongod.log
• logappend = true
• journal = true

你能夠通過文檔了解到與 MongoDB配置選項 相關的更多內容。在MongoDB文檔 產品說明 頁面上還維護著針對操作系統、文件系統、存儲設備和其他系統相關主題特定配置的最新建議。

結論

在本文中我們介紹了哪些用于部署關系型數據庫的概念、操作和流程可以被直接地應用到MongoDB上，同時還介紹了硬件選擇和部署及監控的最佳實踐。另外，有關于所有這些主題的詳細討論可以從 MongoDB操作指南 （一個.pdf文件）中獲取。

關于作者

Mat Keep ?(@matkeep) 是MongoDB產品營銷團隊的一員，負責為MongoDB的產品和服務構建愿景、定位和內容，同時也負責對市場趨勢和客戶需求進行分析。在就職于MongoDB之前，Mat是Oracle公司的產品管理總監，負責MySQL數據庫在Web、電信行業、云和大數據方面的應用。在這之后他還在技術供應商和面向最終用戶的公司中從事過一系列的工作，包括銷售、商業開發與分析、程序員。

查看英文原文 ： Preparing for Your First MongoDB Deployment: Capacity Planning and Monitoring

查看中文原文： 為首次部署MongoDB做好準備：容量計劃和監控

為首次部署MongoDB做好準備：容量計劃和監控