mongo，redis等NoSQL資料庫效能比較
阿新 • • 發佈：2019-01-12
隨著網際網路web2.0網站的興起，非關係型的資料庫現在成了一個極其熱門的新領域，非關係資料庫產品的發展非常迅速。而傳統的關係資料庫在應付 web2.0網站，特別是超大規模和高併發的SNS型別的web2.0純動態網站已經顯得力不從心，暴露了很多難以克服的問題，例如：
1、High performance - 對資料庫高併發讀寫的需求
web2.0網站要根據使用者個性化資訊來實時生成動態頁面和提供動態資訊，所以基本上無法使用動態頁面靜態化技術，因此資料庫併發負載非常高，往往要達到 每秒上萬次讀寫請求。關係資料庫應付上萬次SQL查詢還勉強頂得住，但是應付上萬次SQL寫資料請求，硬碟IO就已經無法承受了。其實對於普通的BBS網 站，往往也存在對高併發寫請求的需求，例如像JavaEye網站的實時統計線上使用者狀態，記錄熱門帖子的點選次數，投票計數等，因此這是一個相當普遍的需求。
2、Huge Storage - 對海量資料的高效率儲存和訪問的需求
類似Facebook，twitter，Friendfeed 這樣的SNS網站，每天使用者產生海量的使用者動態，以Friendfeed為例，一個月就達到了2.5億條使用者動態，對於關係資料庫來說，在一張2.5億條 記錄的表裡面進行SQL查詢，效率是極其低下乃至不可忍受的。再例如大型web網站的使用者登入系統，例如騰訊，盛大，動輒數以億計的帳號，關係資料庫也很 難應付。
3、High Scalability && High Availability- 對資料庫的高可擴充套件性和高可用性的需求
在基於web的架構當中，資料庫是最難進行橫向擴充套件的，當一個應用系統的使用者量和訪問量與日俱增的時候，你的資料庫卻沒有辦法像web server和app server那樣簡單的通過新增更多的硬體和服務節點來擴充套件效能和負載能力。對於很多需要提供24小時不間斷服務的網站來說，對資料庫系統進行升級和擴充套件 是非常痛苦的事情，往往需要停機維護和資料遷移，為什麼資料庫不能通過不斷的新增伺服器節點來實現擴充套件呢？
在上面提到的“三高”需求面前，關係資料庫遇到了難以克服的障礙，而對於web2.0網站來說，關係資料庫的很多主要特性卻往往無用武之地，例如：
1、資料庫事務一致性需求
很多web實時系統並不要求嚴格的資料庫事務，對讀一致性的要求很低，有些場合對寫一致性要求也不高。因此資料庫事務管理成了資料庫高負載下一個沉重的負擔。
2、資料庫的寫實時性和讀實時性需求
對關係資料庫來說，插入一條資料之後立刻查詢，是肯定可以讀出來這條資料的，但是對於很多web應用來說，並不要求這麼高的實時性，比方說我（JavaEye的robbin）發一條訊息之後，過幾秒乃至十幾秒之後，我的訂閱者才看到這條動態是完全可以接受的。
3、對複雜的SQL查詢，特別是多表關聯查詢的需求
任何大資料量的web系統，都非常忌諱多個大表的關聯查詢，以及複雜的資料分析型別的複雜SQL報表查詢，特別是SNS型別的網站，從需求以及產品設計角度，就避免了這種情況的產生。往往更多的只是單表的主鍵查詢，以及單表的簡單條件分頁查詢，SQL的功能被極大的弱化了。
因此，關係資料庫在這些越來越多的應用場景下顯得不那麼合適了，為了解決這類問題的非關係資料庫應運而生，現在這兩年，各種各樣非關係資料庫，特別是鍵值 資料庫(Key-Value Store DB)風起雲湧，多得讓人眼花繚亂。前不久國外剛剛舉辦了NoSQL Conference，各路NoSQL資料庫紛紛亮相，加上未亮相但是名聲在外的，起碼有超過10個開源的NoSQLDB，例如：
Redis，Tokyo Cabinet，Cassandra，Voldemort，MongoDB，Dynomite，HBase，CouchDB，Hypertable， Riak，Tin， Flare， Lightcloud， KiokuDB，Scalaris， Kai， ThruDB， ......
這些NoSQL資料庫，有的是用C/C++編寫的，有的是用Java編寫的，還有的是用Erlang編寫的，每個都有自己的獨到之處，看都看不過來了，我 (robbin)也只能從中挑選一些比較有特色，看起來更有前景的產品學習和了解一下。這些NoSQL資料庫大致可以分為以下的三類：
一、滿足極高讀寫效能需求的Kye-Value資料庫：Redis，Tokyo Cabinet， Flare
高效能Key-Value資料庫的主要特點就是具有極高的併發讀寫效能，Redis，Tokyo Cabinet， Flare，這3個Key-Value DB都是用C編寫的，他們的效能都相當出色，但出了出色的效能，他們還有自己獨特的功能：
1、Redis
Redis是一個很新的專案，剛剛釋出了1.0版本。Redis本質上是一個Key-Value型別的記憶體資料庫，很像memcached，整個資料庫統統載入在記憶體當中進行操作，定期通過非同步操作把資料庫資料flush到硬碟上進行儲存。因為是純記憶體操作，Redis的效能非常出色，每秒可以處理超過10萬次讀寫操作，是我知道的效能最快的Key-Value DB。
Redis的出色之處不僅僅是效能，Redis最大的魅力是支援儲存List連結串列和Set集合的資料結構，而且還支援對List進行各種操作，例如從 List兩端push和pop資料，取List區間，排序等等，對Set支援各種集合的並集交集操作，此外單個value的最大限制是1GB，不像 memcached只能儲存1MB的資料，因此Redis可以用來實現很多有用的功能，比方說用他的List來做FIFO雙向連結串列，實現一個輕量級的高性 能訊息佇列服務，用他的Set可以做高效能的tag系統等等。另外Redis也可以對存入的Key-Value設定expire時間，因此也可以被當作一個功能加強版的memcached來用。
Redis的主要缺點是資料庫容量受到實體記憶體的限制，不能用作海量資料的高效能讀寫，並且它沒有原生的可擴充套件機制，不具有scale（可擴充套件）能力，要依賴客戶端來實現分散式讀寫，因此Redis適合的場景主要侷限在較小資料量的高效能操作和運算上。目前使用Redis的網站有github，Engine Yard。
2、Tokyo Cabinet和Tokoy Tyrant
TC和TT的開發者是日本人Mikio Hirabayashi，主要被用在日本最大的SNS網站mixi.jp上，TC發展的時間最早，現在已經是一個非常成熟的專案，也是Kye-Value 資料庫領域最大的熱點，現在被廣泛的應用在很多很多網站上。TC是一個高效能的儲存引擎，而TT提供了多執行緒高併發伺服器，效能也非常出色，每秒可以處理 4-5萬次讀寫操作。
TC除了支援Key-Value儲存之外，還支援儲存Hashtable資料型別，因此很像一個簡單的資料庫表，並且還支援基於column的條件查詢， 分頁查詢和排序功能，基本上相當於支援單表的基礎查詢功能了，所以可以簡單的替代關係資料庫的很多操作，這也是TC受到大家歡迎的主要原因之一，有一個 Ruby的專案miyazakiresistance將TT的hashtable的操作封裝成和ActiveRecord一樣的操作，用起來非常爽。
TC/TT在mixi的實際應用當中，儲存了2000萬條以上的資料，同時支撐了上萬個併發連線，是一個久經考驗的專案。TC在保證了極高的併發讀寫效能 的同時，具有可靠的資料持久化機制，同時還支援類似關係資料庫表結構的hashtable以及簡單的條件，分頁和排序操作，是一個很棒的NoSQL資料 庫。
TC的主要缺點是在資料量達到上億級別以後，併發寫資料效能會大幅度下降，NoSQL: If Only It Was That Easy提到，他們發現在TC裡面插入1.6億條2-20KB資料的時候，寫入效能開始急劇下降。看來是當資料量上億條的時候，TC效能開始大幅度下降， 從TC作者自己提供的mixi資料來看，至少上千萬條資料量的時候還沒有遇到這麼明顯的寫入效能瓶頸。
這個是Tim Yang做的一個Memcached，Redis和Tokyo Tyrant的簡單的效能評測，僅供參考
3、Flare
TC是日本第一大SNS網站mixi開發的，而Flare是日本第二大SNS網站green.jp開發的，有意思吧。Flare簡單的說就是給TC添加了 scale功能。他替換掉了TT部分，自己另外給TC寫了網路伺服器，Flare的主要特點就是支援scale能力，他在網路服務端之前添加了一個 node server，來管理後端的多個伺服器節點，因此可以動態新增資料庫服務節點，刪除伺服器節點，也支援failover。如果你的使用場景必須要讓TC可 以scale，那麼可以考慮flare。
flare唯一的缺點就是他只支援memcached協議，因此當你使用flare的時候，就不能使用TC的table資料結構了，只能使用TC的key-value資料結構儲存。
二、滿足海量儲存需求和訪問的面向文件的資料庫：MongoDB，CouchDB
面向文件的非關係資料庫主要解決的問題不是高效能的併發讀寫，而是保證海量資料儲存的同時，具有良好的查詢效能。MongoDB是用C++開發的，而CouchDB則是Erlang開發的：
1、MongoDB
MongoDB是一個介於關係資料庫和非關係資料庫之間的產品，是非關係資料庫當中功能最豐富，最像關係資料庫的。他支援的資料結構非常鬆散，是類似 json的bjson格式，因此可以儲存比較複雜的資料型別。Mongo最大的特點是他支援的查詢語言非常強大，其語法有點類似於面向物件的查詢語言，幾乎可以實現類似關係資料庫單表查詢的絕大部分功能，而且還支援對資料建立索引。
Mongo主要解決的是海量資料的訪問效率問題，根據官方的文件，當資料量達到50GB以上的時候，Mongo的資料庫訪問速度是MySQL的10倍以 上。Mongo的併發讀寫效率不是特別出色，根據官方提供的效能測試表明，大約每秒可以處理0.5萬－1.5次讀寫請求。對於Mongo的併發讀寫效能， 我（robbin）也打算有空的時候好好測試一下。
因為Mongo主要是支援海量資料儲存的，所以Mongo還自帶了一個出色的分散式檔案系統GridFS，可以支援海量的資料儲存，但我也看到有些評論認為GridFS效能不佳，這一點還是有待親自做點測試來驗證了。
最後由於Mongo可以支援複雜的資料結構，而且帶有強大的資料查詢功能，因此非常受到歡迎，很多專案都考慮用MongoDB來替代MySQL來實現不是 特別複雜的Web應用，比方說why we migrated from MySQL to MongoDB就是一個真實的從MySQL遷移到MongoDB的案例，由於資料量實在太大，所以遷移到了Mongo上面，資料查詢的速度得到了非常顯著 的提升。
MongoDB也有一個ruby的專案MongoMapper，是模仿Merb的DataMapper編寫的MongoDB的介面，使用起來非常簡單，幾乎和DataMapper一模一樣，功能非常強大易用。
2、CouchDB
CouchDB現在是一個非常有名氣的專案，似乎不用多介紹了。但是我卻對CouchDB沒有什麼興趣，主要是因為CouchDB僅僅提供了基於HTTP REST的介面，因此CouchDB單純從併發讀寫效能來說，是非常糟糕的，這讓我立刻拋棄了對CouchDB的興趣。
三、滿足高可擴充套件性和可用性的面向分散式計算的資料庫：Cassandra，Voldemort
面向scale能力的資料庫其實主要解決的問題領域和上述兩類資料庫還不太一樣，它首先必須是一個分散式的資料庫系統，由分佈在不同節點上面的資料庫共同 構成一個數據庫服務系統，並且根據這種分散式架構來提供online的，具有彈性的可擴充套件能力，例如可以不停機的新增更多資料節點，刪除資料節點等等。因 此像Cassandra常常被看成是一個開源版本的Google BigTable的替代品。Cassandra和Voldemort都是用Java開發的：
1、Cassandra
Cassandra專案是Facebook在2008年開源出來的，隨後Facebook自己使用Cassandra的另外一個不開源的分支，而開源出來 的Cassandra主要被Amazon的Dynamite團隊來維護，並且Cassandra被認為是Dynamite2.0版本。目前除了 Facebook之外，twitter和digg.com都在使用Cassandra。
Cassandra的主要特點就是它不是一個數據庫，而是由一堆資料庫節點共同構成的一個分散式網路服務，對Cassandra的一個寫操作，會被複制到 其他節點上去，對Cassandra的讀操作，也會被路由到某個節點上面去讀取。對於一個Cassandra群集來說，擴充套件效能是比較簡單的事情，只管在 群集裡面新增節點就可以了。我看到有文章說Facebook的Cassandra群集有超過100臺伺服器構成的資料庫群集。
Cassandra也支援比較豐富的資料結構和功能強大的查詢語言，和MongoDB比較類似，查詢功能比MongoDB稍弱一些，twitter的平臺架構部門領導Evan Weaver寫了一篇文章介紹Cassandra：http://blog.evanweaver.com/artic ... ing-with-cassandra/，有非常詳細的介紹。
Cassandra以單個節點來衡量，其節點的併發讀寫效能不是特別好，有文章說評測下來Cassandra每秒大約不到1萬次讀寫請求，我也看到一些對 這個問題進行質疑的評論，但是評價Cassandra單個節點的效能是沒有意義的，真實的分散式資料庫訪問系統必然是n多個節點構成的系統，其併發效能取 決於整個系統的節點數量，路由效率，而不僅僅是單節點的併發負載能力。
2、Voldemort
Voldemort是個和Cassandra類似的面向解決scale問題的分散式資料庫系統，Cassandra來自於Facebook這個SNS網 站，而Voldemort則來自於Linkedin這個SNS網站。說起來SNS網站為我們貢獻了n多的NoSQL資料庫，例如 Cassandar，Voldemort，Tokyo Cabinet，Flare等等。Voldemort的資料不是很多，因此我沒有特別仔細去鑽研，Voldemort官方給出Voldemort的併發讀 寫效能也很不錯，每秒超過了1.5萬次讀寫。
從Facebook開發Cassandra，Linkedin開發Voldemort，我們也可以大致看出國外大型SNS網站對於分散式資料庫，特別是對資料庫的scale能力方面的需求是多麼殷切。前面我（robbin）提到，web應用的架構當中，web層和app層相對來說都很容易橫向擴充套件，唯有資料庫是單點的，極難scale，現在Facebook和Linkedin在非關係型資料庫的分散式方面探索了一條很好的方向，這也是為什麼現在Cassandra這麼熱門的主要原因。
1、High performance - 對資料庫高併發讀寫的需求
web2.0網站要根據使用者個性化資訊來實時生成動態頁面和提供動態資訊，所以基本上無法使用動態頁面靜態化技術，因此資料庫併發負載非常高，往往要達到 每秒上萬次讀寫請求。關係資料庫應付上萬次SQL查詢還勉強頂得住，但是應付上萬次SQL寫資料請求，硬碟IO就已經無法承受了。其實對於普通的BBS網 站，往往也存在對高併發寫請求的需求，例如像JavaEye網站的實時統計線上使用者狀態，記錄熱門帖子的點選次數，投票計數等，因此這是一個相當普遍的需求。
2、Huge Storage - 對海量資料的高效率儲存和訪問的需求
類似Facebook，twitter，Friendfeed 這樣的SNS網站，每天使用者產生海量的使用者動態，以Friendfeed為例，一個月就達到了2.5億條使用者動態，對於關係資料庫來說，在一張2.5億條 記錄的表裡面進行SQL查詢，效率是極其低下乃至不可忍受的。再例如大型web網站的使用者登入系統，例如騰訊，盛大，動輒數以億計的帳號，關係資料庫也很 難應付。
3、High Scalability && High Availability- 對資料庫的高可擴充套件性和高可用性的需求
在基於web的架構當中，資料庫是最難進行橫向擴充套件的，當一個應用系統的使用者量和訪問量與日俱增的時候，你的資料庫卻沒有辦法像web server和app server那樣簡單的通過新增更多的硬體和服務節點來擴充套件效能和負載能力。對於很多需要提供24小時不間斷服務的網站來說，對資料庫系統進行升級和擴充套件 是非常痛苦的事情，往往需要停機維護和資料遷移，為什麼資料庫不能通過不斷的新增伺服器節點來實現擴充套件呢？
在上面提到的“三高”需求面前，關係資料庫遇到了難以克服的障礙，而對於web2.0網站來說，關係資料庫的很多主要特性卻往往無用武之地，例如：
1、資料庫事務一致性需求
很多web實時系統並不要求嚴格的資料庫事務，對讀一致性的要求很低，有些場合對寫一致性要求也不高。因此資料庫事務管理成了資料庫高負載下一個沉重的負擔。
2、資料庫的寫實時性和讀實時性需求
對關係資料庫來說，插入一條資料之後立刻查詢，是肯定可以讀出來這條資料的，但是對於很多web應用來說，並不要求這麼高的實時性，比方說我（JavaEye的robbin）發一條訊息之後，過幾秒乃至十幾秒之後，我的訂閱者才看到這條動態是完全可以接受的。
3、對複雜的SQL查詢，特別是多表關聯查詢的需求
任何大資料量的web系統，都非常忌諱多個大表的關聯查詢，以及複雜的資料分析型別的複雜SQL報表查詢，特別是SNS型別的網站，從需求以及產品設計角度，就避免了這種情況的產生。往往更多的只是單表的主鍵查詢，以及單表的簡單條件分頁查詢，SQL的功能被極大的弱化了。
因此，關係資料庫在這些越來越多的應用場景下顯得不那麼合適了，為了解決這類問題的非關係資料庫應運而生，現在這兩年，各種各樣非關係資料庫，特別是鍵值 資料庫(Key-Value Store DB)風起雲湧，多得讓人眼花繚亂。前不久國外剛剛舉辦了NoSQL Conference，各路NoSQL資料庫紛紛亮相，加上未亮相但是名聲在外的，起碼有超過10個開源的NoSQLDB，例如：
Redis，Tokyo Cabinet，Cassandra，Voldemort，MongoDB，Dynomite，HBase，CouchDB，Hypertable， Riak，Tin， Flare， Lightcloud， KiokuDB，Scalaris， Kai， ThruDB， ......
這些NoSQL資料庫，有的是用C/C++編寫的，有的是用Java編寫的，還有的是用Erlang編寫的，每個都有自己的獨到之處，看都看不過來了，我 (robbin)也只能從中挑選一些比較有特色，看起來更有前景的產品學習和了解一下。這些NoSQL資料庫大致可以分為以下的三類：
一、滿足極高讀寫效能需求的Kye-Value資料庫：Redis，Tokyo Cabinet， Flare
高效能Key-Value資料庫的主要特點就是具有極高的併發讀寫效能，Redis，Tokyo Cabinet， Flare，這3個Key-Value DB都是用C編寫的，他們的效能都相當出色，但出了出色的效能，他們還有自己獨特的功能：
1、Redis
Redis是一個很新的專案，剛剛釋出了1.0版本。Redis本質上是一個Key-Value型別的記憶體資料庫，很像memcached，整個資料庫統統載入在記憶體當中進行操作，定期通過非同步操作把資料庫資料flush到硬碟上進行儲存。因為是純記憶體操作，Redis的效能非常出色，每秒可以處理超過10萬次讀寫操作，是我知道的效能最快的Key-Value DB。
Redis的出色之處不僅僅是效能，Redis最大的魅力是支援儲存List連結串列和Set集合的資料結構，而且還支援對List進行各種操作，例如從 List兩端push和pop資料，取List區間，排序等等，對Set支援各種集合的並集交集操作，此外單個value的最大限制是1GB，不像 memcached只能儲存1MB的資料，因此Redis可以用來實現很多有用的功能，比方說用他的List來做FIFO雙向連結串列，實現一個輕量級的高性 能訊息佇列服務，用他的Set可以做高效能的tag系統等等。另外Redis也可以對存入的Key-Value設定expire時間，因此也可以被當作一個功能加強版的memcached來用。
Redis的主要缺點是資料庫容量受到實體記憶體的限制，不能用作海量資料的高效能讀寫，並且它沒有原生的可擴充套件機制，不具有scale（可擴充套件）能力，要依賴客戶端來實現分散式讀寫，因此Redis適合的場景主要侷限在較小資料量的高效能操作和運算上。目前使用Redis的網站有github，Engine Yard。
2、Tokyo Cabinet和Tokoy Tyrant
TC和TT的開發者是日本人Mikio Hirabayashi，主要被用在日本最大的SNS網站mixi.jp上，TC發展的時間最早，現在已經是一個非常成熟的專案，也是Kye-Value 資料庫領域最大的熱點，現在被廣泛的應用在很多很多網站上。TC是一個高效能的儲存引擎，而TT提供了多執行緒高併發伺服器，效能也非常出色，每秒可以處理 4-5萬次讀寫操作。
TC除了支援Key-Value儲存之外，還支援儲存Hashtable資料型別，因此很像一個簡單的資料庫表，並且還支援基於column的條件查詢， 分頁查詢和排序功能，基本上相當於支援單表的基礎查詢功能了，所以可以簡單的替代關係資料庫的很多操作，這也是TC受到大家歡迎的主要原因之一，有一個 Ruby的專案miyazakiresistance將TT的hashtable的操作封裝成和ActiveRecord一樣的操作，用起來非常爽。
TC/TT在mixi的實際應用當中，儲存了2000萬條以上的資料，同時支撐了上萬個併發連線，是一個久經考驗的專案。TC在保證了極高的併發讀寫效能 的同時，具有可靠的資料持久化機制，同時還支援類似關係資料庫表結構的hashtable以及簡單的條件，分頁和排序操作，是一個很棒的NoSQL資料 庫。
TC的主要缺點是在資料量達到上億級別以後，併發寫資料效能會大幅度下降，NoSQL: If Only It Was That Easy提到，他們發現在TC裡面插入1.6億條2-20KB資料的時候，寫入效能開始急劇下降。看來是當資料量上億條的時候，TC效能開始大幅度下降， 從TC作者自己提供的mixi資料來看，至少上千萬條資料量的時候還沒有遇到這麼明顯的寫入效能瓶頸。
這個是Tim Yang做的一個Memcached，Redis和Tokyo Tyrant的簡單的效能評測，僅供參考
3、Flare
TC是日本第一大SNS網站mixi開發的，而Flare是日本第二大SNS網站green.jp開發的，有意思吧。Flare簡單的說就是給TC添加了 scale功能。他替換掉了TT部分，自己另外給TC寫了網路伺服器，Flare的主要特點就是支援scale能力，他在網路服務端之前添加了一個 node server，來管理後端的多個伺服器節點，因此可以動態新增資料庫服務節點，刪除伺服器節點，也支援failover。如果你的使用場景必須要讓TC可 以scale，那麼可以考慮flare。
flare唯一的缺點就是他只支援memcached協議，因此當你使用flare的時候，就不能使用TC的table資料結構了，只能使用TC的key-value資料結構儲存。
二、滿足海量儲存需求和訪問的面向文件的資料庫：MongoDB，CouchDB
面向文件的非關係資料庫主要解決的問題不是高效能的併發讀寫，而是保證海量資料儲存的同時，具有良好的查詢效能。MongoDB是用C++開發的，而CouchDB則是Erlang開發的：
1、MongoDB
MongoDB是一個介於關係資料庫和非關係資料庫之間的產品，是非關係資料庫當中功能最豐富，最像關係資料庫的。他支援的資料結構非常鬆散，是類似 json的bjson格式，因此可以儲存比較複雜的資料型別。Mongo最大的特點是他支援的查詢語言非常強大，其語法有點類似於面向物件的查詢語言，幾乎可以實現類似關係資料庫單表查詢的絕大部分功能，而且還支援對資料建立索引。
Mongo主要解決的是海量資料的訪問效率問題，根據官方的文件，當資料量達到50GB以上的時候，Mongo的資料庫訪問速度是MySQL的10倍以 上。Mongo的併發讀寫效率不是特別出色，根據官方提供的效能測試表明，大約每秒可以處理0.5萬－1.5次讀寫請求。對於Mongo的併發讀寫效能， 我（robbin）也打算有空的時候好好測試一下。
因為Mongo主要是支援海量資料儲存的，所以Mongo還自帶了一個出色的分散式檔案系統GridFS，可以支援海量的資料儲存，但我也看到有些評論認為GridFS效能不佳，這一點還是有待親自做點測試來驗證了。
最後由於Mongo可以支援複雜的資料結構，而且帶有強大的資料查詢功能，因此非常受到歡迎，很多專案都考慮用MongoDB來替代MySQL來實現不是 特別複雜的Web應用，比方說why we migrated from MySQL to MongoDB就是一個真實的從MySQL遷移到MongoDB的案例，由於資料量實在太大，所以遷移到了Mongo上面，資料查詢的速度得到了非常顯著 的提升。
MongoDB也有一個ruby的專案MongoMapper，是模仿Merb的DataMapper編寫的MongoDB的介面，使用起來非常簡單，幾乎和DataMapper一模一樣，功能非常強大易用。
2、CouchDB
CouchDB現在是一個非常有名氣的專案，似乎不用多介紹了。但是我卻對CouchDB沒有什麼興趣，主要是因為CouchDB僅僅提供了基於HTTP REST的介面，因此CouchDB單純從併發讀寫效能來說，是非常糟糕的，這讓我立刻拋棄了對CouchDB的興趣。
三、滿足高可擴充套件性和可用性的面向分散式計算的資料庫：Cassandra，Voldemort
面向scale能力的資料庫其實主要解決的問題領域和上述兩類資料庫還不太一樣，它首先必須是一個分散式的資料庫系統，由分佈在不同節點上面的資料庫共同 構成一個數據庫服務系統，並且根據這種分散式架構來提供online的，具有彈性的可擴充套件能力，例如可以不停機的新增更多資料節點，刪除資料節點等等。因 此像Cassandra常常被看成是一個開源版本的Google BigTable的替代品。Cassandra和Voldemort都是用Java開發的：
1、Cassandra
Cassandra專案是Facebook在2008年開源出來的，隨後Facebook自己使用Cassandra的另外一個不開源的分支，而開源出來 的Cassandra主要被Amazon的Dynamite團隊來維護，並且Cassandra被認為是Dynamite2.0版本。目前除了 Facebook之外，twitter和digg.com都在使用Cassandra。
Cassandra的主要特點就是它不是一個數據庫，而是由一堆資料庫節點共同構成的一個分散式網路服務，對Cassandra的一個寫操作，會被複制到 其他節點上去，對Cassandra的讀操作，也會被路由到某個節點上面去讀取。對於一個Cassandra群集來說，擴充套件效能是比較簡單的事情，只管在 群集裡面新增節點就可以了。我看到有文章說Facebook的Cassandra群集有超過100臺伺服器構成的資料庫群集。
Cassandra也支援比較豐富的資料結構和功能強大的查詢語言，和MongoDB比較類似，查詢功能比MongoDB稍弱一些，twitter的平臺架構部門領導Evan Weaver寫了一篇文章介紹Cassandra：http://blog.evanweaver.com/artic ... ing-with-cassandra/，有非常詳細的介紹。
Cassandra以單個節點來衡量，其節點的併發讀寫效能不是特別好，有文章說評測下來Cassandra每秒大約不到1萬次讀寫請求，我也看到一些對 這個問題進行質疑的評論，但是評價Cassandra單個節點的效能是沒有意義的，真實的分散式資料庫訪問系統必然是n多個節點構成的系統，其併發效能取 決於整個系統的節點數量，路由效率，而不僅僅是單節點的併發負載能力。
2、Voldemort
Voldemort是個和Cassandra類似的面向解決scale問題的分散式資料庫系統，Cassandra來自於Facebook這個SNS網 站，而Voldemort則來自於Linkedin這個SNS網站。說起來SNS網站為我們貢獻了n多的NoSQL資料庫，例如 Cassandar，Voldemort，Tokyo Cabinet，Flare等等。Voldemort的資料不是很多，因此我沒有特別仔細去鑽研，Voldemort官方給出Voldemort的併發讀 寫效能也很不錯，每秒超過了1.5萬次讀寫。
從Facebook開發Cassandra，Linkedin開發Voldemort，我們也可以大致看出國外大型SNS網站對於分散式資料庫，特別是對資料庫的scale能力方面的需求是多麼殷切。前面我（robbin）提到，web應用的架構當中，web層和app層相對來說都很容易橫向擴充套件，唯有資料庫是單點的，極難scale，現在Facebook和Linkedin在非關係型資料庫的分散式方面探索了一條很好的方向，這也是為什麼現在Cassandra這麼熱門的主要原因。