MongoDB 應用二三事

最近，隨著“大資料時代”的到來，NoSQL資料庫作為資料庫行業的後起之秀，在短短的幾年之間，得到了迅猛的發展，而如今還大有取代RDBMS之勢。在眾多的NoSQL資料庫中，名氣最大的莫過於MongoDB了。MongoDB於2009年2月推出第一個版本，至今的5年多時間，其已經發展成為在DB Engine影響力排行世界第5位的資料庫。

MongoDB具有以下幾個特點：

1）  非結構化的資料結構，保證了適應多種多樣的資料類型和形式，無需預先設計資料結構和表模式。

2）  水平擴張，理論上是可以無限擴充的水平擴充性。

3）  多樣的功能和平台架構支援，經過其Team Dev的自身推進以及Mongo開源社區的蓬勃發展，使得MongoDB支援越來越多的開發語言和大資料架構，同時也不斷豐富了他的功能。

 

而本人作為一個大資料相關的從業人員，在工作中不斷地學習MongoDB的知識，我自己也將其運用到了一些實際應用情境當中。

 

在使用MongoDB的過程中，其效能表現雖然中規中矩，也很好的體現了NoSQL的基本特性，但是實際應用情境之中，MongoDB仍然有不少功能上的不足以及效能上可改進之處。

1.      效能

首先我想談談MongoDB的效能表現。作為NoSQL資料庫，MongoDB的讀寫查等許多操作的效能方面自然是領先於RDBMS的，然而在與其他的NoSQL產品比較時，MongoDB其實並沒有太大的優勢。

根據網上之前公布的一些權威機構的測試結果，MongoDB的效能在眾多NoSQL資料庫中只能說是一般般。讀寫效能方面，相比於HBase，MongoDB在少分區下還能基本持平，但是在多分區的情情景下效能表現也只有HBase的1/3甚至1/5。而與這方面的佼佼者Cassandra相比，Mongo在各項對比中，也只能達到Cassandra的1/10甚至更少。

http://planetcassandra.org/nosql-performance-benchmarks

 

而與儲存方式同類的Couchbase相比，MongoDB似乎也不佔優勢。

http://www.csdn.net/article/2013-04-15/2814886-nosql-benchmark

http://www.couchbase.com/press-releases/couchbase-blows-past-competition-nosql-performance-benchmark

從以上兩個測試報告也可以看出，作為NoSQL領軍人物的MongoDB，在效能表現上確實差強人意。

 

2.      功能

2.1  事務

事務作為RDBMS一個非常實用的特性，在處理高可用性高安全性的情景，如企業級的應用時，事務有它獨到的優點。

MongoDB並沒有交易處理的功能，而在原子性的保證方面，其只能做到單個文檔層級，不能支援多檔案的原子性。

如今，MongoDB在開源之後應用程式層也有民間開發的整合了事務功能的組件，但是應用程式層的實現在資料庫的通訊上面不能保證效能和可靠性，也就很難提供更專業和完善的支援。

 

2.2  SQL支援

SQL作為已經使用了幾十年的資料庫操作語言，不僅在應用上，有著完善多樣的介面和驅動，同時，SQL的思維在眾多資料庫使用者和DBA的腦中已經根深蒂固，想要迅速的改變這種思維方式是困難也沒有必要的。所以，NoSQL對於SQL語句的支援也很重要。MongoDB並不具備這樣的原生支援，同樣，應用程式層的一些驅動並不能很好的結合資料庫本身，完全發揮它的能量。

相反，有許多的同類產品已經提供內建的SQL語句處理，例如通過對接PostgreSQL來實現SQL語句支援，這樣能讓開發人員更快的熟悉和轉入NoSQL。

 

2.3  鎖

MongoDB 只有庫級粒度的鎖，這意味著當 MongoDB 一個寫鎖處於佔用狀態時，其它的讀寫操作都需要等待。雖然因為改動過的鎖處理機制讓其能保證較高的並發量和高效能（感興趣可以另外介紹）。

可是基本保證並能完全避免問題，如果資料操作不當，依然會導致長時間佔用寫鎖，比如前台建立索引操作，當出現這種情況的時候，整個資料庫就處於完全阻塞狀態，無法進行任何讀寫操作，情況十分嚴重。

2.4  自動分區

體現MongoDB水平擴充能力的重要一個功能就是自動分區（auto-sharding），然而MongoDB的自動分區在實際應用當中也存在著不少問題。1）在高負載的情況下，MongoDB的自動資料分割函數會出現不可用或者運行緩慢的情況。2）可以看到網上有不少使用者在系統自動分區後出現資料錯誤或者資料丟失的情況（最出名的當然是Foursquare的宕機事件）。3）我自己在實際應用中也出現過類似問題，也就是MongoDB在高負載下，出現了資料的丟失，並且還沒辦法恢複。

 

2.5  Join

MongoDB不支援Join操作，需要在多個Collection中尋找時，不能使用Join將多個Collection合并，只能分別在每個Collection中運行一次儲存操作。

 

3.      安全性

MongoDB的原生資料庫系統安全性雖然也是它極力展示的一個特性之一，但是事實上

MongoDB的安全性設計仍有缺陷。首先，MongoDB的預設安全設定為否，這給了很多不熟悉MongoDB特點的新人或是第一次轉換NoSQL的企業使用者一個非常大的安全隱患。此外，MongoDB也在網上被報道一些安全性漏洞或者駭客攻擊事件，包括非法資料擷取、資料的無故丟失等這些事件究其原因也是安全保障設計的缺陷。

 

4.      易用性

易用上來說，MongoDB的表現也是中規中矩，雖然可以使用Javascript的Shell工具以及介面化的MMS，但是其操作仍有最佳化的空間。此外，MongoDB不具備自動安裝部署功能。MongoDB的安裝部署必須全手動操作，這樣不僅比較耗時，對於新手來說可能因為不熟悉而忽略或不能完成一些系統配置的工作，導致安裝失敗或是使用過程中出現異常。

以上是我個人在實踐中發現的MongoDB的幾點不足，我認為，MongoDB雖然是作為NoSQL的領軍人物在與關係型資料庫華山論劍，但是其實他並不完善，所以我希望未來MongoDB自身能做出改進，當然我更希望能有新的資料庫產品能後來居上，這樣才能加快NoSQL資料庫的更快進步。