如果你已經(jīng)完成了自己新的MongoDB應(yīng)用程序的開發(fā),并且現(xiàn)在正準備將它部署進產(chǎn)品中,那么你和你的運營團隊需要討論一些關(guān)鍵的問題:
- 最佳部署實踐是什么?
- 為了確保應(yīng)用程序滿足它所必須的服務(wù)層次我們需要監(jiān)控哪些關(guān)鍵指標?
- 如何能夠確定添加分片的時機?
- 有哪些工具可以對數(shù)據(jù)庫進行備份和恢復(fù)?
- 怎樣才能安全地訪問所有新的實時大數(shù)據(jù)?
本文介紹了硬件選擇、擴展、HA和監(jiān)控。在查看詳細信息之前,首先讓我們處理一個最常見的問題:
部署MongoDB和部署RDBMS有什么不同?
你會發(fā)現(xiàn)MongoDB作為一個文檔數(shù)據(jù)庫,它和你已經(jīng)熟悉的關(guān)系型數(shù)據(jù)庫分享了很多同樣的概念、操作、策略和過程。監(jiān)控、索引、調(diào)整和備份等內(nèi)容的流程和最佳實踐可以應(yīng)用到MongoDB。同時如果你想要開始自己的培訓(xùn),那么可以從 MongoDB大學(xué) 中獲取到來自于開發(fā)者和DBA的免費在線課程。
系統(tǒng)性能和容量規(guī)劃是兩個重要的主題,任何部署都需要處理這兩個問題,無論是RDBMS還是NoSQL數(shù)據(jù)庫都是如此。作為規(guī)劃的一部分我們應(yīng)該對數(shù)據(jù)卷(volume)、系統(tǒng)負載、性能(吞吐量及延遲時間)和容量利用建立基線。這些基線應(yīng)該反映你對數(shù)據(jù)庫在產(chǎn)品環(huán)境中執(zhí)行的工作負載的期望,它們應(yīng)該隨著用戶數(shù)、應(yīng)用程序功能、性能SLA或者其他因素的變化定期地調(diào)整。
基線將幫助你理解系統(tǒng)哪些時候是按照設(shè)計運行的,哪些時候可能會影響用戶體驗質(zhì)量或者其他決定性系統(tǒng)因素的問題開始浮現(xiàn)。
下面將會討論關(guān)鍵的部署要素,包括硬件、擴展和HA,同時還會討論為了維持最佳的系統(tǒng)性能你應(yīng)該監(jiān)控哪些內(nèi)容。
清楚自己的工作集
在為部署MongoDB優(yōu)化硬件預(yù)算的時候,RAM應(yīng)該是或者接近于列表的第一位。
為了實現(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中。工作集可能是整個數(shù)據(jù)庫的一小部分,例如最近的事件所關(guān)聯(lián)的應(yīng)用程序數(shù)據(jù)或者最常訪問的熱門產(chǎn)品。
MongoDB試圖訪問數(shù)據(jù)時發(fā)生的頁面錯誤并不會被加載到RAM中。如果有空閑內(nèi)存,那么操作系統(tǒng)將定位到磁盤上的頁面并將它們直接加載到內(nèi)存中。但是如果沒有空閑內(nèi)存,那么操作系統(tǒng)必須將內(nèi)存中的一個頁面寫入磁盤,然后將被請求的頁面讀取到內(nèi)存中。這個流程比訪問已經(jīng)存在于內(nèi)存中的數(shù)據(jù)要慢。
有些操作可能會在不經(jīng)意間從內(nèi)存中清除大量的工作集,這樣會對性能產(chǎn)生嚴重影響。例如,對于一個瀏覽數(shù)據(jù)庫中所有文檔的查詢而言,如果數(shù)據(jù)庫比服務(wù)器上的RAM大,那么將會導(dǎo)致文檔被讀入內(nèi)存而工作集被寫出到磁盤。在項目的模式設(shè)計階段為自己的查詢定義合適的索引將會極大地降低這種風險發(fā)生的可能性。MongoDB 說明 操作能夠為查詢計劃和索引的使用提供信息。
MongoDB 服務(wù)狀態(tài) 命令 中包含了一個有用的輸出: 工作集 文檔 ,它提供了一個MongoDB實例工作集的估算大小。運營團隊可以按照給定的時間跟蹤實例訪問的頁面數(shù),包括工作集中最舊的文檔到最新的文檔之間的運行時間。通過跟蹤這些指標我們能夠發(fā)現(xiàn)什么時候工作集會接近現(xiàn)在的RAM限制從而積極地采取行動確保系統(tǒng)是可擴展的。
MongoDB管理服務(wù) 和 mongostat 能夠幫助用戶監(jiān)控內(nèi)存的使用情況,下面我們將會對此進行詳細地討論。
存儲和磁盤I/O
MongoDB不需要共享存儲(例如存儲區(qū)域網(wǎng)絡(luò))。MongoDB能夠使用本地附加的存儲和固態(tài)硬盤(SSD)。
MongoDB中的大部分磁盤訪問模式并沒有順序?qū)傩裕@樣做的結(jié)果便是客戶可以通過使用SSD獲得巨大的性能收益。我們已經(jīng)觀察到使用SATA SSD和PCI獲得的良好結(jié)果和強大的性能。商業(yè)SATA旋轉(zhuǎn)驅(qū)動器可以媲美成本更高的旋轉(zhuǎn)驅(qū)動器,這得益于MongoDB的非順序訪問模式:應(yīng)該更有效地使用預(yù)算將其用于更多的RAM或者SSD上,而不是更多地用于昂貴的旋轉(zhuǎn)驅(qū)動器上。
在數(shù)據(jù)文件受益于SSD的同時,MongoDB的日記文件由于其自身的高順序的寫屬性成為了快速常規(guī)磁盤的一個很好的候選。
大多數(shù)MongoDB部署應(yīng)該使用RAID-10。RAID-5和RAID-6沒有提供足夠的性能。RAID-0提供了很好的寫性能,但是讀性能有限,容錯能力也不足。部署的MongoDB可以通過副本集(下面將會討論)提供很強的數(shù)據(jù)可用性,同時用戶應(yīng)該考慮使用RAID和其他因素滿足想要的SLA可用性。
雖然我們應(yīng)該設(shè)計MongoDB系統(tǒng)讓它的工作集適合于內(nèi)存,但是磁盤I/O依然是一個關(guān)鍵的性能考慮。MongoDB會定期地將寫操作刷新到磁盤并提交到日記,所以在寫負載較重的時候基礎(chǔ)的磁盤子系統(tǒng)可能會變得不堪重負。iostat命令可以用于顯示高磁盤利用率和過多的寫隊列。
CPU選擇——速度還是內(nèi)核?
MongoDB的性能通常不會綁定到CPU上。因為MongoDB很少會遇需要利用大量內(nèi)核的工作負載,比起時鐘速度較慢的多核服務(wù)器最好的選擇是有更快的時鐘速度。
無論是什么系統(tǒng),測量CPU的利用率都是非常重要的。如果觀察到CPU的利用率很高但是并沒有出現(xiàn)磁盤飽和或者頁面錯誤這樣的其他問題,那么系統(tǒng)中可能會存在不尋常的問題。例如,一個存在無限循環(huán)的MapReduce工作或者一個沒有建立良好索引就對工作集中的大量文檔進行排序和過濾的查詢都可能會導(dǎo)致CPU利用率的飆升,但是它們卻不會引發(fā)磁盤系統(tǒng)問題或者頁面錯誤。用于監(jiān)控CPU利用率的工具將在下面介紹。
擴展數(shù)據(jù)庫——何時擴展和如何擴展?
MongoDB通過一種稱為 Sharding 的技術(shù)提供了水平擴展能力。Sharding能夠在多個物理分區(qū)(稱為片)之間分發(fā)數(shù)據(jù)。Sharding可以讓MongoDB的部署解決單個服務(wù)器的硬件限制而不需要增加應(yīng)用程序的復(fù)雜性,解決的硬件限制包括RAM和磁盤I/O的瓶頸。
MongoDB 自動分片和應(yīng)用程序的透明度
在系統(tǒng)資源變得有限之前實現(xiàn)分片是非常容易的,因此容量規(guī)劃和主動監(jiān)控在需要成功地擴展應(yīng)用程序時是非常重要的元素。
在下面的場景中用戶應(yīng)該考慮部署一個分片的MongoDB集群:
- RAM 限制: 系統(tǒng)活動工作集的大小很快就會超過系統(tǒng)RAM的最大容量。
- 磁盤 ?I/O 限制: 系統(tǒng)有大量的寫活動,但是操作系統(tǒng)寫數(shù)據(jù)的速度不夠快,無法滿足需求;同時/或者I/O帶寬限制了數(shù)據(jù)寫入磁盤的速度。
- 存儲限制: ? 數(shù)據(jù)集接近或者超過了系統(tǒng)中的單個節(jié)點的存儲容量。
Sharding的目標之一就是在多臺服務(wù)器之間一致地分發(fā)數(shù)據(jù)。如果服務(wù)器資源的利用率并不是近似地相等,那么可能會存在引發(fā)調(diào)度錯誤的潛在問題。例如,選擇一個糟糕的分片鍵可能會導(dǎo)致不平衡的數(shù)據(jù)分發(fā)。在這種情況下,即便不是所有的但是大部分查詢也會被導(dǎo)向到正在管理數(shù)據(jù)的那個單獨的MongoDB。
另外,MongoDB可能會試圖重新分發(fā)文檔從而在服務(wù)器之間實現(xiàn)更加理想的平衡。雖然重新分發(fā)最終會實現(xiàn)一種更加令人滿意的文檔分發(fā),但是有大量與重新平衡數(shù)據(jù)相關(guān)的工作,這些工作本身就有可能會產(chǎn)生影響導(dǎo)致無法實現(xiàn)預(yù)期性能的SLA。
通過運行 db.currentOp() 命令,你將能夠了解集群現(xiàn)在正在執(zhí)行哪些工作,包括跨分片的文檔再平衡。
為了確保數(shù)據(jù)能夠在集群中的所有分片間均勻地分發(fā),選擇一個優(yōu)秀的分片鍵是非常重要的。MongoDB文檔中包含了一個關(guān)于 如何選擇優(yōu)秀分片鍵的教程 。
MongoDB復(fù)制集的高可用性
MongoDB使用本地復(fù)制維護 復(fù)制集 之間的多個數(shù)據(jù)副本。復(fù)制集可以通過發(fā)現(xiàn)錯誤(服務(wù)器、網(wǎng)絡(luò)、OS或者數(shù)據(jù)庫)和自動化故障修復(fù)避免停機時間。推薦的做法是:所有的MongoDB部署都應(yīng)該配置復(fù)制。
(單擊放大圖片)
使用MongoDB復(fù)制集自恢復(fù)
對主節(jié)點數(shù)據(jù)庫的修改操作會通過名為 oplog 的日志被復(fù)制到其他二級節(jié)點上。oplog包含了一個排序的冪等操作的集合,該集合中的操作會在二級節(jié)點上重放。oplog的大小是可配置的,默認是可用磁盤空間的5%。
正如下面的圖表所闡述的,可以通過定位副本為服務(wù)器、機架、數(shù)據(jù)中心故障和網(wǎng)絡(luò)分區(qū)提供容錯性。
(單擊放大圖片)
復(fù)制延遲是作為正常運行的一部分來監(jiān)控的。它表示的是將主節(jié)點上的一個寫操作復(fù)制到二級節(jié)點上所花費的時間。一定的延遲是正常的,但是如果復(fù)制延遲增長,則可能會引發(fā)問題。復(fù)制延遲產(chǎn)生的典型原因包括網(wǎng)絡(luò)延遲、連接問題和磁盤延遲(例如二級節(jié)點的吞吐量劣于主節(jié)點)。
復(fù)制狀態(tài)和復(fù)制延遲可以通過 replSetGetStatus 命令重新恢復(fù)。
日志概述
作為所有部署的一部分,應(yīng)該監(jiān)控應(yīng)用程序和數(shù)據(jù)庫的日志以便發(fā)現(xiàn)錯誤并查看其他的系統(tǒng)信息。將應(yīng)用程序和數(shù)據(jù)庫的日志關(guān)聯(lián)起來是非常重要的,因為這樣才能決定應(yīng)用程序中的活動最終是否需要對系統(tǒng)中的其他問題負責。例如,用戶寫入峰值可能會增加寫入MongoDB的容量,這反過來可能會壓垮下面的存儲系統(tǒng)。如果沒有應(yīng)用程序和數(shù)據(jù)庫日志的關(guān)聯(lián),那么可能要花費更多的時間才能夠確定寫入容量的增長是應(yīng)用程序的問題而不是運行在MongoDB中的某些進程的問題。
MongoDB 監(jiān)控工具
MongoDB包含了各種監(jiān)控工具,讓你能夠積極地管理系統(tǒng)的運行和性能。
MongoDB管理服務(wù) (MMS)
MongoDB管理服務(wù)(MMS) 提供了云監(jiān)控和備份服務(wù),幫助用戶優(yōu)化集群、解決性能問題、減輕運維風險。MMS備份服務(wù)將在以后的文章中討論。
MMS監(jiān)控支持圖表、自定義儀表盤和自定義警告。MMS僅需要最低限度的安裝和配置。用戶在所有的 MongoDB 實例上安裝一個本地代理,該代理會跟蹤與數(shù)據(jù)庫使用情況相關(guān)的數(shù)百個關(guān)鍵的健康指標,包括:
- 操作數(shù)(Op Counters)—每秒鐘執(zhí)行的操作的數(shù)量
- 內(nèi)存(Memory)—MongoDB正在使用的數(shù)據(jù)量
- 鎖百分比(Lock Percent)—寫鎖消耗時間的百分比
- 后臺刷新(Background Flush)—將數(shù)據(jù)刷新到磁盤消耗的平均時間
- 連接(Connections)—MongoDB當前打開的連接的數(shù)量
- 隊列(Queues)—等待運行的操作的數(shù)量
- 頁面錯誤(Page Faults)—磁盤的頁面錯誤數(shù)
- 復(fù)制(Replication)—主節(jié)點操作日志的長度以及復(fù)制延時
- 日志(Journal)—寫入日志的數(shù)據(jù)量
(單擊放大圖片)
這些指標會被安全地報告給MMS服務(wù),告訴它它們是在哪里處理、聚合、通知的,并在瀏覽器中可視化顯示。用戶能夠容易地根據(jù)各種性能指標了解他們集群的健康狀況。
硬件監(jiān)控
Munin node 是一個開源軟件程序,它可以監(jiān)控硬件并報告磁盤和RAM的使用情況這樣的指標。MMS能夠收集Munin node產(chǎn)生的這些數(shù)據(jù),并在MMS儀表盤中將這些數(shù)據(jù)和其他數(shù)據(jù)一起展現(xiàn)給用戶。因為每一個應(yīng)用程序和部署都是唯一的,所以用戶應(yīng)該為磁盤利用率的峰值、網(wǎng)絡(luò)活動的主要變化和平均查詢長度/響應(yīng)時間的增長創(chuàng)建警報。
數(shù)據(jù)庫分析工具
MongoDB提供了一個 性能分析工具 ,該工具能夠記錄數(shù)據(jù)庫操作相關(guān)的細粒度信息。分析工具可以記錄所有事件的信息,也能夠只記錄那些持續(xù)時間超出了配置閾值的事件的信息。分析數(shù)據(jù)存儲在一個固定集合中,用戶能夠很容易地從中搜索相關(guān)的事件——查詢這個集合可能比嘗試著去解析日志文件更加容易。
其他的監(jiān)控工具
有各種各樣的監(jiān)控工具讓你能夠從其他的方面深入理解MongoDB系統(tǒng)。
- mongotop ?是隨MongoDB提供的一個工具,它能夠跟蹤并報告一個MongoDB集群當前的讀、寫活動。
- mongostat ?是隨MongoDB提供的另一個工具,它為所有的操作提供了一個全面概覽,包括更新、插入的計數(shù),頁面錯誤、索引的丟失情況以及很多其他的關(guān)系到系統(tǒng)健康的重要指標。
- Iostat、vmstat、netstat和sar這樣的Linux工具也能為深入探索MongoDB系統(tǒng)提供有價值的信息。
- 對于Windows環(huán)境上的用戶而言,性能監(jiān)控器(Performance Monitor,一個Microsoft管理控制臺單元)是一個非常有用的工具,可以用來測量各種指標。
如果想要獲取更多與監(jiān)控工具和監(jiān)控內(nèi)容相關(guān)的信息,可以查看MongoDB文檔中的 監(jiān)控數(shù)據(jù)庫系統(tǒng) 頁面。
配置MongoDB
用戶應(yīng)該將配置選項存儲到MongoDB的配置文件中。sysadmins能夠通過這種方式在整個集群之間實現(xiàn)一致性的配置。配置文件支持MongoDB命令行所支持的所有選項。安裝和升級應(yīng)該通過流行的工具(例如Chef和Puppet)自動完成,同時MongoDB社區(qū)還提供并維護了這些工具的示例腳本。
一個基礎(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配置選項 相關(guān)的更多內(nèi)容。在MongoDB文檔 產(chǎn)品說明 頁面上還維護著針對操作系統(tǒng)、文件系統(tǒng)、存儲設(shè)備和其他系統(tǒng)相關(guān)主題特定配置的最新建議。
結(jié)論
在本文中我們介紹了哪些用于部署關(guān)系型數(shù)據(jù)庫的概念、操作和流程可以被直接地應(yīng)用到MongoDB上,同時還介紹了硬件選擇和部署及監(jiān)控的最佳實踐。另外,有關(guān)于所有這些主題的詳細討論可以從 MongoDB操作指南 (一個.pdf文件)中獲取。
關(guān)于作者
Mat Keep ?(@matkeep) 是MongoDB產(chǎn)品營銷團隊的一員,負責為MongoDB的產(chǎn)品和服務(wù)構(gòu)建愿景、定位和內(nèi)容,同時也負責對市場趨勢和客戶需求進行分析。在就職于MongoDB之前,Mat是Oracle公司的產(chǎn)品管理總監(jiān),負責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做好準備:容量計劃和監(jiān)控
更多文章、技術(shù)交流、商務(wù)合作、聯(lián)系博主
微信掃碼或搜索:z360901061

微信掃一掃加我為好友
QQ號聯(lián)系: 360901061
您的支持是博主寫作最大的動力,如果您喜歡我的文章,感覺我的文章對您有幫助,請用微信掃描下面二維碼支持博主2元、5元、10元、20元等您想捐的金額吧,狠狠點擊下面給點支持吧,站長非常感激您!手機微信長按不能支付解決辦法:請將微信支付二維碼保存到相冊,切換到微信,然后點擊微信右上角掃一掃功能,選擇支付二維碼完成支付。
【本文對您有幫助就好】元
