你有沒有遇到MongoDB數據庫的性能問題？運行查詢時常見的情況是突然出現性能問題。明顯的第一個解決方案是“讓我們創建一個索引！” 雖然這在某些情況下有效，但在嘗試優化MongoDB時還需要考慮其他選項。

性能不是一個擁有昂貴磁盤和千兆網絡的大型機器的問題。事實上，這些并不一定是取得良好表現的關鍵。

MongoDB的性能來自良好的概念，組織和數據分布。我們將列出一些有關良好MongoDB優化的最佳實踐。這不是一個詳盡的或完整的指南，因為有很多變數。但這是一個好的開始。

1.保持文件簡單

MongoDB是一個無模式數據庫。這意味著默認情況下沒有預定義的模式。我們可以在新版本中添加預定義的模式，但不是強制性的。了解使用嵌入式文檔和數組時遇到的困難，因為在應用程序端/ ETL過程中解析數據會變得非常復雜。此外，數組可能會影響復制性能：對于數組中的每個更改，所有數組值都將被復制！

在MMAPv1中，選擇正確的字段名稱非常重要，因為數據庫需要保存每個文檔的字段名稱。它不像在關系數據庫中保存架構。讓我們想象一下 ，如果您有一百萬個文檔，那么稱為lastmessagefrom傳感器的字段會占用多少數據：大約28 MB僅用于保存此字段名稱！十個字段的集合需要280MB（僅用于保存一個空文檔）。

幾乎達到這種文件大小的文件是不可取的，因為數據庫將需要大量頁面來處理單個文件。這需要更多的CPU周期來完成任何操作。

2.硬件很重要，但...

使用好幾個處理器和大量內存的硬件肯定有助于提高性能。

WiredTiger利用多個處理器來提供良好的性能。該存儲引擎具有每文檔鎖定算法，因此可以同時運行盡可能多的處理器和盡可能多的操作（存在票據限制，但這超出了本文的范圍）。但是，MMAPv1存儲引擎必須鎖定每個集合，有時不能利用多個處理器進行寫入。

但是當一個實例死亡時，在三臺大型機器（32個CPU，128個RAM和2TB磁盤）的環境中會發生什么？答案是它會進行故障轉移 - 而且驅動程序足夠聰明，可以讀取運行狀況實例并編寫新的主要實例。但是，你的表現不一樣。

情況并非總是如此，但在分布式環境中使用多臺中小型機器可確保中斷只會影響碎片的幾個部分，而應用程序很少或根本沒有感知。但是與此同時，更多的機器意味著很有可能失敗。在設計環境時考慮這種折衷。正確的選擇會影響性能。

3.閱讀首選項和writeConcern

讀取首選項和writeConcern根據公司的要求而有所不同。但請記住，新的MongoDB版本（3.6）使用writeConcern：“多數”和readConcern：“主要”。

這意味著它必須承認至少在所有寫入（（N / 0.5）+1）的寫入，其中N是副本集中實例的數量。這可能會很慢。然而，這對于速度的一致性來說是一個公平的權衡。

請確保您使用的是最適合您的閱讀偏好，并在您的公司中撰寫關注。驅動程序始終從主服務器讀取，但如果它不是您的環境要求，請考慮將查詢分發到其他實例中。如果不這樣做，這些實例僅用于故障轉移，并且不會在常規操作中使用。

4.工作集

工作組有多大？通常，應用程序不會使用所有數據。一些數據經常更新，而其他數據則不是。

你的工作數據集是否適合RAM？當所有工作數據集在RAM中時都會發揮最佳性能。女性的遲緩，如頁面錯誤，可能會影響性能，這取決于您使用的是什么。

讀取（如備份，ETL或基本報告）可能會嚴重影響性能，因為存在競爭將頁面放入緩存中的情況。大報告或匯總也是如此。

擁有多個用于多種用途的集合并將特定機器用于特定目的（如使用區域來保存不再使用的文檔）將有助于實現簡單和預期的工作集。

總結

以上是生活随笔為你收集整理的4个优化MongoDB的技巧的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。