胡超曄，張忠能

0 引言

目前的互聯(lián)網(wǎng)應(yīng)用已經(jīng)進(jìn)入了Web2.0時(shí)代，互聯(lián)網(wǎng)應(yīng)用對于數(shù)據(jù)庫的支持，提出了更高的要求，總的來說，挑戰(zhàn)來自兩個(gè)方面，一者是數(shù)據(jù)規(guī)模越來越大，海量存儲(chǔ)的數(shù)據(jù)量的到來，使得原來傳統(tǒng)關(guān)系型數(shù)據(jù)庫在數(shù)據(jù)量與性能之間，原本就不平穩(wěn)的平衡岌岌可危；其次，由于Web2.0本身的時(shí)代特點(diǎn)，讀少寫多的特點(diǎn)，已經(jīng)取代了讀多寫少的Web1.0時(shí)代的重要特征。針對這兩個(gè)IT時(shí)代的應(yīng)用新特點(diǎn)，傳統(tǒng)的關(guān)系型數(shù)據(jù)庫表現(xiàn)力不從心，如何解決這個(gè)難題，成了數(shù)據(jù)庫應(yīng)用面臨的最大挑戰(zhàn)，必須受到高度重視。針對上述現(xiàn)實(shí)，Key-value數(shù)據(jù)庫脫穎而出，在設(shè)計(jì)中可以與關(guān)系型數(shù)據(jù)庫很好的結(jié)合，從而使得在現(xiàn)有服務(wù)不受影響的情況下，解決數(shù)據(jù)量大、數(shù)據(jù)訪問讀少寫多的性能問題。

在此背景下，一種新型的Key-value數(shù)據(jù)庫誕生了，這種數(shù)據(jù)庫，在解決上述兩個(gè)問題上游刃有余，Key-value數(shù)據(jù)庫內(nèi)部使用key-value結(jié)構(gòu)，即多維的哈希表、有查詢速度快、支持?jǐn)?shù)據(jù)量大下高速寫入、高并發(fā)讀寫等特點(diǎn)。

本文利用一種名叫Cassandra的Key-value非關(guān)系型數(shù)據(jù)庫，結(jié)合原有的傳統(tǒng)的關(guān)系型數(shù)據(jù)庫，設(shè)計(jì)一個(gè)網(wǎng)站架構(gòu)模型，在這個(gè)模型中，將傳統(tǒng)關(guān)系型數(shù)據(jù)庫不能勝任的功能特性，交由Key-value型數(shù)據(jù)庫來處理，從而可以從容應(yīng)對Web2.0帶給網(wǎng)站的兩大挑戰(zhàn)。

1 Web2.0時(shí)代的數(shù)據(jù)變化

Web2.0時(shí)代的來臨，使得計(jì)算機(jī)應(yīng)用，尤其是網(wǎng)絡(luò)應(yīng)用，發(fā)生了巨大的變化。在這個(gè)更加自由的網(wǎng)絡(luò)時(shí)代，越來越多的用戶被允許同時(shí)也愿意，在互聯(lián)網(wǎng)的世界里添加自己的心情、狀態(tài)、對新聞添加評(píng)論、與人分享自己的感想和經(jīng)歷。這種變化，對于數(shù)據(jù)庫服務(wù)器來說，主要發(fā)生在兩個(gè)方面：

1.1 數(shù)據(jù)量

海量數(shù)據(jù)的產(chǎn)出基于兩個(gè)原因：

1.1.1 用戶數(shù)據(jù)

web2.0之后，出現(xiàn)了大量用戶互動(dòng)型的網(wǎng)站，用戶可以添加博客，發(fā)送微博消息，與其他用戶發(fā)生即時(shí)通信，對某篇文章進(jìn)行評(píng)論，對某個(gè)觀點(diǎn)進(jìn)行投票。這些海量信息的數(shù)量相比，web2.0之前的網(wǎng)站，以幾何級(jí)數(shù)的形式增長。同時(shí)，越來越多的人通過個(gè)人電腦接入網(wǎng)絡(luò)，在訪問網(wǎng)絡(luò)資源的人口基數(shù)變化，也是產(chǎn)生更多用戶數(shù)據(jù)的原因。這部分大量增加的數(shù)據(jù)，我們也稱為用戶互動(dòng)信息。

1.1.2 系統(tǒng)數(shù)據(jù)

隨著計(jì)算機(jī)技術(shù)的普及，各行各業(yè)電子信息化的應(yīng)用越來越普遍，越來越多的系統(tǒng)數(shù)據(jù)就此產(chǎn)生，例如：工廠為自己的儀器設(shè)備增加監(jiān)控儀器，儀器會(huì)每隔一段時(shí)間記錄設(shè)備的工作狀態(tài)，這就產(chǎn)生了記錄用的時(shí)序數(shù)據(jù)，或者是網(wǎng)絡(luò)應(yīng)用為了提供某些非實(shí)時(shí)服務(wù)（例如統(tǒng)計(jì)，分析）而記錄的日志，網(wǎng)絡(luò)游戲中記錄的游戲過程等。這些數(shù)據(jù)數(shù)量龐大，當(dāng)需要記錄到數(shù)據(jù)庫中的時(shí)候就會(huì)產(chǎn)生瓶頸。

1.2 數(shù)據(jù)的訪問方式

Web2.0之前的數(shù)據(jù)訪問形式往往是這樣：編輯或網(wǎng)站工作人員，將組織好的文章或其他網(wǎng)絡(luò)資源放在網(wǎng)頁上，然后用戶訪問這些資源，這樣的形式，對于后臺(tái)服務(wù)器來說，主要是讀的操作（用戶），少量寫的操作（網(wǎng)站編輯或者工作人員），即寫少讀多。而web2.0之后，應(yīng)用形式和數(shù)據(jù)量的改變，使得數(shù)據(jù)的訪問形式發(fā)生了大量的變化，用戶自己將文章、照片、視頻等上傳網(wǎng)絡(luò)與其他用戶分享，而其他用戶往往只是閱讀其中的一小部分，這樣對于后臺(tái)服務(wù)器來說，承載的主要壓力，將來自于寫（用戶上傳網(wǎng)絡(luò)資源），而小部分的讀（用戶訪問其他用戶的上傳內(nèi)容），即寫多讀少是目前網(wǎng)站的主要訪問模式。其中主要的寫操作的內(nèi)容，就是前面提到的用戶互動(dòng)信息和時(shí)序數(shù)據(jù)。

2 關(guān)系型數(shù)據(jù)庫的局限

2.1 傳統(tǒng)關(guān)系型數(shù)據(jù)庫網(wǎng)站的架構(gòu)

傳統(tǒng)的僅適用關(guān)系型數(shù)據(jù)庫的網(wǎng)站的主體架構(gòu)，包含如下部分：應(yīng)用服務(wù)器集群、中間件服務(wù)器集群和關(guān)系型數(shù)據(jù)庫集群。

應(yīng)用服務(wù)器集群，負(fù)責(zé)處理用戶請求，向后臺(tái)申請數(shù)據(jù)，前臺(tái)邏輯處理等。

中間件服務(wù)器集群，負(fù)責(zé)控制連接池，是數(shù)據(jù)庫為應(yīng)用服務(wù)器服務(wù)的橋梁。

關(guān)系型數(shù)據(jù)庫集群式數(shù)據(jù)的集中存儲(chǔ)，接受來自前臺(tái)的數(shù)據(jù)請求，提供數(shù)據(jù)。

其簡略的架構(gòu)圖，如圖1所示：

圖1 關(guān)系型數(shù)據(jù)庫網(wǎng)站的架構(gòu)

2.2 傳統(tǒng)關(guān)系型數(shù)據(jù)庫的局限及其原因

在上圖的模型中，一般而言，當(dāng)用戶數(shù)量成倍增加的時(shí)候，應(yīng)用服務(wù)器集群和中間件服務(wù)器，僅需要線性增加就可以滿足需要，但是對于數(shù)據(jù)一致性要求極高的關(guān)系型數(shù)據(jù)庫來說，問題就沒有那么簡單了。

對于，目前的關(guān)系型數(shù)據(jù)庫（即使是其中最優(yōu)秀的關(guān)系型數(shù)據(jù)庫，例如Oracle）顯得越來越力不從心，主要方面體現(xiàn)在：

1. 單位時(shí)間產(chǎn)生的海量數(shù)據(jù)，關(guān)系型數(shù)據(jù)庫來不及處理，

2. 網(wǎng)站規(guī)模越來越大，單節(jié)點(diǎn)關(guān)系型數(shù)據(jù)庫，無法提供數(shù)量如此巨大的服務(wù)，多節(jié)點(diǎn)關(guān)系型數(shù)據(jù)庫的擴(kuò)展性，面臨挑戰(zhàn)的問題會(huì)存在，如表1所示：

表1 關(guān)系型數(shù)據(jù)庫的局限和原因

2.3 彌補(bǔ)關(guān)系型數(shù)據(jù)庫的思路

在Web2.0下，關(guān)系型數(shù)據(jù)庫力不從心的部分，主要是在用戶互動(dòng)信息數(shù)據(jù)以及時(shí)序數(shù)據(jù)，原因在于，關(guān)系型數(shù)據(jù)庫的機(jī)制是高度一致性，根據(jù) CAP理論，Consistency（一致性），Availability（可得性）和Performance（性能）之多獲得其二，關(guān)系型數(shù)據(jù)庫一直強(qiáng)調(diào)的是C和A（A在有用戶訪問的情況下是必不可少的），所以必然會(huì)喪失 P，這也就是關(guān)系型數(shù)據(jù)庫的性能不盡如人意的原因。而現(xiàn)在實(shí)際情況是，用戶互動(dòng)信息數(shù)據(jù)以及時(shí)序數(shù)據(jù)的時(shí)候，往往是少量的（數(shù)據(jù)讀少寫多，相對于寫，少有人來讀）或者是非實(shí)時(shí)的，我們所需要的是性能，所以根據(jù)這個(gè)理論，我們可以考慮犧牲C來獲得P。Key-value數(shù)據(jù)庫正好可以滿足這樣的需求，通過非實(shí)時(shí)一致性（最終一致性）來大幅度提升數(shù)據(jù)庫的性能，從而實(shí)現(xiàn)高并發(fā)讀寫。

3. Key-value數(shù)據(jù)庫的應(yīng)用

3.1 Key-value數(shù)據(jù)庫的特點(diǎn)

Key-value數(shù)據(jù)庫屬于非關(guān)系型數(shù)據(jù)庫，也稱Nosql，全稱是Not Only SQL，是一種不同于關(guān)系型數(shù)據(jù)庫的數(shù)據(jù)庫管理系統(tǒng)設(shè)計(jì)方式，其查詢訪問方式不是通過傳統(tǒng)的SQL，而是通過其各自提供的 API。Key-value數(shù)據(jù)庫強(qiáng)調(diào)并主要滿足龐大的水平擴(kuò)展性。NoSQL的最主要特點(diǎn)，就是可以處理超大量的數(shù)據(jù)。本文以Key-value數(shù)據(jù)庫Cassandra為例，做一介紹。

3.2 Cassandra特點(diǎn)的介紹

Key-value數(shù)據(jù)庫的結(jié)構(gòu)與傳統(tǒng)關(guān)系型數(shù)據(jù)庫不同，以Key-value類型的表結(jié)構(gòu)為主（例如Cassandra等，本文也主要以Cassandra為主要舉例對象）

Cassandra是Apache的一個(gè)自由，開源的分布式數(shù)據(jù)庫，其主要結(jié)構(gòu)特征如下：

3.2.1 Key-value結(jié)構(gòu)

Key-value的結(jié)構(gòu)，區(qū)別于關(guān)系型數(shù)據(jù)庫中主外鍵的模式，key-value的結(jié)構(gòu)，使得關(guān)系型數(shù)據(jù)庫表結(jié)構(gòu)的定義更加自由，其中value中可以包含不定的column，而且可以不用預(yù)先定義，這樣數(shù)據(jù)庫在導(dǎo)入數(shù)據(jù)的時(shí)候，就不會(huì)有過多的校驗(yàn)部分，這樣可以很明顯地提高效率。Key-Value的組織形式，如圖2所示：

圖2 關(guān)系型數(shù)據(jù)庫網(wǎng)站的架構(gòu)

Cassandra的表結(jié)構(gòu)采用Key-value，即多維的哈希表，在存儲(chǔ)數(shù)據(jù)前不需要預(yù)先定義列的含義，而是根據(jù)key值將數(shù)據(jù)以column的形式存儲(chǔ)。Column的個(gè)數(shù)，格式可以每行不同

3.2.2 分布式

Cassandra的部署是采用分布式結(jié)構(gòu)，即多個(gè)節(jié)點(diǎn)共同組成了數(shù)據(jù)庫，多個(gè)節(jié)點(diǎn)可同時(shí)訪問，同時(shí)讀寫操作，這樣的結(jié)構(gòu)使得數(shù)據(jù)庫有很好的水平擴(kuò)展性，同時(shí)，如果設(shè)置冗余，可以有效的提高系統(tǒng)的高可用性，從而使得數(shù)據(jù)庫更加可靠。

3.2.3 無中心節(jié)點(diǎn)的對稱結(jié)構(gòu)

無中心的設(shè)置，使得數(shù)據(jù)庫能夠保證其負(fù)載均衡，同時(shí)這樣的結(jié)構(gòu)，也使得添加，減少節(jié)點(diǎn)比較容易實(shí)現(xiàn)。

Cassandra分布式結(jié)構(gòu)及無中心對稱結(jié)構(gòu)，如圖3所示：

圖3 Cassandra分布式對稱結(jié)構(gòu)圖

3.3 由Key-value數(shù)據(jù)庫Cassandra參與的網(wǎng)站架構(gòu)

針對Web2.0的網(wǎng)絡(luò)應(yīng)用特點(diǎn)，Key-value數(shù)據(jù)庫是對關(guān)系型數(shù)據(jù)庫的一個(gè)很好的彌補(bǔ)，由Key-value數(shù)據(jù)庫來處理海量的數(shù)據(jù)，而關(guān)系型數(shù)據(jù)庫處理過去經(jīng)典的業(yè)務(wù)邏輯，兩者配合，發(fā)揮各自優(yōu)點(diǎn)，可以做到相輔相成，相得益彰。

Key-value數(shù)據(jù)庫Cassandra為基礎(chǔ)的網(wǎng)站架構(gòu)圖，如圖4所示：

圖4 由Key-value數(shù)據(jù)庫Cassandra參與的網(wǎng)站架構(gòu)

其中，Key-value數(shù)據(jù)庫集群部分與關(guān)系型數(shù)據(jù)庫部分同時(shí)與中間件連接，由應(yīng)用服務(wù)器或中間件來判斷選擇，使用何種數(shù)據(jù)庫集群來讀取數(shù)據(jù)，判斷原則一般為：重要的，少量的數(shù)據(jù)存儲(chǔ)于關(guān)系型數(shù)據(jù)庫中；不重要的，日志性的（例如，系統(tǒng)日志、用戶評(píng)論、微博信息、游戲日志）數(shù)據(jù)，一般，也就是本文重點(diǎn)針對的用戶互動(dòng)信息或時(shí)序數(shù)據(jù)由Key-value數(shù)據(jù)庫負(fù)責(zé)。

3.4 性能對比

對于關(guān)系型數(shù)據(jù)庫和Cassandra數(shù)據(jù)庫做了個(gè)簡單的對比。

測試方法：在兩臺(tái)CPU為IntelQ8400，內(nèi)存2G的服務(wù)器上，分別按照Oracle和Cassandra（均為2節(jié)點(diǎn)數(shù)據(jù)庫），并在不同存量數(shù)據(jù)的情況下，做插入數(shù)據(jù)的實(shí)驗(yàn)，測試其速度，結(jié)果，如表2所示：

表2 關(guān)系型數(shù)據(jù)庫與Cassandra數(shù)據(jù)庫在不同存量數(shù)據(jù)的情況下的數(shù)據(jù)插入速度

4. Key-value數(shù)據(jù)庫的優(yōu)勢

Cassandra與傳統(tǒng)的關(guān)系型數(shù)據(jù)庫，有十分顯著的區(qū)別，這種特點(diǎn)，正好對于滿足時(shí)序數(shù)據(jù)處理以及用戶互動(dòng)數(shù)據(jù)處理十分合適，因?yàn)椋?/p>

4.1.1 高并發(fā)讀寫性能

Web2.0網(wǎng)站要根據(jù)用戶個(gè)性化信息，使得數(shù)據(jù)庫并發(fā)負(fù)載非常高。關(guān)系數(shù)據(jù)庫可以勉強(qiáng)做到上萬次SQL查詢，但是對上萬次SQL寫數(shù)據(jù)請求，就比較困難了,而Key-value數(shù)據(jù)的強(qiáng)大的可擴(kuò)展性以及分布式的結(jié)構(gòu)，可以很好地應(yīng)對這一特點(diǎn)。Key-value數(shù)據(jù)庫不需要在寫數(shù)據(jù)文件的過程中優(yōu)先寫日志，從而不會(huì)引起數(shù)據(jù)庫因?yàn)槿罩疚募]有寫好而掛起，同時(shí)，由于數(shù)據(jù)文件本身，就是由key-value形式的哈希表構(gòu)成，所以不需要額外的索引開銷，同時(shí)對于數(shù)據(jù)提供了極好的支持，最終達(dá)到高并發(fā)讀寫的特點(diǎn)。

4.1.2 海量存儲(chǔ)

對于大型網(wǎng)站，每天用戶產(chǎn)生海量的用戶動(dòng)態(tài)，對于關(guān)系數(shù)據(jù)庫來說，在一張億條記錄的表里面進(jìn)行SQL查詢，效率是極其低下乃至不可忍受的。而這對于Key-value數(shù)據(jù)庫來說，key-value形式的存儲(chǔ)結(jié)構(gòu)，使得對于數(shù)據(jù)量有很好的提升

4.1.3 高穩(wěn)定性及高可用性

在基于 web的架構(gòu)當(dāng)中，數(shù)據(jù)庫是最難進(jìn)行橫向擴(kuò)展的，當(dāng)一個(gè)應(yīng)用系統(tǒng)的用戶量和訪問量與日俱增的時(shí)候，你的數(shù)據(jù)庫卻沒有辦法像web server和app server那樣簡單的通過添加更多的硬件和服務(wù)節(jié)點(diǎn)，來擴(kuò)展性能和負(fù)載能力。對于很多需要提供24小時(shí)不間斷服務(wù)的網(wǎng)站來說，對數(shù)據(jù)庫系統(tǒng)進(jìn)行升級(jí)和擴(kuò)展，是非常痛苦的事情，往往需要停機(jī)維護(hù)和數(shù)據(jù)遷移，為什么數(shù)據(jù)庫不能通過不斷的添加服務(wù)器節(jié)點(diǎn)來實(shí)現(xiàn)擴(kuò)展呢？分布式無中心的Key-value數(shù)據(jù)庫，使得數(shù)據(jù)庫可以保持相當(dāng)?shù)娜哂嘈?，合理的配置可以避免單點(diǎn)故障的發(fā)生。

4.1.4 數(shù)據(jù)庫事務(wù)一致性需求

很多web實(shí)時(shí)系統(tǒng)，并不要求嚴(yán)格的數(shù)據(jù)庫事務(wù)，對讀一致性的要求很低，有些場合對寫一致性要求也不高。因此數(shù)據(jù)庫事務(wù)管理，成了數(shù)據(jù)庫高負(fù)載下一個(gè)沉重的負(fù)擔(dān)。對關(guān)系數(shù)據(jù)庫來說，插入一條數(shù)據(jù)之后立刻查詢，是肯定可以讀出這條數(shù)據(jù)的，但是對于很多 web應(yīng)用來說，并不要求這么高的實(shí)時(shí)性。

對于一些互動(dòng)類的業(yè)務(wù)、用戶評(píng)價(jià)等，用戶并沒有實(shí)時(shí)查詢到其他用戶評(píng)價(jià)的需要，只要可以有最終一致性，就可以滿足用戶的需求。

4.1.5 方便的可擴(kuò)展性

其次，分布式無中心的結(jié)構(gòu)，也使得數(shù)據(jù)庫具有很強(qiáng)大的水平擴(kuò)展性。

由于沒有中心節(jié)點(diǎn)，所有的節(jié)點(diǎn)都是對等的，所以在增加和減少節(jié)點(diǎn)的情況下，就會(huì)變得比較容易，速度也會(huì)比較快，大大降低了維護(hù)的成本和開銷。

4.1.6 對復(fù)雜的SQL查詢，特別是多表關(guān)聯(lián)查詢的需求

Key-value數(shù)據(jù)庫不擅長進(jìn)行關(guān)系型查詢，但是這點(diǎn)在處理時(shí)序數(shù)據(jù)以及互動(dòng)數(shù)據(jù)的處理來說是可以規(guī)避的，在大型SNS網(wǎng)站中，大量的用戶數(shù)據(jù)產(chǎn)生，但數(shù)據(jù)的查詢，可以通過用戶以及時(shí)間點(diǎn)進(jìn)行key值建立，所以，應(yīng)用可以方便地通過這些信息定位到key值，從而獲取了value里的數(shù)據(jù)。

5 結(jié)論

隨著IT應(yīng)用的發(fā)展，越來越大的數(shù)據(jù)量的需求產(chǎn)生，于是我們需要更加有力的數(shù)據(jù)庫的支撐，Key-value數(shù)據(jù)庫為一種最新的數(shù)據(jù)庫，打破了傳統(tǒng)關(guān)系型數(shù)據(jù)庫壟斷的局面，可以以新的思路、新的方式解決新的問題。

Key-value數(shù)據(jù)庫能夠：

1) 加載更大的數(shù)據(jù)量

2) 強(qiáng)大的水平擴(kuò)展性

3) 強(qiáng)大的讀寫并發(fā)

這些Key-value數(shù)據(jù)庫優(yōu)越表現(xiàn)在如果可以和傳統(tǒng)的關(guān)系型數(shù)據(jù)庫相結(jié)合，必定能使得其在web2.0時(shí)代，得以充分的發(fā)揮其優(yōu)勢。

[1]王珊, 薩師煊,數(shù)據(jù)庫系統(tǒng)概論 2010.6

[2]西爾伯沙茨 數(shù)據(jù)庫系統(tǒng)概念 2006.10

[3]Eben Hewitt, Cassandra：the Definitive Guide 2010.3

[4]Prabhakar Chaganti, Amazon Simple [DB]Developer Guide Jun 2010 2010.4