用還是不用MongoDB？悲催用戶炮轟10gen CTO
前幾天在HackNew上出現了一篇文章，標題很彪悍，叫《Don’t use MongoDB》，其內容也是直接表達了對MongoDB的不滿，作者列舉了MongoDB使用過程中遇到的種種問題。甚至上升到對其開發團隊的質疑，表示他們可能只關心benchmark的數據，不關心用戶數據的安全性。真是大叫坑爹??！
***消息：這篇文章的作者已經承認文章只是他的一個惡作劇，他稱只是想做個實驗，以顯示控制一個人的思維是多么容易。但是他提到的案例并非完全沒有出現過，這樣一篇惡作劇的文章，雖然著實唬了我們一把，但是能夠讓一些盲目的朋友更謹慎一些。還是有好處的。
但很快地，10gen CTO @ehwizard 就看到了這篇文章，并馬上對作者提到的各個問題進行了回應。ehwizard表示，他翻遍了1600個用戶案例報告，并沒有發現出現了文章作者所說這些問題的案例（實際上也是對指責的真實性進行了懷疑。你是哪個單位的？）。隨后ehwizard又友好的表示，如果你在使用MongoDB中遇到問題，可以隨時到MongoDB的Google Group或者MongoDB相應的IRC中進行報告。
在MongoDB正被炒得火熱的今天，相信這樣一篇文章也著實向一些同學澆了一頭冷水。所以NoSQLFan將二者PK觀點都放在這里，大家可以自己看一看，甚至做做實驗，在使用NoSQL或者是其它新技術前，也都多了解一些可能出現的問題。
下面綠色部分是原文作者對MongoDB的一些指責和質疑，紅色部分為NoSQLFan的無聊演繹，其余為10gen CTO ehwizard的回應。
1. MongoDB為了在benchmark上好看一些，不惜將不安全的方案作為其默認配置。（就差大叫無良奸商了）
ehwizard說，哥們你這個說法有點過份了，MongoDB的默認方案的選擇，和benchmark根本就一點關系都沒有，而且不僅是默認方案，包括API的設計，以及MongoDB其它的一些功能取舍，都和benchmark沒有半毛錢關系。當然，默認配置的設定還是需要和用戶主要的使用場景相關，MongoDB在使用上確實已經經歷了很多變化，對這些變化做出相應的默認策略調整，確實也有可能。
當然，話說回來，MongoDB的實現策略的實現，本身是可控的。比如你可以選擇寫操作的安全級別，在你使用了replica sets的時候，你完全可以設定一個寫操作同步到一定機器數量后才返回成功。（對作者一大嘴巴子，您這是真不懂呢還是裝不懂呢）
2. MongoDB丟數據現象嚴重，并且導致的情況很多
2.1 MongoDB經常詭異的丟失數據
對此ehwizard的回應是，對于丟數據的問題，我們收到過bug報告，但是我們對MongoDB非常了解，所有的bug在收到后，幾乎都在***時間進行了修復。如果你能夠給出你丟數據時的使用場景，我們會盡可能找出原因。ehwizard表示，如果你真的發生了丟數據的問題，請馬上聯系10gen的工程師進行bug修復。（哥們，有問題，找組織，不丟人）
2.2 在不使用journaling的時候，如果MongoDB崩潰，數據無法恢復
ehwizard解釋說，這是正常的情況，對于單機使用MongoDB來說，不使用journaling日志本身就是不推薦的危險做法，在2.0版本后，journaling日志已經是默認開啟了。而如果是在replica sets等多機的情況下，你根本不需要進行數據恢復，只需要從另一個同步節點resync數據就可以了。
2.3 主從復制有問題，存在丟失數據的操作，主從之間沒有同步校驗。并且雖然數據丟了，但是在狀態上顯示還是同步正常的
ehwizard表示這種情況應該不會發生，如果確實發生了，應該是嚴重bug。
2.4 主從復制存在不明原因的中斷現實，沒有任何錯誤就直接中斷了
ehwizard說這確實有可能發生，可能中間確實出錯了，只是出錯信息并沒有返回給客戶端而已。因為復制操作本身是異步進行的，如果你希望數據同步復制完后才返回，你可以通過getLastError命令將w參數設定為2。
3. MongoDB在進行寫操作時使用了一個全局的寫鎖，這樣效率很低
這一點上ehwizard也承認這確實是MongoDB長期被詬病的問題，但是目前在2.0版本中已經做了相當大的改進。已經對寫操作需要涉及到磁盤IO的情況下進行了優化。而在2.2版本中，這一優化還會進一步推進。（哥們，針對collection的lock啥時候來?。?/p>
4. 大壓力比較大的時候，MongoDB的auto-sharding功能會出現問題，在大負載下，添加一個sharding結點絕對是場噩夢。因為這時候MongoDB只要去做chunk的移動，就會影響本身服務，要么就只能不做移動。
ehwizard解釋說，如果系統確實已經到達極限，這時候再去做chunk塊的移動確實不容易。關于這個話題他自己已經在很多場合說過，他的建議是盡早監測到集群已經快到極限了，不要等到系統已經到了100%負載的時候再去做添加節點的操作。（對自己的業務增長上點心，別跟4sq一樣火燒眉毛了才發現）
5. mongos非常不可靠，雖然 mongod/config server/mongos 結合的架構看起來很美，但是mongos確實很不給力。當壓力稍大一點，mongos就經常崩潰，少則幾天崩潰一次，多則幾小時就崩潰一次。有時候會出現拋出斷言然后殺掉某個關鍵線程，但是這時候進程居然還依然運行，所以重啟管理進程也不是每次都管用。
ehwizard表示不知道他所謂的關鍵線程是什么，希望能夠多提供一些相關細節。
6. MongoDB曾經出現過一次問題，導致所有數據被刪除了。這個情況發生在 MongoDB 1.6版本的replica sets結構中，由于選舉策略出現問題，導致選擇了一個空數據節點作為新的primary，這樣導致那些有數據的節點都把自己的數據給刪除了，我們700G的數據就這樣沒了。還好在1.8版本中修復了這個問題。
ehwizard說查看了相關的報告，并沒有發現有所說的問題，希望能夠提供更多細節。
7. 10gen的人發布了一些還不能發布的東西。據我們所知，在一些stable版本中居然會有一些導致數據問題的bug，而通常我們在遇到這些bug的時候才會發現。我們購買了10gen的白金級服務，但是得到的結果只是一些被他們稱為內部RC版本的熱補丁，而我們需要將這些補丁打在我們線上版本上。天哪！
ehwizard表示我們并沒有什么白金合同，所有的問題都是通過公開的jira系統來反饋的。從問題的提出和修改，都是在jira上公示的，（比尼瑪官員的財產還透明）。如果你不能提供更多的信息，這個真的不好再討論。我們通常的做法是在修復了問題后會盡快的通知到相應的用戶。
8. 在負載比較高的機器上，同步工作相當廢柴
感覺應該是負載過高了，跟我之前說的一樣，同步默認是異步的，如果你希望確認同步成功，可以通過getLastError命令設置w參數為2。
而上面的問題可能已經有一些修復了，但是我想說的是，作為一個公司，還是應該將服務的可靠性放在***位。我認為10gen應該按下面的優先級來進行MongoDB的功能開發：
1. 不要丟數據，對數據一定要非常小心2. 多做測試，保證可靠性3. 做到真正的多節點擴展性4. 除低延遲5. 提高對資源的請求性能
而在我看來，10gen眼中可能就在意第5個，而***點估計在他們眼中連前三都進不了。
看到這個，ehwizard同學不認同了（這是從道德層面上質疑?。?，他表示10gen絕不是像作者說的那樣，他說你可以看一下我們bug修復的列表，這些都是公開的，我們從來沒有說偷偷的改掉某個bug了事，或者說只跟一些特殊用戶說明這些bug。如果我們真的那么在意讀寫性能，我們早就修復了那些浪費CPU的問題了。如果我們真的那么在意benchmark的話，我們早就優化了全局鎖的問題了，這東西對多線程的benchmark結果是有非常大的改進的。更何況一般的benchmark都是多線程跑的，我們并不那么在意benchmark的數據。（我的benchmark已經很牛X的好不好）
MongoDB確實還很新，還有很多問題。如果你想來跟我們討論一些MongoDB相關的問題，我們的的辦公室為你敞開，我們會以非常開放的態度對待你提出的問題，所以如果真的有問題，我們非常期待與你的溝通。
【編輯推薦】
