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