千萬別用MongoDB？真的嗎？！

　某人發了一篇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類的數據結果映射起來，這對於程序員來於有很大的感染力（它徹底符合程序員的邏輯思惟），並且，程序員老是在項目能夠作技術選型的人。
• 成熟和分健壯，有記錄，被真實的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是一個新生的東西，還有不少東西須要打磨。若是你想來認識一下咱們，咱們歡迎你來認識一下咱們。

　　這些失敗，還有那所暗示的公司的優先級，指出了一個最基本的企業文化的問題，其會讓問題出如今任一發布版中：由於他們缺少尊守必要的數據庫系統的設計律條。

　　請慎重考慮這些警告。