將mongodb
加入到我們的服務支援列表中，是整個團隊年初工作計畫中的首要任務。但我們感覺如果先新增一項對nosql儲存的支援，而不是先公升級已支援的關係型資料庫，可能對使用者不太好，畢竟目前的使用者都使用關係型資料庫。
所以我們決定將引入mongodb這項工作放到公升級mysql和postgresql之後來做。到目前為止，mysql 5.5的beta版已在進行中，而postgresql的9.1 beta版也將進入流程，因此我們打算在2023年第一季度中應用這兩個版本。
由於我們對mongodb的關注，我們選擇性地為幾名使用mongodb的使用者提供了技術支援。在這個過程中，我們了解到了很多可能出現問題的地方。所以想借此文與大家分享engine yard眼中的mongodb最佳實踐。
如果你的mongodb是定製化安裝的，我們強烈建議你將自己的設定與本文講到的內容進行對比，並進行必要的設定修改。
已有很多文章對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引入到服務支援列表過程中所遵循的原則。
總是使用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官方發布的乙個監控服務，可以將集群的各項健康指標以圖形化的方式彙總展示。
MongoDB 最佳實踐
已經有很多關於 nosql 選擇的文章了。影響你選擇資料庫的因素有 讀 寫操作的吞吐量，永續性，一致性，延遲性等等。nathan hurst 的文章 visual guide to nosql system 很好的總結了這一點。nosql 通用的最佳實踐 1.徹底的測試 模擬你的生產環境，包括流量來...
MongoDB最佳實踐
將mongodb加入到我們的服務支援列表中，是整個團隊年初工作計畫中的首要任務。但我們感覺如果先新增一項對nosql儲存的支援，而不是先公升級已支援的關係型資料庫，可能對使用者不太好，畢竟目前的使用者都使用關係型資料庫。所以我們決定將引入mongodb這項工作放到公升級mysql和postgresq...
mongodb 最佳實踐
不要按照關係型來設計表結構 mongodb可以讓你像關係型資料庫一樣設計表結構，但是它不支援外來鍵，也不支援複雜的join！如果你的程式發現有大量實用join的地方，那你的設計可能需要重新來過。參照以下相關模式設計建議。資料庫集合 collection 的數量不宜太多 mongodb的模式設計基於靈...