本文轉載自：http://book.2cto.com/201211/7897.html

市面上的數(shù)據(jù)庫數(shù)量成爆炸式增長，要在它們之間進行權衡是很困難的。幸運的是，它們之中的大多數(shù)數(shù)據(jù)庫都能歸在幾個分類里。本節(jié)中，我會描述簡單及復雜的鍵值存儲、關系型數(shù)據(jù)庫和文檔數(shù)據(jù)庫，并將它們與MongoDB做一個比較。下面來看表1-1。

表1-1　數(shù)據(jù)庫家族

?	示　　例	數(shù)據(jù)模型	伸縮性模型	使用場景
簡單鍵值存儲	memcached	鍵值對，其中值是一個二進制大字段	多種模型。memcached能跨多個節(jié)點進行伸縮，把所有可用內存變?yōu)橐粋€巨大的數(shù)據(jù)存儲	緩存、Web操作
復雜鍵值存儲	Cassandra、Project Voldemort、Riak	多種模型。Cassandra使用名為列（column）的鍵值結構。Voldemort存儲二進制大字段	最終一致性，多節(jié)點部署以獲得高可用性和簡單的故障轉移	高吞吐量垂直內容（活動feed、消息隊列）、緩存、Web操作
關系型數(shù)據(jù)庫	Oracle數(shù)據(jù)庫、MySQL、 PostgreSQL	數(shù)據(jù)表	垂直伸縮。對集群和手動分區(qū)支持有限	要求事務（銀行、金融）或SQL的系統(tǒng)、正規(guī)化數(shù)據(jù)模型

1. 簡單鍵值存儲

簡單鍵值存儲正如其名，基于給定的鍵對值做索引。常見的場景是緩存。舉例來說，假設需要緩存一個由應用程序呈現(xiàn)的HTML頁面，此處的鍵可能是頁面的URL，值是HTML本身。請注意，對鍵值存儲而言，值就是一個不透明的字節(jié)數(shù)組。沒有強加關系型數(shù)據(jù)庫中的Schema，也沒有任何數(shù)據(jù)類型的概念。這自然限制了鍵值存儲允許的操作：可以放入一個新值，然后通過鍵將其找出或刪除。擁有如此簡單性的系統(tǒng)通常很快，而且具有可伸縮性。

最著名的簡單鍵值存儲是memcached（發(fā)音是mem-cash-dee）。memcached僅在內存里存儲數(shù)據(jù)，用持久性來換取速度。它也是分布式的，跨多臺服務器的memcached節(jié)點能像單個數(shù)據(jù)存儲那樣來使用，這消除了維護跨服務器緩存狀態(tài)的復雜性。

與MongoDB相比，memcached這樣的簡單鍵值存儲通常讀寫會更快。但與MongoDB不同，這些系統(tǒng)很少能充當主要數(shù)據(jù)存儲。簡單鍵值存儲的最佳用途是附加存儲，既可以作為傳統(tǒng)數(shù)據(jù)庫之上的緩存層，也可以作為任務隊列之類的短暫服務的簡單持久層。

2. 復雜鍵值存儲

可以改進簡單鍵值模型來處理復雜的讀寫Schema或提供更豐富的數(shù)據(jù)模型。如此一來，就有了復雜鍵值存儲。廣為流傳的論文“Dynamo: Amazon’s Highly Available Key-value Store”中描述的亞馬遜 Dynamo就是這樣一個例子。Dynamo旨在成為一個健壯的數(shù)據(jù)庫，在網(wǎng)絡故障、數(shù)據(jù)中心停轉及類似情況下仍能工作。這要求系統(tǒng)總是能夠被讀和寫，本質上就是要求數(shù)據(jù)能自動跨多個節(jié)點進行復制。如果一個節(jié)點發(fā)生故障，系統(tǒng)的用戶（在這里可能是一個使用亞馬遜購物車的顧客）不會察覺到服務中斷。當系統(tǒng)允許同一份數(shù)據(jù)被寫到多個節(jié)點時，發(fā)生沖突的情況是不可避免的，Dynamo提供了一些解決沖突的方法。與此同時，Dynamo也很容易伸縮。因為沒有主節(jié)點，所有節(jié)點都是對等的，所以很容易從整體上理解系統(tǒng)，能方便地添加節(jié)點。盡管Dynamo是一個私有系統(tǒng)，但其構建理念啟發(fā)了很多NoSQL系統(tǒng)，包括Cassandra、Project Voldemort和Riak。

看看是誰開發(fā)了這些復雜鍵值存儲，看看實踐中它們的使用情況如何，你就能知道它們的優(yōu)點了。以Cassandra為例，它實現(xiàn)了很多Dynamo的伸縮屬性，同時還提供了與谷歌 BigTable類似的面向列的數(shù)據(jù)模型。Cassandra是一款開源的數(shù)據(jù)存儲，是Facebook為其收件箱搜索功能開發(fā)的。該系統(tǒng)可以水平擴展，索引超過50 TB的收件箱數(shù)據(jù)，允許在收件箱中對關鍵字和收件人做檢索。數(shù)據(jù)是根據(jù)用戶ID做索引的，每條記錄由一個用于關鍵字檢索的搜索項數(shù)組和一個用于收件人檢索的收件人ID數(shù)組構成。¹

這些復雜鍵值存儲是由亞馬遜、谷歌和Facebook這樣的大型互聯(lián)網(wǎng)公司開發(fā)的，用來管理系統(tǒng)的多個部分，擁有非常大的數(shù)據(jù)量。換言之，復雜鍵值存儲管理了一個相對自包含的域，它對海量存儲和可用性有一定要求。由于采用了無主節(jié)點的架構，這些系統(tǒng)能輕松地通過添加節(jié)點進行擴展。它們都選擇了最終一致性，也就是說讀請求不必返回最后一次寫的內容。用戶用較弱的一致性所換得的是在某一節(jié)點失效時仍能寫入的能力。

這與MongoDB正好相反，MongoDB提供了強一致性、（每個分片）一個主節(jié)點、更豐富的數(shù)據(jù)模型，還有二級索引，最后兩項特性總是一起出現(xiàn)的。如果一個系統(tǒng)允許跨多個域建模，例如構建完整Web應用程序時就會有此要求，那么查詢就需要跨整個數(shù)據(jù)模型，這時就要用到二級索引了。

因為有豐富的數(shù)據(jù)模型，可以考慮把MongoDB作為更通用的大型、可伸縮Web應用程序的解決方案。MongoDB的伸縮架構有時也會受到非難，因為它并非源自Dynamo。但MongoDB針對不同域有不同的伸縮解決方案。MongoDB的自動分片受到了雅虎PNUTS數(shù)據(jù)存儲和谷歌 BigTable的啟發(fā)。讀過發(fā)布這些數(shù)據(jù)存儲的白皮書的人會發(fā)現(xiàn)，MongoDB實現(xiàn)伸縮的方法已經(jīng)被實現(xiàn)了，而且還很成功。

3. 關系型數(shù)據(jù)庫

本章已經(jīng)介紹了不少關系型數(shù)據(jù)庫的內容，簡單起見，我只討論RDBMS與MongoDB的相同點和不同點。盡管MySQL²使用固定Schema的數(shù)據(jù)表，MongoDB使用無Schema的文檔，但兩者都能表示豐富的數(shù)據(jù)模型。MySQL和MongoDB都支持B樹索引，那些適用于MySQL索引的經(jīng)驗也同樣適用于MongoDB。MySQL支持聯(lián)結和事務，因此如果你必須使用SQL或者要求有事務，那么只能選擇MySQL或其他RDBMS。也就是說，MongoDB的文檔模型足以在不用聯(lián)結查詢的情況下表示對象。MongoDB中對單獨文檔的更新也是原子的，這提供了傳統(tǒng)事務的一個子集。MongoDB和MySQL都支持復制。就可伸縮性而言，MongoDB設計成能水平擴展，能自動分片并處理故障轉移。MySQL上的分片都需要手動管理，有一定的復雜性，更常見的是垂直擴展的MySQL系統(tǒng)。

4. 文檔數(shù)據(jù)庫

自稱為文檔數(shù)據(jù)庫的產(chǎn)品還不多，在本書編寫時，除了MongoDB之外，唯一的著名文檔型數(shù)據(jù)庫就是Apache CouchDB。盡管CouchDB的數(shù)據(jù)是使用JSON格式的純文本存儲的，而MongoDB是使用BSON二進制格式，但兩者的文檔模型是相似的。與MongoDB一樣，CouchDB也支持二級索引，不同之處是CouchDB中的索引是通過編寫MapReduce函數(shù)來定義的，這比MySQL和MongoDB使用的聲明式語法更復雜一些。兩者伸縮的方式也有所不同，CouchDB不會把數(shù)據(jù)分散到多臺服務器上，每個CouchDB節(jié)點都是其他節(jié)點的完整副本。
________________________________
1 參見http://mng.bz/5321。
2 這里我用MySQL來做說明，因為我所描述的特性適用于大多數(shù)關系型數(shù)據(jù)庫。

[以下補充內容來自：http://book.2cto.com/201211/7896.html?為什么選擇MongoDB]

MongoDB項目的總體設計目標。根據(jù)其作者的觀點，MongoDB的設計是要結合鍵值存儲和關系型數(shù)據(jù)庫的最好特性。鍵值存儲，因為非常簡單，所以速度極快而且相對容易伸縮。關系型數(shù)據(jù)庫較難伸縮，至少很難水平伸縮，但擁有富數(shù)據(jù)模型和強大的查詢語言。如果MongoDB能介于兩者之間，就能成為一款易伸縮、能存儲豐富數(shù)據(jù)結構、提供復雜查詢機制的數(shù)據(jù)庫。

在使用場景方面，MongoDB非常適合用做以下應用程序的主要數(shù)據(jù)存儲：Web應用程序、分析與記錄應用程序，以及任何要求有中等級別緩存的應用程序。此外，由于它能方便地存儲無Schema數(shù)據(jù)，MongoDB還很適合保存事先無法知曉其數(shù)據(jù)結構的數(shù)據(jù)。

轉載于:https://blog.51cto.com/idata/1082559

總結

以上是生活随笔為你收集整理的MongoDB与其他数据库的对比的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內容還不錯，歡迎將生活随笔推薦給好友。