將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.programmer.com.cn/9999/

原英文文章來自：http://www.engineyard.com/blog/2011/mongodb-best-practices/

總結

以上是生活随笔為你收集整理的MongoDB最佳实践（转）的全部內容，希望文章能夠幫你解決所遇到的問題。

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