公眾號:mywangxiao
及時發(fā)布考試資訊
分享考試技巧、復(fù)習(xí)經(jīng)驗(yàn)
新浪微博 @wangxiaocn關(guān)注微博
聯(lián)系方式 400-18-8000
隨著互聯(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ù)用戶個性化信息來實(shí)時生成動態(tài)頁面和提供動態(tài)信息,所以基本上無法使用動態(tài)頁面靜態(tài)化技術(shù),因此數(shù)據(jù)庫并發(fā)負(fù)載非常高,往往要達(dá)到每秒上萬次讀寫請求。關(guān)系數(shù)據(jù)庫應(yīng)付上萬次SQL查詢還勉強(qiáng)頂?shù)米。菓?yīng)付上萬次SQL寫數(shù)據(jù)請求,硬盤IO就已經(jīng)無法承受了。其實(shí)對于普通的BBS網(wǎng)站,往往也存在對高并發(fā)寫請求的需求,例如像JavaEye網(wǎng)站的實(shí)時統(tǒng)計在線用戶狀態(tài),記錄熱門帖子的點(diǎn)擊次數(shù),投票計數(shù)等,因此這是一個相當(dāng)普遍的需求。
2、Huge Storage——對海量數(shù)據(jù)的高效率存儲和訪問的需求
類似Facebook,twitter,F(xiàn)riendfeed這樣的SNS網(wǎng)站,每天用戶產(chǎn)生海量的用戶動態(tài),以Friendfeed為例,一個月就達(dá)到了2.5億條用戶動態(tài),對于關(guān)系數(shù)據(jù)庫來說,在一張2.5億條記錄的表里面進(jìn)行SQL查詢,效率是極其低下乃至不可忍受的。再例如大型web網(wǎng)站的用戶登錄系統(tǒng),例如騰訊,盛大,動輒數(shù)以億計的帳號,關(guān)系數(shù)據(jù)庫也很難應(yīng)付。
3、High Scalability && High Availability——對數(shù)據(jù)庫的高可擴(kuò)展性和高可用性的需求
在基于web的架構(gòu)當(dāng)中,數(shù)據(jù)庫是最難進(jìn)行橫向擴(kuò)展的,當(dāng)一個應(yīng)用系統(tǒng)的用戶量和訪問量與日俱增的時候,你的數(shù)據(jù)庫卻沒有辦法像web server和app server那樣簡單的通過添加更多的硬件和服務(wù)節(jié)點(diǎn)來擴(kuò)展性能和負(fù)載能力。對于很多需要提供24小時不間斷服務(wù)的網(wǎng)站來說,對數(shù)據(jù)庫系統(tǒng)進(jìn)行升級和擴(kuò)展是非常痛苦的事情,往往需要停機(jī)維護(hù)和數(shù)據(jù)遷移,為什么數(shù)據(jù)庫不能通過不斷的添加服務(wù)器節(jié)點(diǎn)來實(shí)現(xiàn)擴(kuò)展呢?
在上面提到的“三高”需求面前,關(guān)系數(shù)據(jù)庫遇到了難以克服的障礙,而對于web2.0網(wǎng)站來說,關(guān)系數(shù)據(jù)庫的很多主要特性卻往往無用武之地,例如:
1. 數(shù)據(jù)庫事務(wù)一致性需求
很多web實(shí)時系統(tǒng)并不要求嚴(yán)格的數(shù)據(jù)庫事務(wù),對讀一致性的要求很低,有些場合對寫一致性要求也不高。因此數(shù)據(jù)庫事務(wù)管理成了數(shù)據(jù)庫高負(fù)載下一個沉重的負(fù)擔(dān)。
2. 數(shù)據(jù)庫的寫實(shí)時性和讀實(shí)時性需求
對關(guān)系數(shù)據(jù)庫來說,插入一條數(shù)據(jù)之后立刻查詢,是肯定可以讀出來這條數(shù)據(jù)的,但是對于很多web應(yīng)用來說,并不要求這么高的實(shí)時性,比方說我(JavaEye的robbin)發(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)運(yùn)而生,現(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編寫的,每個都有自己的獨(dú)到之處,看都看不過來了,我(robbin)也只能從中挑選一些比較有特色,看起來更有前景的產(chǎn)品學(xué)習(xí)和了解一下。
編輯推薦
JAVA認(rèn)證考試報考指南 / 更多JAVA考試資料
(責(zé)任編輯:xy)