隨著互聯網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)也只能從中挑選一些比較有特色,看起來更有前景的產品學習和了解一下.
