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 官方發布的一個監控服務，可以將集群的各項健康指標以圖形化的方式匯總展示。