隨著網際網路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資料庫大致可以分為以下的三類：
剩餘內容點我檢視
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資料庫大致可以分為以下的三類：
剩餘內容點我檢視