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官方發佈的一個監控服務，能夠將集羣的各項健康指標以圖形化的方式彙總展現。