想使用 MongoDB ，你應該瞭解這8個方面！

應用性能高低依賴於數據庫性能，MongoDB 是一個基於分佈式文件存儲的數據庫。由 C++ 語言編寫，旨在爲 WEB 應用提供可擴展的高性能數據存儲解決方案。MongoDB 是一個介於關係數據庫和非關係數據庫之間的產品，是非關係數據庫當中功能最豐富，最像關係數據庫的。

本文針對實時監控 MongoDB 數據庫，總結了一些使用的工具以及須要重點注意的性能方面。

1，實時監控 MongoDB 工具

MongoDB 用本身的工具來統計如今運行的 MongoDB 服務器的數據，並進行實時報告分析：

• mongostat：能夠展現像 opcounts，lock％，內存使用以及副本集更新狀態等關鍵指標，由於能夠實時看到發生的情況，因此通常用於故障除疑。

• mongotop：mongostat 提供的是全局指標，而 mongotop 則提供追蹤 MongoDB 實例花費在讀寫操做數據的時間指標，提供每一個集合級別的統計數據。

• is.status()：返回的是當前服務器節點執行操做後副本集的狀態，經過這個來實時查看集羣的變化。

• sh.status()：返回你的分片集羣的狀態，尤爲是每塊碎片的數量，顯示關於分片集羣的現有區塊的信息的格式化的報告，若是區塊大於等於20就不顯示詳細塊信息。

2，內存使用量和頁面錯誤

內存多是你能夠給 MongoDB 的最重要的資源，由於 Mongodb 是至關吃內存的，若是控制很差的話，mongodb會掛掉。。。因此你要確保你給的內存老是有足夠的！經驗之談是提供符合索引數量的足夠的 RAM，若是可能的話，爲全部數據提供足夠的內存。

常駐內存是這裏的關鍵指標，MongoDB 內存 mem 記錄了 Mongod 的系統架構和內存使用。

頁面錯誤和內存相關由於頁面錯誤發生時是 MongoDB 去磁盤裏面查找數據而不是內存中，若是內存的數量不能知足性能需求，那麼你將會看到頁面錯誤，隨着頁面錯誤率的上升，opcounters 最終會低於指望值，因此這時你應該增長可用的 RAM。

3，鏈接數

鏈接到 MongoDB 的每一個鏈接都有助於追蹤系統所需的內存的開銷。這最初由 Unix 經過 ulimit 來設置限制，但隨後成爲由服務器資源，特別是存儲器限制。

太高數量的鏈接數還能夠指明問題，例如你的應用程序代碼打開太多的鏈接，形成某地方產生很高的 lock％ 。

有時客戶端和數據庫之間的鏈接數超出服務器處理請求的能力，這可能會致使在 MongoDB 環境的應用程序性能的降低。

4，數據庫操做

很少說，實時掌握數據庫操做的統計數據以及複製和分片操做的詳細信息，確保每秒數據庫操做（inserts，query，update，delete，getmore 等 command 命令）的總數有助於分析和跟蹤數據庫的負載。

5，鎖

MongoDB 使用一個全局鎖來確保一致性。可是，若是某些操做是長時間運行的或造成一個隊列，操做等待鎖就會大大下降應用程序性能。

在 MongoDB 2.6版本中，鎖是數據庫級別的，一直持續 MongoDB 2.8，寫操做都是一個全局性數據庫鎖，MongoDB 使用的這種「readers-writer」鎖，雖然支持併發但有很大的侷限性，當一個讀鎖存在，許多讀操做可使用這把鎖，然而當一個寫鎖存在時，其它讀寫操做不能使用共享這個鎖，寫入優先於讀取，當兩個操做一個讀取和一個寫入正在等待鎖，MongoDB 會授予寫鎖，因此若是寫鎖發生的過於頻繁，那麼你應用的性能出現文件也就不奇怪了。固然若是你的應用中真的有大量的寫操做，能夠考慮 Cassandra 數據庫。

6，複製集

MongoDB 複製集經過將數據部署在多個不一樣的服務器上，防止因單機故障而形成數據的丟失，藉助數據冗餘來提升數據的可靠性和安全性。並且還能夠經過複製技術構建分佈式數據庫，提升系統的訪問性能和安全性。

複製集同步數據過程是：Primary 節點寫入數據，Secondary 經過讀取 Primary 的 oplog 獲得複製信息，開始複製數據而且將複製信息寫入到本身的 oplog，複製延遲是 Primary 節點上寫入到 Secondary 節點讀取 oplog 再寫入操做的延遲，複製延遲多是一個顯著的問題，嚴重影響 MongoDB 副本集部署，過分複製延遲使「滯後」的節點將很快成爲 Primary ，增長了分佈式讀操做不一致的可能性。

7，片鍵

分片是在多臺計算機存儲數據記錄的過程當中 MongoDB 來知足數據增加需求的特有方式。隨着數據量的增長，一臺服務器可能不足以存儲數據或提供大量的讀寫操做。分片解決了水平擴展的問題，經過分片，能夠添加更多的機器來支持數據增加以及知足讀寫操做的需求。

MongoDB 在集合的水平上分割數據和分片，經過一個片鍵( shard key )來分割分片。

爲了將一個集合分片，須要選擇一個片關鍵字。一個片鍵是一個索引字段，或是存在於每一個集合文檔中的一個複合索引字段。選擇正確的分片鍵能夠對應用性能，功能以及數據庫和集羣的運做有很大的影響，合適的分片鍵選擇取決於你的數據的架構和應用程序的查詢和寫入數據的方式。並且 Mongodb 數據庫是否能高效運轉也取決於你指定了文檔的哪一個字段做爲分片字段。因爲分片字段都是預先選擇且選定後沒法更改的，並且考慮到 MongoDB 縱向擴展能力的限制，選擇時就須要深思熟慮了。分片鍵應該知足如下條件：

• 分配 -- 分片鍵最糟糕的狀況是自增的值（當全部的寫操做將被平衡到單個碎片時就意味着"熱碎片"的發生，而這就是瓶頸）。理想的分片重點應該讀和寫是儘量多的"隨機分佈"。

• 理想的片鍵主要功能應該是用於查詢，若是大部分的查詢請求都可以命中儘量少的分片那就最好了。

• 一個好的片鍵使得 MongoDB 分配內容變的容易。MongoDB 會根據你的設置將你的數據劃分到有着相同片鍵的數據塊 (Chunk) 中。然後這些數據塊將根據片鍵的大體順序分散到副本集中。

8，集成監控工具 Cloud Insight

想要看以上數據指標，須要必定的監控手段，MongoDB 自己有一堆本身的工具，此外還有開源工具以及第三方廠家提供的監控軟件，總結爲一點，監控很重要，Cloud Insight 全面監控 MongoDB，一工具在手，默認60個數據指標，MongoDB 發生什麼都瞭然於心。

順道推薦這些文章：

大規模運行 MongoDB 應該知道的10件事

本文由 Cloud Insight 工程師整理編譯， Cloud Insight 集監控、管理、計算、協做、可視化於一身，幫助全部 IT 公司，減小在系統監控上的人力和時間成本投入，讓運維工做更加高效、簡單。想閱讀更多技術文章，請訪問 OneAPM 官方技術博客。

本文轉自 OneAPM 官方博客