MongoDB 已經無法滿足需求…現在怎麼辦？

Question 1

如果您目前的效能太慢或達到限制，那麼您有三個選擇。它們適用於任何問題。

垂直縮放：意思是增加你的機器功率。更多 CPU 或更多 RAM。
水平縮放：意味著增加工人數量。更多行程、更多執行緒、更多機器。
改變設計: 換一種方式。其他軟體，其他演算法，其他儲存系統，其他任何東西。

由於您從選項中排除了 1) 和 2)，因此只剩下解決方案 3)。所以就去吧...

Answer

如果您目前的效能太慢或達到限制，那麼您有三個選擇。它們適用於任何問題。

垂直縮放：意思是增加你的機器功率。更多 CPU 或更多 RAM。
水平縮放：意味著增加工人數量。更多行程、更多執行緒、更多機器。
改變設計: 換一種方式。其他軟體，其他演算法，其他儲存系統，其他任何東西。

由於您從選項中排除了 1) 和 2)，因此只剩下解決方案 3)。所以就去吧...

Question 2

我們在 Mongo 論壇上發布了同樣的問題，Mongo CTO 做出了回應，說要回顧他關於如何優化索引的演示

http://www.10gen.com/presentations/mongosf2011/schemascale

在本次演講中，Horowitz 先生明確指出，分片/水平擴展在許多情況下可能會過度，並且設計方法（包括 Mongo 特有的一些相當不直觀的方法）可以使給定的伺服器擴展得更遠。

這提出了一些有趣的概念，包括使用客戶端邏輯來優化資料庫以多種「非規範化」方式使用的方式。演示文稿中有一個明確的潛台詞，大意是“如果您只是按照書本進行構建，那麼您很容易會遇到與擴展相關的不需要的問題。”例如，Horowitz 先生（MongoDB 製造商10Gen 的首席技術官）提出了一種“混合”設計，其中不是每個“記錄”一個文檔，而是在一個文檔中放置100 條“記錄”，從而形成“桶”類型的方法。這樣做是為了減少索引佔用空間。這是在客戶端編碼的內容，不是 MongoDB 的「功能」。這種混合方法可能對我們有用，並且可以使我們的索引大小提高 4 倍或 8 倍。

他還討論了“右平衡”btree，這基本上是優化索引設計，以便大多數查詢僅訪問索引的“右手部分”（而不是跨索引的隨機訪問，為了獲得良好的性能，需要整個索引適合RAM ）。這種方法對我們沒有幫助，因為我們需要查詢整個索引。

我們將使用這些概念作為我們系統審查的一部分。

（有趣的是，在我發布這個問題的所有地方中，唯一給出建設性回應的是 MongoDB 本身的 CTO。）

更新（2017）

最終，我們發現 Mongodb 不適合生產環境。每隔幾個月，它就會轉儲/銷毀整個資料庫，並且所有資料都會遺失。（它不是主要資料來源，因此我們可以忍受這個問題，儘管並不愉快。）

我們現在已經完成了一個遷移到 Elasticsearch 堆疊的項目，並且正在將其投入生產。（我們已經成功使用 Elasticsearch 多年。）Elasticsearch 資料不像 Microsoft SQL Server 那麼持久（我們曾經遇到 Elasticsearch 叢集因不可恢復的資料遺失而失敗），但 Elasticsearch 至少是 10 倍（根據經驗，超過 100 倍））比Mongodb 可靠。（Elasticsearch 很聰明，沒有假裝支援 Windows 作為生產平台，這是 Mongodb 的一大罪。）

我們預計將在未來幾週內清除整個 Mongodb 環境。

向前！

更新（2018-2019）

Elasticsearch 堆疊已經交付。我們發現它非常可靠，非常可擴展，而且根本沒有回頭看。 Mongo 當時聞起來很香，但現在已經消失很多年了，最好擺脫它了。我們一直在運行兩個彈性集群，一個用於日誌資料（取代了我們的 Mongo 伺服器），另一個用於實際應用程式資料。每個集群有1-2TB的資料。花了一個很多架構工作（特別是在應用程式方面）的規模和效能都具有彈性，但交付確實如此。

Answer

我們在 Mongo 論壇上發布了同樣的問題，Mongo CTO 做出了回應，說要回顧他關於如何優化索引的演示

http://www.10gen.com/presentations/mongosf2011/schemascale

在本次演講中，Horowitz 先生明確指出，分片/水平擴展在許多情況下可能會過度，並且設計方法（包括 Mongo 特有的一些相當不直觀的方法）可以使給定的伺服器擴展得更遠。

這提出了一些有趣的概念，包括使用客戶端邏輯來優化資料庫以多種「非規範化」方式使用的方式。演示文稿中有一個明確的潛台詞，大意是“如果您只是按照書本進行構建，那麼您很容易會遇到與擴展相關的不需要的問題。”例如，Horowitz 先生（MongoDB 製造商10Gen 的首席技術官）提出了一種“混合”設計，其中不是每個“記錄”一個文檔，而是在一個文檔中放置100 條“記錄”，從而形成“桶”類型的方法。這樣做是為了減少索引佔用空間。這是在客戶端編碼的內容，不是 MongoDB 的「功能」。這種混合方法可能對我們有用，並且可以使我們的索引大小提高 4 倍或 8 倍。

他還討論了“右平衡”btree，這基本上是優化索引設計，以便大多數查詢僅訪問索引的“右手部分”（而不是跨索引的隨機訪問，為了獲得良好的性能，需要整個索引適合RAM ）。這種方法對我們沒有幫助，因為我們需要查詢整個索引。

我們將使用這些概念作為我們系統審查的一部分。

（有趣的是，在我發布這個問題的所有地方中，唯一給出建設性回應的是 MongoDB 本身的 CTO。）

更新（2017）

最終，我們發現 Mongodb 不適合生產環境。每隔幾個月，它就會轉儲/銷毀整個資料庫，並且所有資料都會遺失。（它不是主要資料來源，因此我們可以忍受這個問題，儘管並不愉快。）

我們現在已經完成了一個遷移到 Elasticsearch 堆疊的項目，並且正在將其投入生產。（我們已經成功使用 Elasticsearch 多年。）Elasticsearch 資料不像 Microsoft SQL Server 那麼持久（我們曾經遇到 Elasticsearch 叢集因不可恢復的資料遺失而失敗），但 Elasticsearch 至少是 10 倍（根據經驗，超過 100 倍））比Mongodb 可靠。（Elasticsearch 很聰明，沒有假裝支援 Windows 作為生產平台，這是 Mongodb 的一大罪。）

我們預計將在未來幾週內清除整個 Mongodb 環境。

向前！

更新（2018-2019）

Elasticsearch 堆疊已經交付。我們發現它非常可靠，非常可擴展，而且根本沒有回頭看。 Mongo 當時聞起來很香，但現在已經消失很多年了，最好擺脫它了。我們一直在運行兩個彈性集群，一個用於日誌資料（取代了我們的 Mongo 伺服器），另一個用於實際應用程式資料。每個集群有1-2TB的資料。花了一個很多架構工作（特別是在應用程式方面）的規模和效能都具有彈性，但交付確實如此。

Question 3

您可能不喜歡“擴展”問題的答案，因為您實際上沒有擴展問題；你有一個設計和實現的問題。您沒有有效地建立索引。

說真的，如果您覺得絕對必須保留該大小的索引，那麼在您尋找的任何資料庫產品中，您都會遇到在 RAM 中保留巨大索引的相同問題。您必須購買大容量伺服器（DL380 G7 可以做到這一點，它是一款中檔商品伺服器；沒什麼奇特的）來儲存這些索引。

作為幫助，搜尋「mongodb 優化索引」會出現幾個有用的連結：

http://www.mongodb.org/display/DOCS/Optimization

http://www.10gen.com/events/indexingmatters

http://www.deanlee.cn/programming/mongodb-optimize-index-avoid-scanandorder/

http://www.slideshare.net/kbanker/mongo-indexoptimizationprimer

您可能會對自己的研究感到抵觸，但我們這些在生產中使用 MongoDB 的人都知道您遺漏了很多要點。

此外，評論“底線：MongoDB 是 FOSS，但我們必須在硬體上花費 $$$$$$$ 來運行它？我們寧願購買商業軟體！”無知和傲慢的尖叫。

Answer