MongoDB核心貢獻(xiàn)者:不是不行,是你不懂!
近期MongoDB在Hack News上是頻繁中槍。許多人更是聲稱恨上了MongoDB，David mytton就在他的博客中揭露了MongoDB許多現(xiàn)存問(wèn)題。然而恨的人有之偏愛的也同樣很多，作為回?fù)簦篟ussell Smith帶來(lái)了多年工作經(jīng)驗(yàn)的總結(jié)。Russell Smith曾擔(dān)任Ops和大型網(wǎng)站縮放顧問(wèn)并且?guī)椭^(guò)Guardian、Experian等多家公司，MongoDB London User Group的聯(lián)合創(chuàng)始人。作為MongoDB Master（MongoDB官方認(rèn)可的MongoDB核心貢獻(xiàn)者組織，并通過(guò)社區(qū)分享自己的專業(yè)技術(shù)），其參與工作的基礎(chǔ)設(shè)施單服務(wù)器每秒查詢超過(guò)3萬(wàn)次，每天活躍數(shù)據(jù)更在1TB以上。
下面來(lái)看Russell對(duì)MongoDB一些常見及生僻的問(wèn)題做出分析：
32位 vs 64位
現(xiàn)在大多數(shù)的服務(wù)器都對(duì)32位操作系統(tǒng)實(shí)現(xiàn)支持，更有許多新型硬件支持著允許更多RAM的64位操作系統(tǒng)。
MongoDB也同時(shí)發(fā)布了32位及64位兩個(gè)版本的數(shù)據(jù)庫(kù)。歸結(jié)于MongoDB使用的內(nèi)存映射文件，32位版本只支持2G數(shù)據(jù)的存儲(chǔ)。對(duì)于標(biāo)準(zhǔn)的Replica Set，MongoDB只擁有單一的處理策略 —— mongod。如果你想在未來(lái)儲(chǔ)存2G以上的數(shù)據(jù)，請(qǐng)使用64位版本的MongoDB。如果擁有分片安裝，那么32位版本同樣可以使用。
總結(jié)：使用64位版本或者理解32位版本的限制。
文件大小限制
不同于RDBMS把數(shù)據(jù)儲(chǔ)存在行與列中，MongoDB的數(shù)據(jù)是儲(chǔ)存在文件中的。這些文件使用二進(jìn)制存儲(chǔ)形式，其格式為類似JSON格式的BSON格式。
和其它的數(shù)據(jù)庫(kù)一樣，單個(gè)文件的儲(chǔ)存大小是有限制的。在舊版本的MongoDB中，單個(gè)文件都限制在4M以內(nèi)。而新版本的MongoDB單文件已經(jīng)支持到16M大小。這樣的限制也許是令人厭煩的，但是10gen的意見是：如果這項(xiàng)設(shè)置不停的困擾到你，那么是否你的設(shè)計(jì)模式存在著問(wèn)題；或者你可以使用文件無(wú)大小限制的GridFS。
這種情況通常的建議是避免存儲(chǔ)過(guò)大的文件，不定期的更新數(shù)據(jù)庫(kù)中存儲(chǔ)的各種對(duì)象。而像Amazon S3或者Rackspace Cloudfiles這樣的服務(wù)通常可能會(huì)是更好的選擇，而非必要情況下***別讓基礎(chǔ)設(shè)施陷入過(guò)載。
總結(jié)：把每個(gè)文件保持在16M以下，那么一切都好。
寫入失敗
MongoDB在默認(rèn)的情況下允許高速的寫入和更新，而付出的代價(jià)就是沒有明確的錯(cuò)誤通知。默認(rèn)情況下多數(shù)的驅(qū)動(dòng)都在做異步、“不安全”寫入 —— 這就意味著驅(qū)動(dòng)程序不能立即反饋錯(cuò)誤信息，類似于MySQL的INSERT DELAYED。如果你想知道某個(gè)事情是否成功，你必須使用getLastError手動(dòng)的檢查錯(cuò)誤信息。
某些情況下如果你需要在錯(cuò)誤發(fā)生后立刻得到錯(cuò)誤信息，即：大多數(shù)的驅(qū)動(dòng)中都很容易實(shí)現(xiàn)同步“安全”查詢。這將謀殺掉MongoDB不同于傳統(tǒng)數(shù)據(jù)庫(kù)的優(yōu)點(diǎn)。
如果對(duì)比“完全安全”的同步寫入你需要多一點(diǎn)性能，同時(shí)還想要一定程度的安全，那么你可以使用getLastError with‘j’讓MongoDB只到一份日志提交后再發(fā)出錯(cuò)誤報(bào)告通知。那么日志將以100毫秒一次的速度輸出到磁盤，而不是60秒。
總結(jié)：如果必須要寫入確認(rèn)，你可以使用安全寫入或getLastError。
數(shù)據(jù)結(jié)構(gòu)模型的弱化不等于沒有數(shù)據(jù)結(jié)構(gòu)模型
RDBMS一般都擁有一個(gè)預(yù)定義的數(shù)據(jù)結(jié)構(gòu)模型：表格的行和列，每個(gè)字段都擁有名稱和數(shù)據(jù)類型。如果你想給其中一行加一列，那么你必須給整個(gè)表格都添加一列。
MongoDB則是移除了這個(gè)設(shè)置，對(duì)于Collection和文件沒有強(qiáng)制的模型限定。這有益于快速開發(fā)及簡(jiǎn)易修改。
當(dāng)然這不意味著你就可以無(wú)視結(jié)構(gòu)模型的設(shè)計(jì)，一個(gè)合適的結(jié)構(gòu)模型可以讓你獲得MongoDB的***性能。趕快閱讀MongoDB文檔，或者觀看這些結(jié)構(gòu)模型設(shè)計(jì)的相關(guān)視頻吧！
總結(jié)：設(shè)計(jì)結(jié)構(gòu)模型并充分利用MongoDB的特色。
默認(rèn)情況下修改語(yǔ)句修改的只是單個(gè)文件
在傳統(tǒng)的RDBMS中除非使用LIMIT子句，修改語(yǔ)句作用的將是所有匹配的地方。然而MongoDB每個(gè)查詢上都默認(rèn)使用等價(jià)“LIMIT 1”的設(shè)置。雖然無(wú)法做到“LIMIT 5”，但是你可以通過(guò)下面的語(yǔ)句整個(gè)的移除限制：
db.people.update({age: {$gt: 30}}, {$set: {past_it: true}}, false, true)
同樣在官方的驅(qū)動(dòng)中還有類似的選項(xiàng) —— ‘multi’。
總結(jié)：可以通過(guò)指定多個(gè)文件的multi為true來(lái)完成多文件修改
查詢區(qū)分大小寫
字符串的查詢可能不按預(yù)期的那樣發(fā)展 —— 這歸結(jié)于MongoDB默認(rèn)區(qū)分大小寫。
例如：db.people.find（{name: ‘Russell’}）與db.people.find（{name: ‘ russell‘}）是不同的。在這里最理想的解決方案就是對(duì)需要查詢數(shù)據(jù)進(jìn)行確認(rèn)。你也可以通過(guò)正則表達(dá)式進(jìn)行查詢，比如：db.people.find（{name:/Russell/i}），但是這樣會(huì)影響到性能。
總結(jié)：查詢是區(qū)分大小寫的，在犧牲速度的情況下可以利用正則表達(dá)式。
對(duì)輸入的數(shù)據(jù)無(wú)容錯(cuò)性
當(dāng)你嘗試向傳統(tǒng)數(shù)據(jù)庫(kù)插入錯(cuò)誤類型的數(shù)據(jù)，傳統(tǒng)的數(shù)據(jù)庫(kù)一般會(huì)把數(shù)據(jù)轉(zhuǎn)換成預(yù)定義的類型。然而這在MongoDB中是行不通的，因?yàn)镸ongoDB的文件是沒有預(yù)定義數(shù)據(jù)模型的。這樣的話MongoDB會(huì)插入你輸入的任何數(shù)據(jù)。
總結(jié)：使用準(zhǔn)確的數(shù)據(jù)類型。
關(guān)于鎖
當(dāng)資源被代碼的多個(gè)部分所共享時(shí)，需要確信鎖必須要確保這處資源只能在一個(gè)地方被操作。
舊版本的MongoDB （pre 2.0）擁有一個(gè)全局的寫入鎖。這就意味貫穿整個(gè)服務(wù)器中只有一個(gè)地方做寫操作。這就可能導(dǎo)致數(shù)據(jù)庫(kù)因?yàn)槟硞€(gè)地方鎖定超負(fù)載而停滯。這個(gè)問(wèn)題在2.0版本中的得到了顯著的改善，并且在當(dāng)前2.2版本中得到了進(jìn)一步的加強(qiáng)。MongoDB 2.2使用數(shù)據(jù)庫(kù)級(jí)別的鎖在這個(gè)問(wèn)題上邁進(jìn)了一大步。同樣值得期待的Collection級(jí)別的鎖也計(jì)劃在下一個(gè)版本中推出。
盡管如此，Russell還是認(rèn)為：大多數(shù)受此限制的應(yīng)用程序于其說(shuō)是受MongoDB影響，還不如說(shuō)是程序本身的問(wèn)題來(lái)的更直接。
總結(jié)：使用***的穩(wěn)定版本才能獲得***的性能。
關(guān)于包
在類Ubuntu和Debian系統(tǒng)上安裝時(shí)，許多人都出現(xiàn)過(guò)“過(guò)時(shí)版本”這樣的問(wèn)題。解決方案很簡(jiǎn)單：使用10gen官方庫(kù)，那么在Ubuntu和Debian上安裝也會(huì)像在Fedora和Centos上安裝一樣流暢。
總結(jié)：使用擁有大多數(shù)***版本的官方包。
使用偶數(shù)個(gè)Replica Set成員
Replica Set是增加冗余及提升MongoDB數(shù)據(jù)集群性能的有效途徑。數(shù)據(jù)在所有的節(jié)點(diǎn)中被復(fù)制，并選出一個(gè)作為主節(jié)點(diǎn)。假如主節(jié)點(diǎn)出故障，那么會(huì)在其他的節(jié)點(diǎn)中票選一個(gè)作為新的主節(jié)點(diǎn)。
在同一個(gè)Replica Set中使用兩臺(tái)機(jī)器是很有誘惑的，它比3臺(tái)機(jī)器來(lái)的便宜并且也是RDBMS的標(biāo)準(zhǔn)行事風(fēng)格。
但是到了MongoDB這里，同一個(gè)Replica Set中的成員數(shù)量只能是奇數(shù)個(gè)。假如你使用了偶數(shù)個(gè)成員，那么當(dāng)主節(jié)點(diǎn)發(fā)生故障時(shí)那么其它的節(jié)點(diǎn)都會(huì)變成只讀。發(fā)生這種情況是因?yàn)槭Ｏ麓x節(jié)點(diǎn)的數(shù)目不滿足票選主節(jié)點(diǎn)的規(guī)定。
如果你想節(jié)約成本，同時(shí)還希望支持故障轉(zhuǎn)移和冗余的增強(qiáng)，那么你可以使用Arbiter。Arbiter是一種特殊的Replica Set成員，它不儲(chǔ)存任何用戶數(shù)據(jù)（這就意味著他們可以使用非常小的服務(wù)器）。
總結(jié)：只可以使用偶數(shù)個(gè)Replica Set成員，但是可以使用Arbitter來(lái)削減成本。
沒有join語(yǔ)句
MongoDB不支持join：如果你想在多個(gè)Collection中檢索數(shù)據(jù)，那么你必須做多次的查詢。
如果你覺得你手動(dòng)做的查詢太多了，你可以重設(shè)計(jì)你的數(shù)據(jù)模型來(lái)減少整體查詢的數(shù)量。MongoDB中的文件可以是任何類型，那么可以輕易的對(duì)數(shù)據(jù)進(jìn)行De-Normalize。這樣就可以讓它始終和你的應(yīng)用程序保持一致。
總結(jié)：沒有join不妨看一下如何設(shè)計(jì)數(shù)據(jù)結(jié)構(gòu)模型。
Journaling
MongoDB使用內(nèi)存映射文件并且每60秒向磁盤輸出一次通知，這就意味著***程度上你可能丟失60秒加上向硬盤輸出通知這段時(shí)間內(nèi)所有的數(shù)據(jù)。
為了避免數(shù)據(jù)丟失，MongoDB從2.0版本起就添加了Journaling（默認(rèn)情況下開啟）。Journaling把時(shí)間從60秒更改為100ms。如果數(shù)據(jù)庫(kù)意外的停機(jī)，在啟動(dòng)之前它將會(huì)被重啟用以確保數(shù)據(jù)庫(kù)處于一致狀態(tài)。這也是MongoDB與傳統(tǒng)數(shù)據(jù)庫(kù)最接近的地方。
當(dāng)然Journaling會(huì)輕微的影響到性能，大約5%。但是對(duì)于多數(shù)人來(lái)說(shuō)額外帶來(lái)的安全性肯定是物有所值的。
總結(jié)：***別關(guān)閉Journaling。
#p#
默認(rèn)情況下沒有身份認(rèn)證
MongoDB在默認(rèn)設(shè)置下并沒有身份驗(yàn)證。MongoDB會(huì)認(rèn)為自身處在一個(gè)擁有防火墻的信任網(wǎng)絡(luò)。但是這不代表它不支持身份驗(yàn)證，如果需要可以輕松的開啟。
總結(jié)：MongoDB的安全性可以通過(guò)使用防火墻和綁定正確的接口來(lái)保證，當(dāng)然也可以開啟身份驗(yàn)證。
Replica Set中損失的數(shù)據(jù)
使用Replica Set是提高系統(tǒng)可靠性及易維護(hù)的有效途徑。這樣的話，弄清節(jié)點(diǎn)間故障的發(fā)生及轉(zhuǎn)移機(jī)制就變得至關(guān)重要。
Replica Set中的成員一般通過(guò)oplog（記錄了數(shù)據(jù)中發(fā)生增、刪、改等操作的列表）來(lái)傳遞信息，當(dāng)其中一個(gè)成員發(fā)生變化修改oplog后，其他的成員也將按照oplog來(lái)執(zhí)行。如果你負(fù)責(zé)處理新數(shù)據(jù)的節(jié)點(diǎn)在出錯(cuò)后恢復(fù)運(yùn)行，它將會(huì)被回滾至***一個(gè)oplog公共點(diǎn)。然而在這個(gè)過(guò)程中：丟失的“新數(shù)據(jù)”已經(jīng)被MongoDB從數(shù)據(jù)庫(kù)中轉(zhuǎn)移并存放到你的數(shù)據(jù)目錄‘rollback’里面等待被手動(dòng)恢復(fù)。如果你不知道這個(gè)特性，你可能就會(huì)認(rèn)為數(shù)據(jù)被弄丟了。所以每當(dāng)有成員從出錯(cuò)中恢復(fù)過(guò)來(lái)都必須要檢查這個(gè)目錄。而通過(guò)MongoDB發(fā)布的標(biāo)準(zhǔn)工具來(lái)恢復(fù)這些數(shù)據(jù)是件很容易的事情。查看官方文檔以了解更多相關(guān)信息。
總結(jié)：故障恢復(fù)中丟失的數(shù)據(jù)將會(huì)出現(xiàn)在rollback目錄里面。
分片太遲
分片是把數(shù)據(jù)拆分到多臺(tái)機(jī)器上，通常被用于Replica Set運(yùn)行過(guò)慢時(shí)進(jìn)行性能提升。MongoDB支持自動(dòng)分片。然而如果你讓分片進(jìn)行太遲的話，問(wèn)題就產(chǎn)生了。因?yàn)閷?duì)數(shù)據(jù)的拆分和塊的遷移需要時(shí)間和資源，所以如果當(dāng)服務(wù)器資源基本上耗盡時(shí)很可能會(huì)導(dǎo)致在你最需要分片時(shí)卻分不了片。
解決的方法很簡(jiǎn)單，使用一個(gè)工具對(duì)MongoDB進(jìn)行監(jiān)視。對(duì)你的服務(wù)器做最準(zhǔn)確的評(píng)估，并且在占整體性能的80%前進(jìn)行分片。類似的監(jiān)視工具有：MMS、Munin（+Mongo Plugin）和CloudWatch。
如果你確定從一開始就要分片處理，那么更好的建議會(huì)是選用AWS或者類似的云服務(wù)進(jìn)行分片。而在小型服務(wù)器上，關(guān)機(jī)或者是調(diào)整機(jī)器明顯比轉(zhuǎn)移成千上萬(wàn)條數(shù)據(jù)塊來(lái)的更直接一點(diǎn)。
總結(jié)：盡早的分片才能有效的避免問(wèn)題。
不可以更改文件中的shard key
對(duì)于分片設(shè)置，shard key是MongoDB用來(lái)識(shí)別分塊對(duì)應(yīng)文件的憑證。當(dāng)你插入一個(gè)文件后，你就不可以對(duì)文件的shard key進(jìn)行更改。而這里的解決方案是把文檔刪除然后重新建立，這樣就允許把它指定到對(duì)應(yīng)的分塊了。
總結(jié)：shard key不可以修改，必要的時(shí)候可以刪除文件重新建立。
不可以對(duì)256G以上的Collection進(jìn)行分片
重新回到分片太遲的問(wèn)題上來(lái) —— MongoDB不允許對(duì)增長(zhǎng)到256G以上的Collection進(jìn)行分片，之前版本的設(shè)置還沒有256G。這個(gè)限定在以后肯定會(huì)被移除，而這里也沒有更好的解決方案。只能進(jìn)行重編譯或者把大小控制在256G以下。
總結(jié)：在Collection達(dá)到256G以前進(jìn)行分片。
唯一性索引與共享
索引的唯一性約束只能通過(guò)shard key來(lái)保證。
選擇了錯(cuò)誤的shard key
MongDB需要你選擇一個(gè)shard key來(lái)將數(shù)據(jù)分片。如果選擇了錯(cuò)誤的shard key,更改起來(lái)將是件很麻煩的事情。
總結(jié)：選擇shard key之前先閱讀這個(gè)文檔。
與MongoDB通信的未經(jīng)加密
與MongoDB的連接默認(rèn)情況下都是非加密的，這就意味你的數(shù)據(jù)可能被第三方記錄和使用。如果你的MongoDB是在自己的非廣域網(wǎng)下使用，那么這種情況是不可能發(fā)生的。
然而如果你是通過(guò)公網(wǎng)訪問(wèn)MongoDB的話，那么你肯定會(huì)希望你的通信是經(jīng)過(guò)加密的。公版的MongoDB是不支持SSL的。慶幸的是可以非常簡(jiǎn)單的定制自己的版本。10gen的用戶則擁有特別定制的加密版本。幸運(yùn)的是大部分的官方驅(qū)動(dòng)都支持SSL，但是小麻煩同樣是不可避免的。點(diǎn)擊查看文檔。
總結(jié)：當(dāng)用公網(wǎng)連接時(shí)，要注意和MongoDB的通信是未加密的。
事務(wù)
不像MySQL這些支持多行數(shù)據(jù)原子操作的傳統(tǒng)數(shù)據(jù)庫(kù)，MongoDB只支持單文件的原子性修改。解決這個(gè)問(wèn)題的方法之一是在應(yīng)用程序中使用異步提交的方式；另一個(gè)是：建立一個(gè)以上的數(shù)據(jù)存儲(chǔ)。雖然***種方法并不適用于所有情況，但是很顯然比第二個(gè)來(lái)的要好。
總結(jié)：不支持對(duì)多文件事務(wù)。
日志預(yù)分配慢
MongDB可能會(huì)告訴你已經(jīng)準(zhǔn)備就緒，但事實(shí)上它還在對(duì)日志進(jìn)行分配。如果你選擇了讓機(jī)器自行分配，而恰巧你的文件系統(tǒng)和磁盤速度又很慢，那么煩惱的事情發(fā)生了。通常情況下這不會(huì)成為問(wèn)題，但是一旦出現(xiàn)了可以使用undocumented flag –nopreallocj來(lái)關(guān)閉預(yù)分配。
總結(jié)：如果機(jī)器文件系統(tǒng)和磁盤過(guò)慢的話，那么日志的預(yù)分配也可能很慢。
NUMA + Linux +MongoDB
Linux、NUMA與MongoDB遇到一起的時(shí)候運(yùn)行總是不會(huì)很好。如果你在NUMA硬件上運(yùn)行MongoDB的話，這里建議是直接關(guān)掉。因?yàn)楦鞣N奇怪的問(wèn)題隨之而來(lái)，比如：速度會(huì)階段性或者在CPU占用率很高的時(shí)候大幅下降。
總結(jié)：禁NUMA。
Linux里面的進(jìn)程限制
如果你在MongoDB未滿載的時(shí)候出過(guò)SEGMENTATION FAULT錯(cuò)誤，你可能會(huì)發(fā)現(xiàn)這是因?yàn)槭褂昧诉^(guò)低或者默認(rèn)的打開文件或用戶進(jìn)程限制。10gen建議把限制設(shè)置在4K+，然而設(shè)置的大小該取決具體情況。閱讀ulimit了解更多。
總結(jié)：長(zhǎng)久的為MongoDB在Linux加上軟或硬的打開文件或用戶進(jìn)程限制。
