某人發(fā)了一篇Don’t use MongoDB的血淚控訴，我把原文翻譯如下，你可以看看。不過，我想我們還要去看看10gen CTO的對(duì)此事的回復(fù)，我們還要去在Reddit上看看大家的說法，10gen CTO的對(duì)此事的回復(fù)后面也有一堆人在討論這個(gè)事，還有一些程序員開始去讀MongoDB的源碼了，呵呵?？礃幼?，說MongoDB的這些事并不是真的。

　　10gen CTO 對(duì)此事的并不完全知道，其在回復(fù)，對(duì)些文中的每一條都做了回復(fù)。我把其回復(fù)的大體意思也放在原文中。不過，很有意思的是那些程序員的討論。建議大家看看。

　　正文

　　因?yàn)楦鞣N政治原因，我這段時(shí)間沒有說什么，但是現(xiàn)在我覺得因?yàn)橐獙?duì)社會(huì)負(fù)責(zé)，所以我要阻止大家不要把你們的業(yè)務(wù)放在MongoDB上。

　　我的團(tuán)隊(duì)在一個(gè)有巨大用戶量（一個(gè)有千萬用戶級(jí)的大型的公司）系統(tǒng)上使用的MongoDB，這個(gè)系統(tǒng)上讓MongoDB有非常大的負(fù)載。早期，我們以為使用MongoDB會(huì)像10gen公司（MongoDB背后的公司）宣揚(yáng)其在長期性能擴(kuò)展有很多好處。但是，我們錯(cuò)了，而這個(gè)rant(長篇抱怨)就是為了讓你不要相信那些所謂的成功經(jīng)驗(yàn)而和我們一樣犯了大錯(cuò)。如果有人能避免你上當(dāng)，那么就得我寫這么多。希望能警醒更多的人。

　　注意，對(duì)于和10gen打交道的經(jīng)歷來說，他們給予了我們充分了熱情和幫助，而且非常地好。但是這并不能成為我不告訴大家他們的產(chǎn)品失敗的理由。

　　為什么這么說？

　　數(shù)據(jù)庫應(yīng)該是正確的，或是僅可能的正確，因?yàn)閿?shù)據(jù)庫的錯(cuò)誤會(huì)比其它使用更大。不僅僅是因?yàn)槠鋵?duì)運(yùn)行，性能，開銷，和其價(jià)值影響巨大，還因?yàn)槠溥B帶的東西。匆忙去去移植TB級(jí)的數(shù)據(jù)相比起去修改代碼中的一個(gè)邏輯錯(cuò)誤來說是一個(gè)很巨大的工作。而在系統(tǒng)出問題后需要恢復(fù)TB級(jí)的數(shù)據(jù)，而你即被限制住了，你會(huì)有一種絕望的感覺。

　　數(shù)據(jù)庫是一個(gè)很復(fù)雜的系統(tǒng)，對(duì)于開發(fā)者來說就像一個(gè)黑盒一樣。你需要對(duì)你所采用的數(shù)據(jù)庫持絕對(duì)信任的態(tài)度，信任它會(huì)做正確的事，并盡會(huì)保持 一致笥和可用性。

　　為什么MongoDB會(huì)流行？

　　說句公道話，我們必需承認(rèn)MongoDB是流行的，因?yàn)橄旅孢@些原因讓其流行變得很合理：

• 它非常容易地運(yùn)行
• 非常自由的Schema模型，而且可以很容易地和JSON類的數(shù)據(jù)結(jié)果映射起來，這對(duì)于程序員來于有很大的感染力（它完全符合程序員的邏輯思維），而且，程序員總是在項(xiàng)目可以做技術(shù)選型的人。
• 成熟和分健壯，有記錄，被真實(shí)的Use Case測試過，等等。對(duì)于那些喜歡選擇成熟的技術(shù)的系統(tǒng)管理員和運(yùn)營專業(yè)來說，這是一個(gè)很典型的選擇。
• 它單系統(tǒng)，低讀并發(fā)的性能測試非常令人驚訝，而對(duì)于那些沒有經(jīng)驗(yàn)的評(píng)估者來說，這基本上來說是最重要的。

　　現(xiàn)在，你可能正在開發(fā)一個(gè)隨便玩一玩的網(wǎng)站，或是一個(gè)原型，或是那種只考慮開發(fā)速度不考慮別的的項(xiàng)目。老實(shí)說，對(duì)于這種項(xiàng)止，無所謂你用什么樣的技術(shù)，只要搞定工作就行了。

　　但是，如果你想要在MongoDB上搞一個(gè)大規(guī)模的系統(tǒng)，在上面運(yùn)行真實(shí)的業(yè)務(wù)，那么，請(qǐng)不要用MongoDB。

　　為什么不？

　　1）MongoDB為了贏得Benchmark測試而默認(rèn)使用了不安全的寫方式

　　如果你不調(diào)用getLastError()，MongoDB就不會(huì)在確認(rèn)數(shù)據(jù)庫寫操作完成就返回了，這會(huì)引入至少兩種問題：

• 在并發(fā)的環(huán)境下（連接池，等），在一個(gè)讀操作“完成”后的連續(xù)地讀操作會(huì)出錯(cuò)，MongoDB沒有“柵欄條件鎖”來知道什么時(shí)候完成寫。
• 未知個(gè)數(shù)的保存操作會(huì)被丟棄，因?yàn)楸４娌僮鞯年?duì)列會(huì)在不同的地方。比如TCP緩存等。當(dāng)你和數(shù)據(jù)庫連接因?yàn)橐恍┮馕肚闆r斷開的時(shí)候，這些東西就被丟棄了。

10gen CTO 回復(fù)： 這和Benchmark沒有任何關(guān)系，并說這個(gè)就是API的設(shè)計(jì)，其交給用戶自己去選擇，因?yàn)閷懙姆绞揭灿泻芏喾N。

　　2）MongoDB會(huì)以令人震驚的方式丟失數(shù)據(jù)

　　下面是一個(gè)我們所經(jīng)歷過的它丟數(shù)據(jù)的列表：

• 數(shù)據(jù)就是丟了，原因未知
• 從損壞的數(shù)據(jù)庫中恢復(fù)數(shù)據(jù)不成功，如事務(wù)日志。
• 主從結(jié)點(diǎn)間的數(shù)據(jù)復(fù)制有缺口，導(dǎo)致從結(jié)點(diǎn)丟失主結(jié)點(diǎn)有的數(shù)據(jù)。是的，沒有CheckSum，并且是的，你還會(huì)看到數(shù)據(jù)復(fù)制過去了。
• 數(shù)據(jù)復(fù)制有時(shí)會(huì)停了，沒有錯(cuò)誤。你可以監(jiān)控你的復(fù)制狀態(tài)。

10gen CTO 逐一回復(fù)：1）從來沒有一個(gè)數(shù)據(jù)丟失的BUG我們沒有馬上fix的事情。你能告訴我你報(bào)給我們的問題號(hào)嗎？我們至少要明的是怎么一回事。如果是我們的問題，我們會(huì)馬上fix的。2）從損壞了的數(shù)據(jù)庫中不能完全恢復(fù)數(shù)據(jù) ，這不挺正常的嗎？但是如果有主從服務(wù)器互為備份應(yīng)該會(huì)好一些。3）請(qǐng)告訴我你的問題號(hào)，我們從來沒有接到過這樣的錯(cuò)誤報(bào)告。如果有，的確很嚴(yán)重。4）如果是說錯(cuò)誤條件發(fā)生的時(shí)候沒有通知，這有可能。另外，你可以監(jiān)控?cái)?shù)據(jù)復(fù)制的寫操作，你可以使用w=2 為getLastError的參數(shù)。

　　3）MongoDB 需要全局寫鎖來請(qǐng)求寫操作

　　在寫操作頻繁的時(shí)候，這等同于殺了你。如果你運(yùn)行一個(gè)blog，你也許不會(huì)關(guān)心這個(gè)事，因?yàn)槟愕淖x寫操作不高。

10gen CTO 回復(fù)：讀寫鎖永遠(yuǎn)都是問題，但是2.0會(huì)好很多，2.2會(huì)解決得更好一些。

　　4）MongoDB 的Sharding(分區(qū)) 在高負(fù)載下會(huì)停止工作

　　在高負(fù)載下加一個(gè)shard是一場惡夢(mèng)。Mongo要么會(huì)移動(dòng)其數(shù)據(jù)塊太快而導(dǎo)致DOS攻擊產(chǎn)生很多流量占用帶寬，要么就完全地拒絕更多的數(shù)據(jù)塊。這會(huì)使一個(gè)高流量的網(wǎng)站承受著沉重地寫操作。

10gen CTO 回復(fù)：如果系統(tǒng)已經(jīng)超過了其負(fù)載，那么移動(dòng)數(shù)據(jù)當(dāng)然會(huì)變得很難。我每一次的演講都說得很清楚，不要在系統(tǒng)性能不行的時(shí)候才去加shard，這不行的。

　　5）Mongo 不可靠

　　Mongod/配置服務(wù)器/mongos的架構(gòu)確定合理且聰明。不幸的是，mongos完全就是垃圾。在有負(fù)載的情況下，它時(shí)不時(shí)就都會(huì)崩潰，有時(shí)幾個(gè)小時(shí)，有時(shí)幾天。進(jìn)程重啟監(jiān)控有時(shí)也不管用，因?yàn)樗麜?huì)拋出一些斷言會(huì)偽造出一個(gè)關(guān)鍵線程，其導(dǎo)致進(jìn)程還在運(yùn)行。Double Fail。

　　最壞的是，唯一可行的方式是在一堆mongos實(shí)例前放一個(gè)HaProxy(一種負(fù)載均衡器)，運(yùn)行一個(gè)作業(yè)其緩慢地輪著訪問這些mongos實(shí)例，并定期kill掉他們，以變可以重新啟動(dòng)新的實(shí)例。我沒有在開玩笑。

10gen CTO 回復(fù)：不可能有這種事，你能不能告訴我更多的細(xì)節(jié)？

　　6）MongoDB有一次甚至刪除了整個(gè)數(shù)據(jù)庫

　　MongoDB 1.6，在數(shù)據(jù)同步配置中，有時(shí)會(huì)配置了一個(gè)錯(cuò)誤的結(jié)點(diǎn)（經(jīng)常是一個(gè)空結(jié)點(diǎn)）是一個(gè)最新的數(shù)據(jù)結(jié)點(diǎn)。于是其它同步數(shù)據(jù)的結(jié)果上的數(shù)據(jù)就這樣被干掉了（我說的是700GB的好數(shù)據(jù)），因?yàn)槠浒堰@個(gè)空結(jié)點(diǎn)的數(shù)據(jù)同步回有數(shù)據(jù)的結(jié)點(diǎn)上。數(shù)據(jù)庫永遠(yuǎn)永遠(yuǎn)都不應(yīng)該干這個(gè)。如果出現(xiàn)這種問題，數(shù)據(jù)庫應(yīng)該拋出一個(gè)錯(cuò)誤而讓DBA來選擇合理的操作，或是強(qiáng)制使用正確的配置。而不應(yīng)該刪除所有的數(shù)據(jù)（那天太糟糕了）。

　　他們?cè)?.8中修復(fù)了這個(gè)問題，偶滴神啊。

10gen CTO 回復(fù)：找不到這樣的事，也找不到相應(yīng)提交的代碼，你能多給點(diǎn)信息嗎？

　　7）發(fā)布了一些不應(yīng)該發(fā)布東西

　　眾所周知，在穩(wěn)定版里能找到一些尷尬的bug其會(huì)導(dǎo)致數(shù)據(jù)問題——而我們總是在出了問題后他們才告訴我們這些問題，這是因?yàn)槲覀冑徺I了10gen他們那超級(jí)詐騙的白金技術(shù)支持。他們回應(yīng)是，發(fā)給我們一個(gè)hot patch，他們內(nèi)部叫RC的玩意，然后讓這個(gè)hot patch運(yùn)行在我們的數(shù)據(jù)上。

10gen CTO 回復(fù)：關(guān)于白金的技術(shù)支持，我們所接手的所有問題都會(huì)公開，fix也會(huì)公開。沒有特定的情景，這種事很難討論。我們會(huì)根據(jù)不同的情況作出不同的反應(yīng)。我們希望我們的用戶的問題能盡快得到解決。

　　8）復(fù)制器在繁忙的服務(wù)器上黯然失色

　　復(fù)制器經(jīng)常性的向Master發(fā)起DOS攻擊，或是復(fù)制非常慢，花了巨長無比的時(shí)間，而oplog幾乎被耗盡（就算是50GB的oplog）。

　　我們有一個(gè)繁忙的，大的數(shù)據(jù)集我們不會(huì)復(fù)制他因?yàn)樗莿?dòng)態(tài)的。那是令人痛苦的一個(gè)月，或是我們需要在選擇不同的數(shù)據(jù)庫系統(tǒng)前交叉雙指（注：好運(yùn)的手勢(shì)）

10gen CTO 回復(fù)：這看起來像上服務(wù)器負(fù)載過重了。我前面提到過了。

　　但是最糟糕的問題是：

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

　　不幸的是，你說這些東西一點(diǎn)用也沒有。

　　真正的問題是，這么多的問題都是首要的問題。 數(shù)據(jù)庫開發(fā)者要能hold住比一般程序員更高的標(biāo)準(zhǔn)。也就是說，你的優(yōu)先級(jí)應(yīng)該像下面這個(gè)樣子：

1. 別搞丟數(shù)據(jù)，對(duì)數(shù)據(jù)要有完全的把握
2. 通過實(shí)踐保證可用性
3. 多結(jié)點(diǎn)的性能擴(kuò)展性
4. 最小延遲應(yīng)該保持在99%和95%之間
5. 每個(gè)資源的每秒請(qǐng)求數(shù)

　　10gen的順序好像是 #5  為每一，其它項(xiàng)隨便，#1 并不在前3位。

10gen CTO 回復(fù)：這明顯不是真的?？匆豢次覀兲峤坏拇a，看一看我們的fix。 我們從來不會(huì)在release版中隱藏一個(gè)bug。如果我們非常在乎性能的benchmark的話，我們會(huì)花精力解決那些鎖的問題，這樣一來，多線程并發(fā)會(huì)更快一些。

MongoDB是一個(gè)新生的東西，還有很多東西需要打磨。如果你想來認(rèn)識(shí)一下我們，我們歡迎你來認(rèn)識(shí)一下我們。

　　這些失敗，還有那所暗示的公司的優(yōu)先級(jí)，指出了一個(gè)最基本的企業(yè)文化的問題，其會(huì)讓問題出現(xiàn)在任一發(fā)布版中：因?yàn)樗麄內(nèi)狈ψ鹗乇匾臄?shù)據(jù)庫系統(tǒng)的設(shè)計(jì)律條。

　　請(qǐng)慎重考慮這些警告。

it知識(shí)庫：千萬別用MongoDB？真的嗎？！，轉(zhuǎn)載需保留來源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請(qǐng)第一時(shí)間聯(lián)系我們修改或刪除，多謝。