某人發了一篇 Don’t use MongoDB 的血淚控訴，我把原文翻譯如下，你可以看看。不過，我想我們還要去看看10gen CTO 的對此事的回覆，我們還要去在 Reddit 上看看大家的說法，10gen CTO 的對此事的回覆後面也有一堆人在討論這個事，還有一些程式設計師開始去讀 MongoDB 的原始碼了，呵呵。看樣子，說 MongoDB 的這些事並不是真的。

　　10gen CTO 對此事的並不完全知道，其在回覆，對些文中的每一條都做了回覆。我把其回覆的大體意思也放在原文中。不過，很有意思的是那些程式設計師的討論。建議大家看看。

　　正文

　　因為各種政治原因，我這段時間沒有說什麼，但是現在我覺得因為要對社會負責，所以我要阻止大家不要把你們的業務放在 MongoDB 上。

　　我的團隊在一個有巨大使用者量（一個有千萬使用者級的大型的公司）系統上使用的 MongoDB，這個系統上讓 MongoDB 有非常大的負載。早期，我們以為使用 MongoDB 會像10gen 公司（MongoDB 背後的公司）宣揚其在長期效能擴充套件有很多好處。但是，我們錯了，而這個 rant (長篇抱怨)就是為了讓你不要相信那些所謂的成功經驗，而和我們一樣犯了大錯。如果有人能避免你上當，那麼就得我寫這麼多。希望能警醒更多的人。

　　注意，對於和10gen 打交道的經歷來說，他們給予了我們充分了熱情和幫助，而且非常地好。但是這並不能成為我不告訴大家他們的產品失敗的理由。

　　為什麼這麼說？

　　資料庫應該是正確的，或是儘可能的正確，因為資料庫的錯誤會比其它錯誤危害更大。不僅僅是因為其對執行，效能，開銷，和其價值影響巨大，還因為其連帶的東西。匆忙去去移植 TB 級的資料相比起去修改程式碼中的一個邏輯錯誤來說是一個很巨大的工作。而在系統出問題後需要恢復 TB 級的資料，你會被硬碟的速度所限制，你會有一種絕望的感覺。

　　資料庫是一個很複雜的系統，對於開發者來說就像一個黑盒一樣。你需要對你所採用的資料庫持絕對信任的態度，信任它會做正確的事，並會保持一致性和可用性。

　　為什麼 MongoDB 會流行？

　　說句公道話，我們必需承認 MongoDB 是流行的，因為下面這些原因讓其流行變得很合理：

• 它非常容易地執行
• 非常自由的 Schema 模型，而且可以很容易地和 JSON 類的資料結果對映起來，這對於程式設計師來於有很大的感染力（它完全符合程式設計師的邏輯思維），而且，程式設計師總是在專案可以做技術選型的人。
• 成熟和健壯，track record，被真實的 Use Case 測試過，等等。對於那些喜歡選擇成熟的技術的系統管理員和運營專業來說，這是一個很典型的選擇。
• 它單系統，低併發讀的效能測試非常令人驚訝，而對於那些沒有經驗的評估者來說，這基本上來說是最重要的。

　　現在，你可能正在開發一個隨便玩一玩的網站，或是一個原型，或是那種只考慮開發速度不考慮別的的專案。老實說，對於這種專案，無所謂你用什麼樣的技術，只要搞定工作就行了。

　　但是，如果你想要在 MongoDB 上搞一個大規模的系統，在上面執行真實的業務，那麼，請不要用 MongoDB。

　　為什麼不？

　　1）MongoDB 為了贏得 Benchmark 測試而預設使用了不安全的寫方式

　　如果你不呼叫 getLastError ()，MongoDB 就不會在確認資料庫寫操作完成就返回了，這會引入至少兩種問題：

• 在併發的環境下（連線池等），在一個讀操作“完成”後的連續地讀操作會出錯，MongoDB 沒有“柵欄條件鎖”來知道什麼時候完成寫。
• 未知個數的儲存操作會被丟棄，因為儲存操作的佇列會在不同的地方。比如 TCP 快取等。當你和資料庫連線因為一些意味情況斷開的時候，這些東西就被丟棄了。

10gen CTO 回覆： 這和 Benchmark 沒有任何關係，並說這個就是 API 的設計，其交給使用者自己去選擇，因為寫的方式也有很多種。

　　2）MongoDB 會以令人震驚的方式丟失資料

　　下面是一個我們所經歷過的它丟資料的列表：

• 資料就是丟了，原因未知。
• 從損壞的資料庫中恢復資料不成功，如事務日誌。
• 主從結點間的資料複製有缺口，導致“從結點”丟失“主結點”有的資料。是的，沒有 CheckSum，並且是的，你還會看到複製狀態為“從結點”的當前狀態。
• 資料複製有時會停了，沒有錯誤。你要監控你的複製狀態！

10gen CTO 逐一回復：1）從來沒有一個數據丟失的 BUG 我們沒有馬上 fix 的事情。你能告訴我你報給我們的問題號嗎？我們至少要明白是怎麼一回事。如果是我們的問題，我們會馬上 fix 的。2）從損壞了的資料庫中不能完全恢復資料 ，這不挺正常的嗎？但是如果有主從伺服器互為備份應該會好一些。3）請告訴我你的問題號，我們從來沒有接到過這樣的錯誤報告。如果有，的確很嚴重。4）如果是說錯誤條件發生的時候沒有通知，這有可能。另外，你可以監控資料複製的寫操作，你可以使用 w=2 為 getLastError 的引數。

　　3）MongoDB 需要全域性寫鎖來請求寫操作

　　在寫操作頻繁的時候，這等同於殺了你。如果你執行一個 blog，你也許不會關心這個事，因為你的讀寫操作不高。

10gen CTO 回覆：讀寫鎖永遠都是問題，但是2.0會好很多，2.2會解決得更好一些。

　　4）MongoDB 的 Sharding (分割槽) 在高負載下會停止工作

　　在高負載下加一個 shard 是一場惡夢。Mongo 要麼會移動其資料塊太快而導致 DOS 攻擊產生很多流量佔用頻寬，要麼就完全地拒絕更多的資料塊。這會使一個高流量的網站承受著沉重地寫操作。

10gen CTO 回覆：如果系統已經超過了其負載，那麼移動資料當然會變得很難。我每一次的演講都說得很清楚，不要在系統性能不行的時候才去加 shard，這不行的。

　　5）Mongo 不可靠

　　Mongod/配置伺服器/mongos 的架構確實合理且聰明。不幸的是，mongos 完全就是垃圾。在有負載的情況下，它時不時就都會崩潰，有時幾個小時，有時幾天。程序重啟監控有時也不管用，因為它會丟擲一些斷言偽造出一個關鍵執行緒，導致程序還在執行。Double Fail。

　　最壞的是，唯一可行的方式是在一堆 mongos 例項前放一個 HaProxy (一種負載均衡器)，執行一個作業緩慢地輪著訪問這些 mongos 例項，並定期 kill 掉他們，以便可以重新啟動新的例項。我沒有在開玩笑。

10gen CTO 回覆：不可能有這種事，你能不能告訴我更多的細節？

　　6）MongoDB 有一次甚至刪除了整個資料庫

　　MongoDB 1.6，在資料同步配置中，有時會配置了一個錯誤的結點（經常是一個空結點）作為一個最新的資料結點。於是其它同步資料的結點上的資料就這樣被幹掉了（我說的是700GB 的好資料），因為其把這個空結點的資料同步回有資料的結點上。資料庫永遠永遠都不應該幹這個。如果出現這種問題，資料庫應該丟擲一個錯誤而讓 DBA 來選擇合理的操作，或是強制使用正確的配置。而不應該刪除所有的資料（那天真是太糟糕了）。

　　他們在1.8中修復了這個問題，偶滴神啊。

10gen CTO 回覆：找不到這樣的事，也找不到相應提交的程式碼，你能多給點資訊嗎？

　　7）釋出了一些不應該釋出東西

　　眾所周知，在穩定版裡能找到一些尷尬的 bug 會導致資料問題——而我們總是在出了問題後他們才告訴我們這些問題，這是因為我們購買了 10gen 他們那超級詐騙的白金技術支援。他們迴應是，發給我們一個 hot patch，他們內部叫 RC 的玩意，然後讓這個 hot patch 執行在我們的資料上。

10gen CTO 回覆：關於白金的技術支援，我們所接手的所有問題都會公開，fix 也會公開。沒有特定的情景，這種事很難討論。我們會根據不同的情況作出不同的反應。我們希望我們的使用者的問題能儘快得到解決。

　　8）複製器在繁忙的伺服器上黯然失色

　　複製器經常性的向 Master 發起 DOS 攻擊，或是複製非常慢，花了巨長無比的時間，而 oplog 幾乎被耗盡（就算是 50GB 的 oplog）。

　　我們有一個繁忙的，大的資料集，我們不會複製它，因為它是動態的。那是令人痛苦的一個月，或是我們需要在選擇不同的資料庫系統前交叉雙指（注：好運的手勢）

10gen CTO 回覆：這看起來像上伺服器負載過重了。我前面提到過了。

　　但是最糟糕的問題是：

　　你可能會說，我這些問題都是過去式了；他們修復了所有這些問題或是他們會在下一版本中修復這些問題；X問題可以用Y實踐來減輕。等等，等等。

　　不幸的是，你說這些東西一點用也沒有。

　　真正的問題是，這麼多的問題都是首要的問題。 資料庫開發者要能 hold 住比一般程式設計師更高的標準。也就是說，你的優先順序應該像下面這個樣子：

1. 別搞丟資料，對資料要有完全的把握
2. 通過實踐保證可用性
3. 多結點的效能擴充套件性
4. 最小延遲應該保持在99%和95%之間
5. 每個資源的每秒請求數

　　10gen 的順序好像是 #5 為第一，其它項隨便，#1 並不在前3位。

10gen CTO 回覆：這明顯不是真的。看一看我們提交的程式碼，看一看我們的 fix。 我們從來不會在 release 版中隱藏一個 bug。如果我們非常在乎效能的 benchmark 的話，我們會花精力解決那些鎖的問題，這樣一來，多執行緒併發會更快一些。

MongoDB 是一個新生的東西，還有很多東西需要打磨。如果你想來認識一下我們，我們歡迎你來認識一下我們。

　　這些失敗，還有那所暗示的公司的優先順序，指出了一個最基本的企業文化的問題，其會讓問題出現在任一發布版中：因為他們缺乏尊守必要的資料庫系統的設計律條。

　　請慎重考慮這些警告。

     原文來自：http://news.cnblogs.com/n/121155/