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