如果你已經(jīng)完成了自己新的MongoDB應(yīng)用程序的開發(fā)，并且現(xiàn)在正準(zhǔn)備將它部署進(jìn)產(chǎn)品中，那么你和你的運(yùn)營團(tuán)隊(duì)需要討論一些關(guān)鍵的問題：

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

本文介紹了硬件選擇、擴(kuò)展、HA和監(jiān)控。在查看詳細(xì)信息之前，首先讓我們處理一個(gè)最常見的問題：

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

你會(huì)發(fā)現(xiàn)MongoDB作為一個(gè)文檔數(shù)據(jù)庫，它和你已經(jīng)熟悉的關(guān)系型數(shù)據(jù)庫分享了很多同樣的概念、操作、策略和過程。監(jiān)控、索引、調(diào)整和備份等內(nèi)容的流程和最佳實(shí)踐可以應(yīng)用到MongoDB。同時(shí)如果你想要開始自己的培訓(xùn)，那么可以從 MongoDB大學(xué) 中獲取到來自于開發(fā)者和DBA的免費(fèi)在線課程。

系統(tǒng)性能和容量規(guī)劃是兩個(gè)重要的主題，任何部署都需要處理這兩個(gè)問題，無論是RDBMS還是NoSQL數(shù)據(jù)庫都是如此。作為規(guī)劃的一部分我們應(yīng)該對(duì)數(shù)據(jù)卷（volume）、系統(tǒng)負(fù)載、性能（吞吐量及延遲時(shí)間）和容量利用建立基線。這些基線應(yīng)該反映你對(duì)數(shù)據(jù)庫在產(chǎn)品環(huán)境中執(zhí)行的工作負(fù)載的期望，它們應(yīng)該隨著用戶數(shù)、應(yīng)用程序功能、性能SLA或者其他因素的變化定期地調(diào)整。

基線將幫助你理解系統(tǒng)哪些時(shí)候是按照設(shè)計(jì)運(yùn)行的，哪些時(shí)候可能會(huì)影響用戶體驗(yàn)質(zhì)量或者其他決定性系統(tǒng)因素的問題開始浮現(xiàn)。

下面將會(huì)討論關(guān)鍵的部署要素，包括硬件、擴(kuò)展和HA，同時(shí)還會(huì)討論為了維持最佳的系統(tǒng)性能你應(yīng)該監(jiān)控哪些內(nèi)容。

清楚自己的工作集

在為部署MongoDB優(yōu)化硬件預(yù)算的時(shí)候，RAM應(yīng)該是或者接近于列表的第一位。

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

在正常操作期間最頻繁訪問的數(shù)據(jù)和索引的集合稱為工作集，在理想的情況下它們應(yīng)該在RAM中。工作集可能是整個(gè)數(shù)據(jù)庫的一小部分，例如最近的事件所關(guān)聯(lián)的應(yīng)用程序數(shù)據(jù)或者最常訪問的熱門產(chǎn)品。

MongoDB試圖訪問數(shù)據(jù)時(shí)發(fā)生的頁面錯(cuò)誤并不會(huì)被加載到RAM中。如果有空閑內(nèi)存，那么操作系統(tǒng)將定位到磁盤上的頁面并將它們直接加載到內(nèi)存中。但是如果沒有空閑內(nèi)存，那么操作系統(tǒng)必須將內(nèi)存中的一個(gè)頁面寫入磁盤，然后將被請(qǐng)求的頁面讀取到內(nèi)存中。這個(gè)流程比訪問已經(jīng)存在于內(nèi)存中的數(shù)據(jù)要慢。

有些操作可能會(huì)在不經(jīng)意間從內(nèi)存中清除大量的工作集，這樣會(huì)對(duì)性能產(chǎn)生嚴(yán)重影響。例如，對(duì)于一個(gè)瀏覽數(shù)據(jù)庫中所有文檔的查詢而言，如果數(shù)據(jù)庫比服務(wù)器上的RAM大，那么將會(huì)導(dǎo)致文檔被讀入內(nèi)存而工作集被寫出到磁盤。在項(xiàng)目的模式設(shè)計(jì)階段為自己的查詢定義合適的索引將會(huì)極大地降低這種風(fēng)險(xiǎn)發(fā)生的可能性。MongoDB 說明 操作能夠?yàn)椴樵冇?jì)劃和索引的使用提供信息。

MongoDB 服務(wù)狀態(tài) 命令 中包含了一個(gè)有用的輸出： 工作集 文檔 ，它提供了一個(gè)MongoDB實(shí)例工作集的估算大小。運(yùn)營團(tuán)隊(duì)可以按照給定的時(shí)間跟蹤實(shí)例訪問的頁面數(shù)，包括工作集中最舊的文檔到最新的文檔之間的運(yùn)行時(shí)間。通過跟蹤這些指標(biāo)我們能夠發(fā)現(xiàn)什么時(shí)候工作集會(huì)接近現(xiàn)在的RAM限制從而積極地采取行動(dòng)確保系統(tǒng)是可擴(kuò)展的。

MongoDB管理服務(wù) 和 mongostat 能夠幫助用戶監(jiān)控內(nèi)存的使用情況，下面我們將會(huì)對(duì)此進(jìn)行詳細(xì)地討論。

存儲(chǔ)和磁盤I/O

MongoDB不需要共享存儲(chǔ)（例如存儲(chǔ)區(qū)域網(wǎng)絡(luò)）。MongoDB能夠使用本地附加的存儲(chǔ)和固態(tài)硬盤（SSD）。

MongoDB中的大部分磁盤訪問模式并沒有順序?qū)傩裕@樣做的結(jié)果便是客戶可以通過使用SSD獲得巨大的性能收益。我們已經(jīng)觀察到使用SATA SSD和PCI獲得的良好結(jié)果和強(qiáng)大的性能。商業(yè)SATA旋轉(zhuǎn)驅(qū)動(dòng)器可以媲美成本更高的旋轉(zhuǎn)驅(qū)動(dòng)器，這得益于MongoDB的非順序訪問模式：應(yīng)該更有效地使用預(yù)算將其用于更多的RAM或者SSD上，而不是更多地用于昂貴的旋轉(zhuǎn)驅(qū)動(dòng)器上。

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

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

雖然我們應(yīng)該設(shè)計(jì)MongoDB系統(tǒng)讓它的工作集適合于內(nèi)存，但是磁盤I/O依然是一個(gè)關(guān)鍵的性能考慮。MongoDB會(huì)定期地將寫操作刷新到磁盤并提交到日記，所以在寫負(fù)載較重的時(shí)候基礎(chǔ)的磁盤子系統(tǒng)可能會(huì)變得不堪重負(fù)。iostat命令可以用于顯示高磁盤利用率和過多的寫隊(duì)列。

CPU選擇——速度還是內(nèi)核？

MongoDB的性能通常不會(huì)綁定到CPU上。因?yàn)镸ongoDB很少會(huì)遇需要利用大量內(nèi)核的工作負(fù)載，比起時(shí)鐘速度較慢的多核服務(wù)器最好的選擇是有更快的時(shí)鐘速度。

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

擴(kuò)展數(shù)據(jù)庫——何時(shí)擴(kuò)展和如何擴(kuò)展？

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

MongoDB 自動(dòng)分片和應(yīng)用程序的透明度

在系統(tǒng)資源變得有限之前實(shí)現(xiàn)分片是非常容易的，因此容量規(guī)劃和主動(dòng)監(jiān)控在需要成功地?cái)U(kuò)展應(yīng)用程序時(shí)是非常重要的元素。

在下面的場景中用戶應(yīng)該考慮部署一個(gè)分片的MongoDB集群：

• RAM 限制： 系統(tǒng)活動(dòng)工作集的大小很快就會(huì)超過系統(tǒng)RAM的最大容量。
• 磁盤 ?I/O 限制： 系統(tǒng)有大量的寫活動(dòng)，但是操作系統(tǒng)寫數(shù)據(jù)的速度不夠快，無法滿足需求；同時(shí)/或者I/O帶寬限制了數(shù)據(jù)寫入磁盤的速度。
• 存儲(chǔ)限制： ? 數(shù)據(jù)集接近或者超過了系統(tǒng)中的單個(gè)節(jié)點(diǎn)的存儲(chǔ)容量。

Sharding的目標(biāo)之一就是在多臺(tái)服務(wù)器之間一致地分發(fā)數(shù)據(jù)。如果服務(wù)器資源的利用率并不是近似地相等，那么可能會(huì)存在引發(fā)調(diào)度錯(cuò)誤的潛在問題。例如，選擇一個(gè)糟糕的分片鍵可能會(huì)導(dǎo)致不平衡的數(shù)據(jù)分發(fā)。在這種情況下，即便不是所有的但是大部分查詢也會(huì)被導(dǎo)向到正在管理數(shù)據(jù)的那個(gè)單獨(dú)的MongoDB。

另外，MongoDB可能會(huì)試圖重新分發(fā)文檔從而在服務(wù)器之間實(shí)現(xiàn)更加理想的平衡。雖然重新分發(fā)最終會(huì)實(shí)現(xiàn)一種更加令人滿意的文檔分發(fā)，但是有大量與重新平衡數(shù)據(jù)相關(guān)的工作，這些工作本身就有可能會(huì)產(chǎn)生影響導(dǎo)致無法實(shí)現(xiàn)預(yù)期性能的SLA。

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

為了確保數(shù)據(jù)能夠在集群中的所有分片間均勻地分發(fā)，選擇一個(gè)優(yōu)秀的分片鍵是非常重要的。MongoDB文檔中包含了一個(gè)關(guān)于 如何選擇優(yōu)秀分片鍵的教程 。

MongoDB復(fù)制集的高可用性

MongoDB使用本地復(fù)制維護(hù) 復(fù)制集 之間的多個(gè)數(shù)據(jù)副本。復(fù)制集可以通過發(fā)現(xiàn)錯(cuò)誤（服務(wù)器、網(wǎng)絡(luò)、OS或者數(shù)據(jù)庫）和自動(dòng)化故障修復(fù)避免停機(jī)時(shí)間。推薦的做法是：所有的MongoDB部署都應(yīng)該配置復(fù)制。

（單擊放大圖片）

使用MongoDB復(fù)制集自恢復(fù)

對(duì)主節(jié)點(diǎn)數(shù)據(jù)庫的修改操作會(huì)通過名為 oplog 的日志被復(fù)制到其他二級(jí)節(jié)點(diǎn)上。oplog包含了一個(gè)排序的冪等操作的集合，該集合中的操作會(huì)在二級(jí)節(jié)點(diǎn)上重放。oplog的大小是可配置的，默認(rèn)是可用磁盤空間的5%。

正如下面的圖表所闡述的，可以通過定位副本為服務(wù)器、機(jī)架、數(shù)據(jù)中心故障和網(wǎng)絡(luò)分區(qū)提供容錯(cuò)性。

（單擊放大圖片）

復(fù)制延遲是作為正常運(yùn)行的一部分來監(jiān)控的。它表示的是將主節(jié)點(diǎn)上的一個(gè)寫操作復(fù)制到二級(jí)節(jié)點(diǎn)上所花費(fèi)的時(shí)間。一定的延遲是正常的，但是如果復(fù)制延遲增長，則可能會(huì)引發(fā)問題。復(fù)制延遲產(chǎn)生的典型原因包括網(wǎng)絡(luò)延遲、連接問題和磁盤延遲（例如二級(jí)節(jié)點(diǎn)的吞吐量劣于主節(jié)點(diǎn)）。

復(fù)制狀態(tài)和復(fù)制延遲可以通過 replSetGetStatus 命令重新恢復(fù)。

日志概述

作為所有部署的一部分，應(yīng)該監(jiān)控應(yīng)用程序和數(shù)據(jù)庫的日志以便發(fā)現(xiàn)錯(cuò)誤并查看其他的系統(tǒng)信息。將應(yīng)用程序和數(shù)據(jù)庫的日志關(guān)聯(lián)起來是非常重要的，因?yàn)檫@樣才能決定應(yīng)用程序中的活動(dòng)最終是否需要對(duì)系統(tǒng)中的其他問題負(fù)責(zé)。例如，用戶寫入峰值可能會(huì)增加寫入MongoDB的容量，這反過來可能會(huì)壓垮下面的存儲(chǔ)系統(tǒng)。如果沒有應(yīng)用程序和數(shù)據(jù)庫日志的關(guān)聯(lián)，那么可能要花費(fèi)更多的時(shí)間才能夠確定寫入容量的增長是應(yīng)用程序的問題而不是運(yùn)行在MongoDB中的某些進(jìn)程的問題。

MongoDB 監(jiān)控工具

MongoDB包含了各種監(jiān)控工具，讓你能夠積極地管理系統(tǒng)的運(yùn)行和性能。

MongoDB管理服務(wù) (MMS)

MongoDB管理服務(wù)（MMS） 提供了云監(jiān)控和備份服務(wù)，幫助用戶優(yōu)化集群、解決性能問題、減輕運(yùn)維風(fēng)險(xiǎn)。MMS備份服務(wù)將在以后的文章中討論。

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

• 操作數(shù)（Op Counters）—每秒鐘執(zhí)行的操作的數(shù)量
• 內(nèi)存（Memory）—MongoDB正在使用的數(shù)據(jù)量
• 鎖百分比（Lock Percent）—寫鎖消耗時(shí)間的百分比
• 后臺(tái)刷新（Background Flush）—將數(shù)據(jù)刷新到磁盤消耗的平均時(shí)間
• 連接（Connections）—MongoDB當(dāng)前打開的連接的數(shù)量
• 隊(duì)列（Queues）—等待運(yùn)行的操作的數(shù)量
• 頁面錯(cuò)誤（Page Faults）—磁盤的頁面錯(cuò)誤數(shù)
• 復(fù)制（Replication）—主節(jié)點(diǎn)操作日志的長度以及復(fù)制延時(shí)
• 日志（Journal）—寫入日志的數(shù)據(jù)量

（單擊放大圖片）

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

硬件監(jiān)控

Munin node 是一個(gè)開源軟件程序，它可以監(jiān)控硬件并報(bào)告磁盤和RAM的使用情況這樣的指標(biāo)。MMS能夠收集Munin node產(chǎn)生的這些數(shù)據(jù)，并在MMS儀表盤中將這些數(shù)據(jù)和其他數(shù)據(jù)一起展現(xiàn)給用戶。因?yàn)槊恳粋€(gè)應(yīng)用程序和部署都是唯一的，所以用戶應(yīng)該為磁盤利用率的峰值、網(wǎng)絡(luò)活動(dòng)的主要變化和平均查詢長度/響應(yīng)時(shí)間的增長創(chuàng)建警報(bào)。

數(shù)據(jù)庫分析工具

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

其他的監(jiān)控工具

有各種各樣的監(jiān)控工具讓你能夠從其他的方面深入理解MongoDB系統(tǒng)。

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

如果想要獲取更多與監(jiān)控工具和監(jiān)控內(nèi)容相關(guān)的信息，可以查看MongoDB文檔中的 監(jiān)控?cái)?shù)據(jù)庫系統(tǒng) 頁面。

配置MongoDB

用戶應(yīng)該將配置選項(xiàng)存儲(chǔ)到MongoDB的配置文件中。sysadmins能夠通過這種方式在整個(gè)集群之間實(shí)現(xiàn)一致性的配置。配置文件支持MongoDB命令行所支持的所有選項(xiàng)。安裝和升級(jí)應(yīng)該通過流行的工具（例如Chef和Puppet）自動(dòng)完成，同時(shí)MongoDB社區(qū)還提供并維護(hù)了這些工具的示例腳本。

一個(gè)基礎(chǔ)的MongoDB配置文件類似于下面的內(nèi)容：

• 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配置選項(xiàng) 相關(guān)的更多內(nèi)容。在MongoDB文檔 產(chǎn)品說明 頁面上還維護(hù)著針對(duì)操作系統(tǒng)、文件系統(tǒng)、存儲(chǔ)設(shè)備和其他系統(tǒng)相關(guān)主題特定配置的最新建議。

結(jié)論

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

關(guān)于作者

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

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

查看中文原文： 為首次部署MongoDB做好準(zhǔn)備：容量計(jì)劃和監(jiān)控

為首次部署MongoDB做好準(zhǔn)備：容量計(jì)劃和監(jiān)控