MongoDB的首席解決方案架構(gòu)師Asya Kamsky?最近發(fā)表了一篇文章，概括了大規(guī)模運行MongoDB需要知道的10件事。

MongoDB也需要DevOps。MongoDB是一個數(shù)據(jù)庫。和任何其他的數(shù)據(jù)存儲一樣，它也需要容量計劃、調(diào)整、監(jiān)控和維護(hù)。不要因為它很容易安裝、入門，同時與關(guān)系型數(shù)據(jù)庫相比能夠更加自然地滿足開發(fā)人員的范例就認(rèn)為MongoDB不需要適當(dāng)?shù)恼疹櫤臀桂B(yǎng)。開發(fā)時它能在小樣本數(shù)據(jù)集上超快地運行并不意味著你就不需要良好的模式、索引策略以及產(chǎn)品環(huán)境所需要的正確的硬件資源了。但是如果你準(zhǔn)備的很好，并且理解最佳實踐，那么運營大型MongoDB集群就會變得很無聊，而不是令人非常頭痛。

成功的MongoDB用戶會監(jiān)控所有的事情，同時會做好增長的準(zhǔn)備。在任何數(shù)據(jù)庫系統(tǒng)中跟蹤當(dāng)前的容量以及容量計劃都是基本的實踐，MongoDB也是如此。你需要知道集群現(xiàn)在能夠支撐多少工作，最高使用率時它會處理哪些需求。如果你沒有注意到服務(wù)器上增長的負(fù)載，那么最終會遇到?jīng)]有足夠容量的錯誤。監(jiān)控MongoDB可以使用MongoDB管理服務(wù)（MMS），通過查看操作計數(shù)器（opscounters）圖表可視化自己的操作：

你可能并不希望系統(tǒng)隨著使用量的增長出現(xiàn)性能擴展障礙。?根據(jù)大量用戶的部署經(jīng)驗，性能瓶頸通常是（按順序）：

• 應(yīng)用程序訪問模式?jīng)]有使用最優(yōu)的模式設(shè)計
• 索引不佳或者缺失索引，抑或有太多不必要的索引
• 磁盤較慢/磁盤IOPS不足
• 索引沒有足夠的RAM

事實證明，在真正的大型部署實踐中對性能影響最大的是模式設(shè)計與應(yīng)用程序需求的契合程度。而缺少索引、索引錯誤或者索引太多則是影響性能的第二大因素。在模式設(shè)計非常完美，索引也最優(yōu)的情況下，磁盤IO吞吐能力就成了下一個限制因素，尤其是寫吞吐量。RAM不足會引發(fā)很多頁錯誤，同時也會增加磁盤IO的壓力。

很多成功的MongoDB用戶使用單復(fù)制集。太早分片可能是過早優(yōu)化，并不是每個MongoDB部署都需要分片。分片處理非常特殊的需求，不能不加思索地認(rèn)為它就是解決“數(shù)據(jù)庫很慢”的最佳方案。如果你的協(xié)調(diào)模式非常差勁或者有錯誤索引，那么分片并不能解決問題，相反的你最終會得到一些差勁的協(xié)調(diào)和差勁的執(zhí)行碎片。當(dāng)單臺機器或者復(fù)制集上的某種特殊資源成為瓶頸，同時基于成本的考慮無法添加更多這種資源的時候才適合分片。你可能需要更多的磁盤IO吞吐量，或者更多的內(nèi)存，或者更多的存儲，再或者更多的并發(fā)，這種情況下分片才是有意義的。

即使沒有將整個數(shù)據(jù)庫放在內(nèi)存中，MongoDB依然能夠取得非常好的性能。對于MongoDB常見的一個誤解是：為了獲得更好的性能需要將整個數(shù)據(jù)庫放在內(nèi)存中。這可能是最錯誤的一件事情，因為這依賴于集群正在處理的負(fù)載的類型。有一些標(biāo)志和指標(biāo)能夠告訴你：相對于你放到數(shù)據(jù)庫上的負(fù)載類型你所擁有的內(nèi)存數(shù)量是否充足。正如你所看到的，隨著數(shù)據(jù)庫大小的增長，能夠放到內(nèi)存中的相關(guān)部分將會受限于可用物理內(nèi)存的大小。如果內(nèi)存的數(shù)量不能滿足性能需求，那么你將會看到頁面錯誤，隨著頁面錯誤率的上升，opcounters最終會低于期望值。

必須將數(shù)據(jù)寫刷新到磁盤。如果磁盤利用率達(dá)到了100%，那么處理更多寫操作的速度比起現(xiàn)在得不到絲毫的提升。可以通過MMS中的“Background flush average”圖表查看將數(shù)據(jù)文件中的臟頁刷新到磁盤花費了多長時間。通過這種趨勢你會發(fā)現(xiàn)，隨著寫操作的增長，刷新將花費更多的時間。這種問題可以通過使用更快的磁盤解決，將工作拆分到更多的分片上，或者調(diào)整應(yīng)用程序使之減少寫數(shù)據(jù)的總量。你應(yīng)該記住：寫入的所有內(nèi)容都會被刷新到磁盤兩次——立即刷新到日志同時周期性地刷新到數(shù)據(jù)文件。將這兩種操作分離到不同的物理設(shè)備上將會消除它們對可用磁盤IO帶寬的競爭。?

復(fù)制 != 備份。所有人都清楚備份的重要性。但是為什么備份這么重要呢？ 想必是因為當(dāng)某些影響所有復(fù)制集節(jié)點的災(zāi)難性事件發(fā)生的時候我們可以恢復(fù)數(shù)據(jù)。復(fù)制并不是備份的原因是：它并不能讓你避免人為錯誤——例如某些人突然刪除了產(chǎn)品數(shù)據(jù)，或者部署了錯誤版本的應(yīng)用程序代碼以致于搞亂了部分或者所有數(shù)據(jù)。必須要有一個能夠讓我們從這種場景中恢復(fù)數(shù)據(jù)的備份。通過文件系統(tǒng)快照、mongodump或者M(jìn)MS備份練習(xí)數(shù)據(jù)恢復(fù)。第一次從備份恢復(fù)產(chǎn)品數(shù)據(jù)的操作不應(yīng)該發(fā)生在真正的“數(shù)據(jù)緊急事件”發(fā)生的時候。

復(fù)制集的健康不僅僅是復(fù)制延遲。“復(fù)制延遲”僅僅是復(fù)制集健康狀況的指標(biāo)之一。關(guān)注復(fù)制操作日志（oplog）窗口和監(jiān)控復(fù)制延遲一樣重要。它表示的是基于現(xiàn)在的寫流量完全“滾動”oplog所要花費的時間。換句話說，它指的是將一個復(fù)制節(jié)點拿下來以后依然能夠重新加入集合而不必對所有數(shù)據(jù)進(jìn)行重新同步的時間。隨著時間的推移，復(fù)制操作日志窗口將會隨著寫負(fù)載的變化而浮動。流量高峰時窗口會縮短。這在容量計劃中是非常重要的，你需要為最繁忙的數(shù)據(jù)吸收時間做好準(zhǔn)備。下面是MMS中的一個并行視圖，它展示了整個復(fù)制集的復(fù)制操作日志窗口。

MongoDB并不清楚數(shù)據(jù)需要什么樣的安全級別。和其他數(shù)據(jù)庫一樣，你應(yīng)該遵循最小特權(quán)原則。必須自己配置數(shù)據(jù)庫的安全。不要讓所有人都能訪問你的數(shù)據(jù)。打開MongoDB自己本身的安全機制是非常重要的，但是這樣也鎖定了從任何地方對集群的訪問，除非你確實認(rèn)為自己的客戶端進(jìn)程可以在那里運行。只修改MongoDB進(jìn)程的默認(rèn)端口并不能保證安全。

沒必要修改引擎里面的東西。?除非文檔或者M(jìn)ongoDB支持告訴你做一些非常特殊的事情，否則你沒有必要直接修改系統(tǒng)集合、本地、管理或者配置數(shù)據(jù)庫。你可以借助于管理命令和shell執(zhí)行所需的操作，如果數(shù)據(jù)庫并不能按照期望運行，或者某些地方發(fā)生了錯誤，那么成功的鑰匙并不是試圖通過直接操作內(nèi)部的“bits”強制它運行。你需要熟悉的唯一一個“特殊的”、由系統(tǒng)產(chǎn)生的集合是分析器集合，定期地分析你的查詢是確保事情按照期望運行的一個非常好的方式。

總結(jié)

以上是生活随笔為你收集整理的大规模运行MongoDB应该知道的10件事的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。