隨著云計(jì)算時(shí)代的到來(lái)，各種類(lèi)型的互聯(lián)網(wǎng)應(yīng)用層出不窮，對(duì)與此相關(guān)的數(shù)據(jù)模型、分布式架構(gòu)、數(shù)據(jù)存儲(chǔ)等數(shù)據(jù)庫(kù)相關(guān)的技術(shù)指標(biāo)也提出了新的要求。雖然傳統(tǒng)的關(guān)系型數(shù)據(jù)庫(kù)已在數(shù)據(jù)存儲(chǔ)方面占據(jù)了不可動(dòng)搖的地位，但由于其天生的限制，已經(jīng)越來(lái)越無(wú)法滿足云計(jì)算時(shí)代對(duì)數(shù)據(jù)擴(kuò)展、讀寫(xiě)速度、支撐容量以及建設(shè)和運(yùn)營(yíng)成本的要求。云計(jì)算時(shí)代對(duì)數(shù)據(jù)庫(kù)技術(shù)提出了新的需求，主要表現(xiàn)在以下幾個(gè)方面。
海量數(shù)據(jù)處理：對(duì)類(lèi)似搜索引擎和電信運(yùn)營(yíng)商級(jí)的經(jīng)營(yíng)分析系統(tǒng)這樣大型的應(yīng)用而言，需要能夠處理PB級(jí)的數(shù)據(jù)，同時(shí)應(yīng)對(duì)百萬(wàn)級(jí)的流量。
大規(guī)模集群管理：分布式應(yīng)用可以更加簡(jiǎn)單地部署、應(yīng)用和管理。
低延遲讀寫(xiě)速度：快速的響應(yīng)速度能夠極大地提高用戶的滿意度。
建設(shè)及運(yùn)營(yíng)成本：云計(jì)算應(yīng)用的基本要求是希望在硬件成本、軟件成本以及人力成本方面都有大幅度的降低。
關(guān)系型數(shù)據(jù)庫(kù)的劣勢(shì)分析
隨著Web2.0的發(fā)展，傳統(tǒng)的關(guān)系型數(shù)據(jù)庫(kù)在應(yīng)對(duì)超大規(guī)模和高并發(fā)的SNS類(lèi)型的網(wǎng)站方面暴露了許多難以克服的問(wèn)題，主要表現(xiàn)在以下方面。
(1)高并發(fā)讀寫(xiě)速度慢
這種情況主要發(fā)生在數(shù)據(jù)量達(dá)到一定規(guī)模時(shí)，由于關(guān)系型數(shù)據(jù)庫(kù)的系統(tǒng)邏輯非常復(fù)雜，使得其非常容易發(fā)生死鎖等并發(fā)問(wèn)題，導(dǎo)致其讀寫(xiě)速度下降非常嚴(yán)重。例如，Web2.0網(wǎng)站要根據(jù)用戶個(gè)性化信息來(lái)實(shí)時(shí)生成動(dòng)態(tài)頁(yè)面、提供動(dòng)態(tài)信息，所以基本上無(wú)法使用動(dòng)態(tài)頁(yè)面靜態(tài)化技術(shù)，因此數(shù)據(jù)庫(kù)并發(fā)負(fù)載非常高，往往要達(dá)到每秒上萬(wàn)次讀寫(xiě)請(qǐng)求。關(guān)系型數(shù)據(jù)庫(kù)勉強(qiáng)可以應(yīng)付上萬(wàn)次SQL查詢，硬盤(pán)I/O往往無(wú)法承擔(dān)上萬(wàn)次的SQL寫(xiě)數(shù)據(jù)請(qǐng)求。
(2)支撐容量有限
類(lèi)似Facebook、Twitter這樣的SNS網(wǎng)站，用戶每天產(chǎn)生海量的用戶動(dòng)態(tài)，每月會(huì)產(chǎn)生幾億條用戶動(dòng)態(tài)，對(duì)于關(guān)系型數(shù)據(jù)庫(kù)來(lái)說(shuō)，在一張數(shù)億條記錄的表里面進(jìn)行SQL查詢，效率是極其低下乃至不可忍受的。
(3)擴(kuò)展性差
在基于Web的架構(gòu)當(dāng)中，數(shù)據(jù)庫(kù)是最難進(jìn)行橫向擴(kuò)展的，當(dāng)一個(gè)應(yīng)用系統(tǒng)的用戶量和訪問(wèn)量與日俱增的時(shí)候，傳統(tǒng)的關(guān)系型數(shù)據(jù)庫(kù)卻沒(méi)有辦法像Web Server那樣簡(jiǎn)單地通過(guò)添加更多的硬件和服務(wù)節(jié)點(diǎn)來(lái)擴(kuò)展性能和負(fù)載能力。對(duì)于很多需要提供不間斷服務(wù)的網(wǎng)站來(lái)說(shuō)，對(duì)數(shù)據(jù)庫(kù)系統(tǒng)進(jìn)行升級(jí)和擴(kuò)展是非常痛苦的事情，往往需要停機(jī)維護(hù)和數(shù)據(jù)遷移，因此迫切需要關(guān)系型數(shù)據(jù)庫(kù)也能夠通過(guò)不斷添加服務(wù)器節(jié)點(diǎn)來(lái)實(shí)現(xiàn)擴(kuò)展。
(4)建設(shè)和運(yùn)維成本高
企業(yè)級(jí)數(shù)據(jù)庫(kù)的價(jià)格很高，并且隨著系統(tǒng)的規(guī)模增大而不斷上升。高昂的建設(shè)和運(yùn)維成本無(wú)法滿足云計(jì)算應(yīng)用對(duì)數(shù)據(jù)庫(kù)的需求。
關(guān)系型數(shù)據(jù)庫(kù)遇到上述難以克服的瓶頸，與此同時(shí)，它的很多主要特性在云計(jì)算應(yīng)用中卻往往無(wú)用武之地，例如：數(shù)據(jù)庫(kù)事務(wù)一致性、數(shù)據(jù)庫(kù)的寫(xiě)實(shí)時(shí)性和讀實(shí)時(shí)性、復(fù)雜的SQL查詢特別是多表關(guān)聯(lián)查詢。因此，傳統(tǒng)的關(guān)系型數(shù)據(jù)庫(kù)已經(jīng)無(wú)法獨(dú)立應(yīng)付云計(jì)算時(shí)代的各種應(yīng)用。
NoSQL數(shù)據(jù)庫(kù)數(shù)據(jù)模型
關(guān)系型數(shù)據(jù)庫(kù)越來(lái)越無(wú)法滿足云計(jì)算的應(yīng)用場(chǎng)景，為了解決此類(lèi)問(wèn)題，非關(guān)系型數(shù)據(jù)庫(kù)應(yīng)運(yùn)而生，由于在設(shè)計(jì)上和傳統(tǒng)的關(guān)系型數(shù)據(jù)庫(kù)相比有了很大的不同，所以此類(lèi)數(shù)據(jù)庫(kù)被稱(chēng)為“NoSQL(Not only SQL)”系列數(shù)據(jù)庫(kù)。與關(guān)系型數(shù)據(jù)庫(kù)相比，它們非常關(guān)注對(duì)數(shù)據(jù)高并發(fā)讀寫(xiě)和海量數(shù)據(jù)的存儲(chǔ)，在架構(gòu)和數(shù)據(jù)模型方面作了簡(jiǎn)化，而在擴(kuò)展和并發(fā)等方面作了增強(qiáng)。目前，主流的NoSQL數(shù)據(jù)庫(kù)包括BigTable、HBase、Cassandra、SimpleDB、CouchDB、MongoDB以及 Redis等。NoSQL常用數(shù)據(jù)模型包括以下3種。
(1)Column-oriented(列式)
列式主要使用Table這樣的模型，但是它并不支持類(lèi)似Join這樣多表的操作，它的主要特點(diǎn)是在存儲(chǔ)數(shù)據(jù)時(shí)，主要圍繞著“列(Column)”，而不是像傳統(tǒng)的關(guān)系型數(shù)據(jù)庫(kù)那樣根據(jù)“行(Row)”進(jìn)行存儲(chǔ)，也就是說(shuō)，屬于同一列的數(shù)據(jù)會(huì)盡可能地存儲(chǔ)在硬盤(pán)同一個(gè)頁(yè)中，而不是將屬于同一個(gè)行的數(shù)據(jù)存放在一起。這樣做的好處是，對(duì)于很多類(lèi)似數(shù)據(jù)倉(cāng)庫(kù)的應(yīng)用，雖然每次查詢都會(huì)處理很多數(shù)據(jù)，但是每次所涉及的列并沒(méi)有很多。使用列式數(shù)據(jù)庫(kù)，將會(huì)節(jié)省大量I/O,并且大多數(shù)列式數(shù)據(jù)庫(kù)都支持Column Family這個(gè)特性，能將多個(gè)列并為一個(gè)小組。這樣做的好處是能將相似列放在一起存儲(chǔ)，提高這些列的存儲(chǔ)和查詢效率。總體而言，這種數(shù)據(jù)模型的優(yōu)點(diǎn)是比較適合匯總和數(shù)據(jù)倉(cāng)庫(kù)這類(lèi)應(yīng)用。
(2)Key-value
雖然Key-value這種模型和傳統(tǒng)的關(guān)系型相比較簡(jiǎn)單，有點(diǎn)類(lèi)似常見(jiàn)的HashTable,一個(gè)Key對(duì)應(yīng)一個(gè)Value,但是它能提供非常快的查詢速度、大的數(shù)據(jù)存放量和高并發(fā)操作，非常適合通過(guò)主鍵對(duì)數(shù)據(jù)進(jìn)行查詢和修改等操作，雖然不支持復(fù)雜的操作，但是可以通過(guò)上層的開(kāi)發(fā)來(lái)彌補(bǔ)這個(gè)缺陷。
(3)Document(文檔)
在結(jié)構(gòu)上，Document和Key-value是非常相似的，也是一個(gè)Key對(duì)應(yīng)一個(gè)Value,但是這個(gè)Value主要以JSON或者 XML等格式的文檔來(lái)進(jìn)行存儲(chǔ)，是有語(yǔ)義的，并且Document DB一般可以對(duì)Value來(lái)創(chuàng)建Secondary Index來(lái)方便上層的應(yīng)用，而這點(diǎn)是普通Key-Value DB所無(wú)法支持的。
常用NoSQL數(shù)據(jù)庫(kù)比較及優(yōu)劣勢(shì)分析
(1)主要NoSQL數(shù)據(jù)庫(kù)比較
從設(shè)計(jì)理念、數(shù)據(jù)模式、分布式等幾個(gè)角度對(duì)BigTable、Cassandra、Redis、MongoDB進(jìn)行比較，見(jiàn)表1.
(2) NoSQL數(shù)據(jù)庫(kù)的優(yōu)勢(shì)分析
NoSQL數(shù)據(jù)庫(kù)主要有以下優(yōu)勢(shì)：
擴(kuò)展簡(jiǎn)單，典型例子是Cassandra,由于其架構(gòu)類(lèi)似于經(jīng)典的P2P,因此能夠通過(guò)簡(jiǎn)單添加新的節(jié)點(diǎn)來(lái)擴(kuò)展集群;
讀寫(xiě)快速，典型例子是Redis,由于其邏輯簡(jiǎn)單，純內(nèi)存操作，因此其具有非常出色的性能，單節(jié)點(diǎn)每秒可以處理超過(guò)10萬(wàn)次的讀寫(xiě)操作;
成本低廉，因?yàn)榇蠖鄶?shù)NoSQL數(shù)據(jù)庫(kù)都是開(kāi)源軟件，沒(méi)有昂貴的成本限制。
(3)NoSQL數(shù)據(jù)庫(kù)的劣勢(shì)分析
雖然NoSQL具有很多顯著的優(yōu)勢(shì)，但是依然存在很多不足，主要表現(xiàn)在：
不提供對(duì)SQL的支持，將會(huì)對(duì)用戶產(chǎn)生一定的應(yīng)用遷移成本，同時(shí)，無(wú)法實(shí)現(xiàn)組合應(yīng)用，發(fā)揮SQL數(shù)據(jù)庫(kù)已經(jīng)非常成熟的優(yōu)勢(shì);
支持的特性不夠豐富，現(xiàn)有NoSQL數(shù)據(jù)庫(kù)提供的功能十分有限，大多數(shù)都不支持事務(wù)和其他附加功能;
產(chǎn)品不夠成熟，大多數(shù)NoSQL數(shù)據(jù)庫(kù)產(chǎn)品還處于初級(jí)階段，與已經(jīng)非常完善成熟的關(guān)系型數(shù)據(jù)庫(kù)不可同日而語(yǔ)。
結(jié)束語(yǔ)
云計(jì)算主要常見(jiàn)的有兩類(lèi)場(chǎng)景：需要低延遲和高并發(fā)的讀寫(xiě)能力，數(shù)據(jù)量雖大，但不超過(guò)TB級(jí)別，大部分現(xiàn)在使用RDBMS的Web應(yīng)用基本上都屬于這一類(lèi)，類(lèi)似傳統(tǒng)的OLTP(聯(lián)機(jī)事務(wù)處理);海量數(shù)據(jù)的存儲(chǔ)和操作，如PB級(jí)別的，這方面的例子有傳統(tǒng)的數(shù)據(jù)倉(cāng)庫(kù)、Google海量的Web頁(yè)面和圖片存儲(chǔ)等，類(lèi)似傳統(tǒng)的OLAP(聯(lián)機(jī)分析處理)。目前，業(yè)界還沒(méi)有一款數(shù)據(jù)庫(kù)能同時(shí)適應(yīng)上述多種云計(jì)算場(chǎng)景的NoSQL數(shù)據(jù)庫(kù)。考慮到PaaS平臺(tái)的需求比較復(fù)雜，能夠在后臺(tái)進(jìn)行定制化的數(shù)據(jù)庫(kù)將是未來(lái)發(fā)展的趨勢(shì)，因此，輕量級(jí)的、兼顧高可擴(kuò)展和高可靠性的架構(gòu)設(shè)計(jì)將會(huì)受到歡迎。
京公網(wǎng)安備 11010502049343號(hào)