近期MongoDB在Hack News上是平凡中槍。許多人更是聲稱恨上了MongoDB，David mytton就在他的博客中揭露了MongoDB許多現存問題。然而恨的人有之偏愛的也同樣很多，作為回擊：Russell Smith帶來了多年工作經驗的總結。Russell Smith曾擔任Ops和大型網站縮放顧問并且幫助過Guardian、Experian等多家公司，MongoDB London User Group的聯合創始人。作為MongoDB Master(MongoDB官方認可的MongoDB核心貢獻者組織，并通過社區分享自己的專業技術)，其參與工作的基礎設施單服務器每秒查詢超過3萬次，每天活躍數據更在1TB以上。

下面來看Russell對MongoDB一些常見及生僻的問題做出分析：

32位 vs 64位

現在大多數的服務器都對32位操作系統實現支持，更有許多新型硬件支持著允許更多RAM的64位操作系統。

MongoDB也同時發布了32位及64位兩個版本的數據庫。歸結于MongoDB使用的內存映射文件，32位版本只支持2G數據的存儲。對于標準的Replica Set，MongoDB只擁有單一的處理策略 —— mongod。如果你想在未來儲存2G以上的數據，請使用64位版本的MongoDB。如果擁有分片安裝，那么32位版本同樣可以使用。

總結：使用64位版本或者理解32位版本的限制。

文檔大小限制

不同于RDBMS把數據儲存在行與列中，MongoDB的數據是儲存在文件中的。這些文件使用二進制存儲形式，其格式為類似JSON格式的BSON格式。

和其它的數據庫一樣，單個文件的儲存大小是有限制的。在舊版本的MongoDB中，單個文件都限制在4M以內。而新版本的MongoDB單文件已經支持到16M大小。這樣的限制也許是令人厭煩的，但是10gen的意見是：如果這項設置不停的困擾到你，那么是否你的設計模式存在著問題;或者你可以使用文件無大小限制的GridFS。

這種情況通常的建議是避免存儲過大的文件，不定期的更新數據庫中存儲的各種對象。而像Amazon S3或者Rackspace Cloudfiles這樣的服務通常可能會是更好的選擇，而非必要情況下最好別讓基礎設施陷入過載。

總結：把每個文件保持在16M以下，那么一切都好。

寫入失敗

MongoDB在默認的情況下允許高速的寫入和更新，而付出的代價就是沒有明確的錯誤通知。默認情況下多數的驅動都在做異步、“不安全”寫入 —— 這就意味著驅動程序不能立即反饋錯誤信息，類似于MySQL的INSERT DELAYED。如果你想知道某個事情是否成功，你必須使用getLastError手動的檢查錯誤信息。

某些情況下如果你需要在錯誤發生后立刻得到錯誤信息，即：大多數的驅動中都很容易實現同步“安全”查詢。這將謀殺掉MongoDB不同于傳統數據庫的優點。

如果對比“完全安全”的同步寫入你需要多一點性能，同時還想要一定程度的安全，那么你可以使用getLastError with‘j’讓MongoDB只到一份日志提交后再發出錯誤報告通知。那么日志將以100毫秒一次的速度輸出到磁盤，而不是60秒。

總結：如果必須要寫入確認，你可以使用安全寫入或getLastError。

數據結構模型的弱化不等于沒有數據結構模型

RDBMS一般都擁有一個預定義的數據結構模型：表格的行和列，每個字段都擁有名稱和數據類型。如果你想給其中一行加一列，那么你必須給整個表格都添加一列。

MongoDB則是移除了這個設置，對于Collection和文件沒有強制的模型限定。這有益于快速開發及簡易修改。

當然這不意味著你就可以無視結構模型的設計，一個合適的結構模型可以讓你獲得MongoDB的最佳性能。趕快閱讀MongoDB文檔，或者觀看這些結構模型設計的相關視頻吧!

Schema Design Basics

Schema Design at Scale

Schema Design Principles and Practice

總結：設計結構模型并充分利用MongoDB的特色。

默認情況下修改語句修改的只是單個文件

在傳統的RDBMS中除非使用LIMIT子句，修改語句作用的將是所有匹配的地方。然而MongoDB每個查詢上都默認使用等價“LIMIT 1”的設置。雖然無法做到“LIMIT 5”，但是你可以通過下面的語句整個的移除限制：

db.people.update({age: {$gt: 30}}, {$set: {past_it: true}}, false, true)

同樣在官方的驅動中還有類似的選項 —— ‘multi’。

總結：可以通過指定多個文件的multi為true來完成多文件修改

查詢區分大小寫

字符串的查詢可能不按預期的那樣發展 —— 這歸結于MongoDB默認區分大小寫。

例如：db.people.find({name: ‘Russell’})與db.people.find({name: ‘ russell‘})是不同的。在這里最理想的解決方案就是對需要查詢數據進行確認。你也可以通過正則表達式進行查詢，比如：db.people.find({name:/Russell/i})，但是這樣會影響到性能。

總結：查詢是區分大小寫的，在犧牲速度的情況下可以利用正則表達式。

對輸入的數據無容錯性

當你嘗試向傳統數據庫插入錯誤類型的數據，傳統的數據庫一般會把數據轉換成預定義的類型。然而這在MongoDB中是行不通的，因為MongoDB的文件是沒有預定義數據模型的。這樣的話MongoDB會插入你輸入的任何數據。

總結：使用準確的數據類型。

關于鎖

當資源被代碼的多個部分所共享時，需要確信鎖必須要確保這處資源只能在一個地方被操作。

舊版本的MongoDB (pre 2.0)擁有一個全局的寫入鎖。這就意味貫穿整個服務器中只有一個地方做寫操作。這就可能導致數據庫因為某個地方鎖定超負載而停滯。這個問題在2.0版本中的得到了顯著的改善，并且在當前2.2版本中得到了進一步的加強。MongoDB 2.2使用數據庫級別的鎖在這個問題上邁進了一大步。同樣值得期待的Collection級別的鎖也計劃在下一個版本中推出。

盡管如此，Russell還是認為：大多數受此限制的應用程序于其說是受MongoDB影響，還不如說是程序本身的問題來的更直接。

總結：使用最新的穩定版本才能獲得最高的性能。

關于包

在類Ubuntu和Debian系統上安裝時，許多人都出現過“過時版本”這樣的問題。解決方案很簡單：使用10gen官方庫，那么在Ubuntu和Debian上安裝也會像在Fedora和Centos上安裝一樣流暢。

總結：使用擁有大多數最新版本的官方包。

使用偶數個Replica Set成員

Replica Set是增加冗余及提升MongoDB數據集群性能的有效途徑。數據在所有的節點中被復制，并選出一個作為主節點。假如主節點出故障，那么會在其他的節點中票選一個作為新的主節點。

在同一個Replica Set中使用兩臺機器是很有誘惑的，它比3臺機器來的便宜并且也是RDBMS的標準行事風格。

但是到了MongoDB這里，同一個Replica Set中的成員數量只能是奇數個。假如你使用了偶數個成員，那么當主節點發生故障時那么其它的節點都會變成只讀。發生這種情況是因為剩下待選節點的數目不滿足票選主節點的規定。

如果你想節約成本，同時還希望支持故障轉移和冗余的增強，那么你可以使用Arbiter。Arbiter是一種特殊的Replica Set成員，它不儲存任何用戶數據(這就意味著他們可以使用非常小的服務器)。

總結：只可以使用偶數個Replica Set成員，但是可以使用Arbitter來削減成本。

沒有join語句

MongoDB不支持join：如果你想在多個Collection中檢索數據，那么你必須做多次的查詢。

如果你覺得你手動做的查詢太多了，你可以重設計你的數據模型來減少整體查詢的數量。MongoDB中的文件可以是任何類型，那么可以輕易的對數據進行De-Normalize。這樣就可以讓它始終和你的應用程序保持一致。

總結：沒有join不妨看一下如何設計數據結構模型。

Journaling

MongoDB使用內存映射文件并且每60秒向磁盤輸出一次通知，這就意味著最大程度上你可能丟失60秒加上向硬盤輸出通知這段時間內所有的數據。

為了避免數據丟失，MongoDB從2.0版本起就添加了Journaling(默認情況下開啟)。Journaling把時間從60秒更改為100ms。如果數據庫意外的停機，在啟動之前它將會被重啟用以確保數據庫處于一致狀態。這也是MongoDB與傳統數據庫最接近的地方。

當然Journaling會輕微的影響到性能，大約5%。但是對于多數人來說額外帶來的安全性肯定是物有所值的。

總結：最好別關閉Journaling。

默認情況下沒有身份認證

MongoDB在默認設置下并沒有身份驗證。MongoDB會認為自身處在一個擁有防火墻的信任網絡。但是這不代表它不支持身份驗證，如果需要可以輕松的開啟。

總結：MongoDB的安全性可以通過使用防火墻和綁定正確的接口來保證，當然也可以開啟身份驗證。

Replica Set中損失的數據

使用Replica Set是提高系統可靠性及易維護的有效途徑。這樣的話，弄清節點間故障的發生及轉移機制就變得至關重要。

Replica Set中的成員一般通過oplog(記錄了數據中發生增、刪、改等操作的列表)來傳遞信息，當其中一個成員發生變化修改oplog后，其他的成員也將按照oplog來執行。如果你負責處理新數據的節點在出錯后恢復運行，它將會被回滾至最后一個oplog公共點。然而在這個過程中：丟失的“新數據”已經被MongoDB從數據庫中轉移并存放到你的數據目錄‘rollback’里面等待被手動恢復。如果你不知道這個特性，你可能就會認為數據被弄丟了。所以每當有成員從出錯中恢復過來都必須要檢查這個目錄。而通過MongoDB發布的標準工具來恢復這些數據是件很容易的事情。查看官方文檔以了解更多相關信息。

總結：故障恢復中丟失的數據將會出現在rollback目錄里面。

分片太遲

分片是把數據拆分到多臺機器上，通常被用于Replica Set運行過慢時進行性能提升。MongoDB支持自動分片。然而如果你讓分片進行太遲的話，問題就產生了。因為對數據的拆分和塊的遷移需要時間和資源，所以如果當服務器資源基本上耗盡時很可能會導致在你最需要分片時卻分不了片。

解決的方法很簡單，使用一個工具對MongoDB進行監視。對你的服務器做最準確的評估，并且在占整體性能的80%前進行分片。類似的監視工具有：MMS、Munin(+Mongo Plugin)和CloudWatch。

如果你確定從一開始就要分片處理，那么更好的建議會是選用AWS或者類似的云服務進行分片。而在小型服務器上，關機或者是調整機器明顯比轉移成千上萬條數據塊來的更直接一點。

總結：盡早的分片才能有效的避免問題。

不可以更改文件中的shard key

對于分片設置，shard key是MongoDB用來識別分塊對應文件的憑證。當你插入一個文件后，你就不可以對文件的shard key進行更改。而這里的解決方案是把文檔刪除然后重新建立，這樣就允許把它指定到對應的分塊了。

總結：shard key不可以修改，必要的時候可以刪除文件重新建立。

不可以對256G以上的Collection進行分片

重新回到分片太遲的問題上來 —— MongoDB不允許對增長到256G以上的Collection進行分片，之前版本的設置還沒有256G。這個限定在以后肯定會被移除，而這里也沒有更好的解決方案。只能進行重編譯或者把大小控制在256G以下。

總結：在Collection達到256G以前進行分片。

唯一性索引與共享

索引的唯一性約束只能通過shard key來保證。

選擇了錯誤的shard key

MongDB需要你選擇一個shard key來將數據分片。如果選擇了錯誤的shard key,更改起來將是件很麻煩的事情。

總結：選擇shard key之前先閱讀這個文檔。

與MongoDB通信的未經加密

與MongoDB的連接默認情況下都是非加密的，這就意味你的數據可能被第三方記錄和使用。如果你的MongoDB是在自己的非廣域網下使用，那么這種情況是不可能發生的。

然而如果你是通過公網訪問MongoDB的話，那么你肯定會希望你的通信是經過加密的。公版的MongoDB是不支持SSL的。慶幸的是可以非常簡單的定制自己的版本。10gen的用戶則擁有特別定制的加密版本。幸運的是大部分的官方驅動都支持SSL，但是小麻煩同樣是不可避免的。點擊查看文檔。

總結：當用公網連接時，要注意和MongoDB的通信是未加密的。

事務

不像MySQL這些支持多行數據原子操作的傳統數據庫，MongoDB只支持單文件的原子性修改。解決這個問題的方法之一是在應用程序中使用異步提交的方式;另一個是：建立一個以上的數據存儲。雖然第一種方法并不適用于所有情況，但是很顯然比第二個來的要好。

總結：不支持對多文件事務。

日志預分配慢

MongDB可能會告訴你已經準備就緒，但事實上它還在對日志進行分配。如果你選擇了讓機器自行分配，而恰巧你的文件系統和磁盤速度又很慢，那么煩惱的事情發生了。通常情況下這不會成為問題，但是一旦出現了可以使用undocumented flag –nopreallocj來關閉預分配。

總結：如果機器文件系統和磁盤過慢的話，那么日志的預分配也可能很慢。

NUMA + Linux +MongoDB

Linux、NUMA與MongoDB遇到一起的時候運行總是不會很好。如果你在NUMA硬件上運行MongoDB的話，這里建議是直接關掉。因為各種奇怪的問題隨之而來，比如：速度會階段性或者在CPU占用率很高的時候大幅下降。

總結：禁NUMA。

Linux里面的進程限制

如果你在MongoDB未滿載的時候出過SEGMENTATION FAULT錯誤，你可能會發現這是因為使用了過低或者默認的打開文件或用戶進程限制。10gen建議把限制設置在4K+，然而設置的大小該取決具體情況。閱讀ulimit了解更多。

總結：長久的為MongoDB在Linux加上軟或硬的打開文件或用戶進程限制。