MongoDB最佳實踐

　　將MongoDB加入到我們的服務支援列表中，是整個團隊年初工作計劃中的首要任務。但我們感覺如果先新增一項對NoSQL儲存的支援，而不是先升級已支援的關係型資料庫，可能對使用者不太好，畢竟目前的使用者都使用關係型資料庫。

　　所以我們決定將引入MongoDB這項工作放到升級MySQL和PostgreSQL之後來做。到目前為止，MySQL 5.5的Beta版已在進行中，而PostgreSQL的9.1 Beta版也將進入流程，因此我們打算在2012年第一季度中應用這兩個版本。

　　由於我們對MongoDB的關注，我們選擇性地為幾名使用MongoDB的使用者提供了技術支援。在這個過程中，我們瞭解到了很多可能出現問題的地方。所以想借此文與大家分享Engine Yard眼中的MongoDB最佳實踐。

　　如果你的MongoDB是定製化安裝的，我們強烈建議你將自己的設定與本文講到的內容進行對比，並進行必要的設定修改。

通常意義上的NoSQL最佳實踐

　　已有很多文章對NoSQL選型方面進行過討論。在選擇一個資料庫產品時，通常可能需要考慮以下因素：讀寫吞吐量、持久化、一致性以及延遲等。在Nathan Hurst的文章《Visual Guide to NoSQL Systems》中對這些方面都做了詳盡的介紹。

　　　資料庫的選擇是個大問題，本文不打算就這方面深入介紹，但希望讀者能夠自己去了解這方面的知識。一旦開發者瞭解得足夠多，最後的結論永遠都只有一個：沒有任何一個資料庫能夠滿足所有的應用場景。本文內容是基於選擇MongoDB作為資料庫儲存上來說的。Engine Yard在這方面提出瞭如下四點建議。

　　全面測試。測試一定要使用切合實際場景的資料，並且需要儘量模擬業務場景的資料操作情況。否則，開發者會發現在上線後的實際場景下，可能導致一些效能瓶頸甚至發現整體架構上的設計缺陷。因此，儘可能使用實際場景的操作使用來進行測試，然後收集足夠的測試資料。

　　千萬別以為在關係型資料庫上的使用方法可以被直接移植。MongoDB並不支援一些關係型資料庫的功能，所以開發者最好先搞清楚MongoDB支援哪些功能。為了獲得更好的效能，開發者最好多看10gen官方建議的文件設計和操作方法。另外，在使用MongoDB前，建議開發者做好對整個架構進行重構以適用新的儲存模型的準備。為了更好地理解資料遷移的代價，建議閱讀《The cost ofMigration》一文。

　　明確資料需要的一致性和可靠性。對MongoDB來說，可靠性不再過度地依賴將資料寫入到磁碟的操作，更多的是通過將資料同步到其他節點的方式解決可靠性問題。絕不建議開發者在真實環境中使用沒有備份的節點單獨工作。這一點很重要，所以建議開發者瞭解其中的原因。

　　明確你對EBS的期望。如果你是Engine Yard雲平臺的使用者（AWS EC2），那麼應該知道，EBS的效能不太穩定。所以在測試時，你最好收集足夠多的EBS裝置吞吐資料以做考量。Engine Yard本身並沒有對使用者在EBS效能上做限制。

MongoDB最佳實踐

　　以下是我們將MongoDB引入到服務支援列表過程中所遵循的原則。

　　總是使用Replica Sets。Replica Sets通過自動failover機制提供MongoDB的高可用性。在應用中，如primary機器出現故障，那麼某一臺secondary機器就會通過選舉成為新的primary，整個叢集仍然能夠提供正常服務。我們的服務不會支援無同步機制的MongoDB佈置方案。如果在開發者自己的環境中同步機制的代價過高，我們建議其使用一些雲端儲存服務。Engine Yard目前已經與MongoHQ和MongoLab都建立了合作關係。開發者可以在合作者頁面找到更多這方面的資訊。

　　保持版本更新。保持版本更新很重要，10gen在每個版本中都會修復一些問題，使MongoDB的執行更出色。比如在2.0.x版本中，MongoDB的儲存效能和併發效能就有極大提高，同時還包括索引優化、Bug修復以及compaction命令等一系列改進，以便開發者更方便地擴充套件其叢集。如果你還在使用1.6.3版本，那就快升級吧。

　　不要在32位系統上使用MongoDB。在32位機器上，MongoDB只能儲存約2.5GB的資料。因為MongoDB在內部實現上是通過記憶體對映的方式來提高效能的，所以在32位機器上其記憶體地址本身就限制了資料容量。在Engine Yard雲服務中使用MongoDB，請使用Large instance來部署MongoDB。在實際產品中，我們也只支援64位的MongoDB。

　　預設開啟journaling日誌。MongoDB支援在寫操作前記錄journaling日誌來提高節點的可用性。強烈建議在部署時開啟journaling日誌。注意資料檔案的存放位置。在使用時，請確認你的資料檔案處於一個持久化儲存中（比如/data/mongodb目錄）。也可以使用非持久化的裝置進行資料檔案儲存，不過你最好小心再小心，因為這可能會對你的叢集架構造成影響。推薦使用EBS進行MongoDB的資料檔案儲存。熱資料最好能放在記憶體中。能夠保持熱資料（以及索引資料）一直放在記憶體中，這一點非常重要，它將對整個叢集的效能造成影響。如果通過監控發現page fault的數量增加，那麼很可能就是熱資料量超出了可用記憶體大小。當熱資料量超出了可用記憶體量時，通常有兩種解決方法：增加記憶體和資料分片。建議先增加記憶體，再考慮通過資料分片的方式解決。

　　壓力過大升級配置。如果機器負載達到65%，那麼應該考慮升級機器配置。在日常使用中，最好保持負載低於65%。同時這也對資料恢復和縱向擴充套件有影響。當需要升級配置時，AWS建議按下面的順序來做：Large、Extra Large、High Memory 4XL。而在更高配置的機器上，網路延遲也會更小。

　　分片需謹慎。分片策略會受資料訪問特點的影響，所以在進行資料分片前，最好先理清楚資料的訪問特點，並想明白是否確實需要分片。分片欄位對效能的影響非常大，所以選擇一個好的分片欄位是非常重要的。Config節點對整個叢集的健康執行是至關重要的，所以一旦你選擇使用分片機制，就一定要保證有3個Config節點。永遠不要刪除Config節點的資料，要確保頻繁地對這些資料進行日常備份。如果可能，通過域名來指定節點的地址，比如在/etc/hosts檔案中指定相應的本地域名，這能讓你在叢集配置上更靈活。Config節點的壓力很小，但還需執行在64位機器上。千萬不要把3個Config節點都放在同一臺機器上！

　　另外，如果你要部署一個分片叢集，那麼可以向Engine Yard專家服務預約諮詢服務。

　　使用Mongo MMS圖形化監控服務。如果你還沒有完善的MongoDB監控，可以嘗試Mongo MMS。Mongo MMS是10gen官方釋出的一個監控服務，可以將叢集的各項健康指標以圖形化的方式彙總展示。

　　原文連結：http://www.engineyard.com/blog/2011/mongodb-best-practices