可擴(kuò)展的云關(guān)系型數(shù)據(jù)庫的研究

陳平平，譚定英，劉秀峰

（廣州中醫(yī)藥大學(xué) 信息技術(shù)學(xué)院，廣東 廣州510006）

0 引 言

如何高效存儲和管理企業(yè)日漸增長的龐大數(shù)據(jù)成為數(shù)據(jù)庫服務(wù)一個(gè)挑戰(zhàn)性問題。為了適應(yīng)這Z種增長需求，云數(shù)據(jù)庫服務(wù)產(chǎn)生了［1－2］。

到目前為止，Amazon的SimpleDB，Google的Bigtable和雅虎的HBase是公開的云數(shù)據(jù)庫服務(wù)［3－4］。但是，它們都不是基于關(guān)系型數(shù)據(jù)庫的［5－6］。因此，當(dāng)用戶想將關(guān)系數(shù)據(jù)庫的應(yīng)用遷移到 SimpleDB 時(shí)，必須做大量的修改［7－8］。Amazon的RDS是一種云關(guān)系型數(shù)據(jù)庫，它提供了一種容易使用的云關(guān)系型數(shù)據(jù)庫服務(wù)［9－10］。但它的可擴(kuò)展性有限，目前只支持單實(shí)例［11－12］。

1 架構(gòu)概述

可擴(kuò)展的云關(guān)系型數(shù)據(jù)庫平臺架構(gòu)如圖1所示，平臺分為四層。第一層為API層，它向第三方的應(yīng)用程序提供可供調(diào)用的服務(wù)，包括SDK和開放式存儲服務(wù)（open storage services，OSS）。第二層為應(yīng)用服務(wù)器（app server，AS）層，它是核心層，向上提供數(shù)據(jù)操作服務(wù)供API層調(diào)用。第三層為分布服務(wù)器（distribution server，DS）層，提供數(shù)據(jù)分布策略。第四層為數(shù)據(jù)節(jié)點(diǎn)（data node，DN）層，提供了可擴(kuò)展性的數(shù)據(jù)物理存儲，在DN層，多個(gè)DN成組成冗余集（redundant set，RS），多個(gè)RS組成節(jié)點(diǎn)組（node group，NG）。

圖1 可擴(kuò)展云關(guān)系型數(shù)據(jù)平臺架構(gòu)

2 API層

API層是可擴(kuò)展的云關(guān)系型數(shù)據(jù)庫平臺的服務(wù)層，包括SDK和OSS。API層的內(nèi)部結(jié)構(gòu)如圖2所示。

圖2 API層架構(gòu)

2.1 SDK機(jī)制

SDK遠(yuǎn)程調(diào)用OSS，并提供簡便的語言相關(guān)的開發(fā)接口。SDK提供面向?qū)ο蟮慕涌谝云帘蔚恼{(diào)用遠(yuǎn)程Web服務(wù)的復(fù)雜性。

在架構(gòu)中，用戶的數(shù)據(jù)存儲在關(guān)系數(shù)據(jù)庫管理系統(tǒng)中，因此SDK必須解決面向?qū)ο蠛完P(guān)系型數(shù)據(jù)的映射問題。SDK根據(jù)應(yīng)用程序的對象類，自動生成關(guān)系型表結(jié)構(gòu)并建立相應(yīng)的索引，并為有引用關(guān)系的對象類之間生成外鍵關(guān)聯(lián)。

此外，SDK提供平臺的模擬器。在開發(fā)階段，程序員可以在沒有連接平臺時(shí)測試它們的應(yīng)用程序，因?yàn)樵赟DK中有一些本地的存儲服務(wù)，能夠?yàn)閼?yīng)用程序提供與實(shí)際的云關(guān)系型數(shù)據(jù)庫服務(wù)相同的接口。

2.2 OSS機(jī)制

OSS是一系列通用的Web服務(wù)，可供各種多種不同語言的SDK調(diào)用。OSS是對AS層的封裝。OSS包括3種服務(wù)：安全服務(wù)，數(shù)據(jù)定義服務(wù)和數(shù)據(jù)操作服務(wù)。

2.3 安全策略

API層還負(fù)責(zé)安全策略的管理，包括用戶認(rèn)證與權(quán)限管理。所有的用戶認(rèn)證與權(quán)限管理都是隱式的。當(dāng)應(yīng)用程序正式運(yùn)行時(shí)，平臺為每個(gè)應(yīng)用程序生成相應(yīng)的許可，SDK向平臺發(fā)送請求時(shí)會自動調(diào)用屬于自己的許可。這樣，每個(gè)應(yīng)用程序只操作屬于自己的數(shù)據(jù)，從而隔離不同應(yīng)用程序之間的影響。

3 分布服務(wù)器（DS）層

圖3是DS層的架構(gòu)，它包括下面的特征：

·DS層由一個(gè)主節(jié)點(diǎn)（master node，MN）和若干個(gè)從節(jié)點(diǎn)（slave node，SN）組成。每個(gè)MN和SN有兩個(gè)單元：元節(jié)點(diǎn)和節(jié)點(diǎn)跟蹤器。

·元節(jié)點(diǎn)是用來維持分布的元數(shù)據(jù)和處理來自AS層的查詢。

·SN上的節(jié)點(diǎn)跟蹤器是用來處理DS層和DN層之間的心跳協(xié)議。

·MN上的節(jié)點(diǎn)跟蹤器負(fù)責(zé)匯總所有的DN狀態(tài)，它會報(bào)告MN上的元節(jié)點(diǎn)狀態(tài)的改變。

·所有MN和SN上的元節(jié)點(diǎn)是同步的。

圖3 分布服務(wù)（DS）器層架構(gòu)

3.1 DS層的構(gòu)成

3.1.1 主從機(jī)制

MN和SN運(yùn)行相同的程序，但運(yùn)行不同的程序分支。為了提高性能，MN有兩個(gè)線程，元節(jié)點(diǎn)線程接受來自AS層的查詢（AppID，ObjectID和Object的關(guān)鍵字），并將結(jié)果發(fā)回給AS層，返回結(jié)果包含NGid、RSid和DNid；節(jié)點(diǎn)跟蹤線程接受來自SN收集的DN狀態(tài)改變信息并更新元數(shù)據(jù)。SN有兩個(gè)線程，元節(jié)點(diǎn)線程接受來自MN的元數(shù)據(jù)更新要求并更新元數(shù)據(jù)，節(jié)點(diǎn)跟蹤線程通過心跳協(xié)議與DN通信，監(jiān)控DN的狀態(tài)并控制DN的故障轉(zhuǎn)移過程。

3.1.2 MN故障切換流程

當(dāng)MN出現(xiàn)故障時(shí)，在所有的SN中必須選出一個(gè)新的MN。首先，所有的SN通過Status＿Discovery消息將自己的狀態(tài)廣播給其他的SN，Status＿Discovery消息包括CPU利用率和內(nèi)存利用率。然后工作負(fù)載最少的SN的希望成為MN，它逐漸地通過廣播Election＿Request信息告訴給其它的SN，其它的SN會通過Election＿ACK信息響應(yīng)確認(rèn)。最后，后備的MN會將其從屬的角色轉(zhuǎn)換為主角色并重新啟動。此后，MN的故障轉(zhuǎn)移過程完成。

3.1.3 SN的負(fù)載均衡

SN上的節(jié)點(diǎn)跟蹤器主要負(fù)責(zé)監(jiān)控DN的狀態(tài)，并處理DS層和DN層之間的心跳協(xié)議。為了讓所有的SN實(shí)現(xiàn)負(fù)載均衡，DN將均勻的分配給不同的SN。負(fù)載均衡的算法可以是輪詢算法（Round Robin）或者最小效應(yīng)時(shí)間優(yōu)先算法（least response time）。

3.2 數(shù)據(jù)結(jié)構(gòu)

數(shù)據(jù)結(jié)構(gòu)如圖4所示。AppID用來識別不同的應(yīng)用，ObjectID是用來識別不同的表，KeyMin和KeyMax是用于定義表的段邊界，HostGroupID、RedundantSetID和PrimaryNodeID是用來標(biāo)識DN的表段存儲位置。NodeID是DN的標(biāo)識，每個(gè)NodeID是獨(dú)一無二的。NetworkLinkProvider是用來標(biāo)識不同的網(wǎng)絡(luò)供應(yīng)商。不同的DN可以跨越許多不同的數(shù)據(jù)中心。DN的狀態(tài)可以是New、Ready、Failed和Recovering。ResourceRatio是指CPU和內(nèi)存的利用率。

圖4 DS層的數(shù)據(jù)結(jié)構(gòu)

3.3 水平分布策略

水平分布策略是為了將不同的表分布到不同的NG、RS和DN上。當(dāng)一個(gè)新表被創(chuàng)建時(shí)，MN會選擇一個(gè)DN存儲這個(gè)表的第一個(gè)段。為了讓不同的DN工作負(fù)載平衡，許多因素都應(yīng)該綜合考慮。首先，要選擇一個(gè)NG，這個(gè)NG的應(yīng)該有數(shù)量最少的表和最多的空閑空間。其次，要選擇一個(gè)RS，這個(gè)RS在當(dāng)前NG內(nèi)，應(yīng)該有數(shù)量最少的表和最多的空閑空間。最后，選擇一個(gè)主DN，這個(gè)DN在當(dāng)前RS內(nèi)部處理的請求最少。

3.4 垂直分布機(jī)制

3.4.1 表段定義

表通過主鍵分裂成表段，如圖5所示，每段是256M字節(jié)，每段的所有數(shù)據(jù)將會存儲到同一個(gè)DN。當(dāng)新的記錄插入到表，一個(gè)段可以分成兩個(gè)部分。當(dāng)記錄從表中刪除后，兩個(gè)部分可能會合并成一個(gè)段。

圖5 表段分布

表段元數(shù)據(jù)是由MN維護(hù)，并且與所有其他SN同步。為了獲得最佳的查詢性能，每個(gè)表段的元數(shù)據(jù)組成一棵3叉平衡樹。該樹節(jié)點(diǎn)的結(jié)構(gòu)如下：

3.4.2 表段定位查詢算法

AS層將查詢請求發(fā)送給DS層，DS層將處理來自AS層的查詢。下面的算法是表段定位查詢算法，它是一個(gè)迭代算法。該算法是有3個(gè)參數(shù)，ParentTree是對某些表的元數(shù)據(jù)樹，KeyMin和KeyMax定義查詢的鍵范圍。

4 應(yīng)用服務(wù)器（AS）層

AS層是云關(guān)系型數(shù)據(jù)庫平臺的核心層，它接受來自O(shè)SS的請求和檢索來自DN層的數(shù)據(jù)并返回到OSS。AS層從DN層中檢索數(shù)據(jù)，需要在DS層中查詢一些元數(shù)據(jù)。

所有從OSS發(fā)送的請求可以分為3種：表定義時(shí)發(fā)送的存儲請求；數(shù)據(jù)操作請求，包括添加、刪除和更新；數(shù)據(jù)查詢請求。

4.1 表定義算法

當(dāng)一個(gè)新類的對象存儲請求通過應(yīng)用程序發(fā)送時(shí)，SDK將生產(chǎn)一個(gè)表定義的請求。該表定義的請求將處理下面的算法。

4.2 數(shù)據(jù)添加、刪除、更新算法

當(dāng)某個(gè)類通過應(yīng)用程序發(fā)送數(shù)據(jù)添加、刪除、更新請求時(shí)，SDK將生成一個(gè)數(shù)據(jù)操作的請求。數(shù)據(jù)操作的請求將由AS層處理，算法如下：

由于同一個(gè)對象實(shí)例的數(shù)據(jù)可能存儲在多個(gè)RS中，所以，刪除或更新數(shù)據(jù)可能需要多個(gè)RS執(zhí)行。該Calculate－CorrelativeRS函數(shù)計(jì)算的RS，都需要執(zhí)行刪除、更新操作。其計(jì)算原理是基于where－clause和從DS層返回的KeyRange。

4.3 數(shù)據(jù)查詢算法

當(dāng)數(shù)據(jù)發(fā)送查詢請求的應(yīng)用，SDK將生成一個(gè)數(shù)據(jù)查詢請求。由于同一個(gè)對象實(shí)例的數(shù)據(jù)是有可能分布在多個(gè)DN上，因此AS層需要從多個(gè)DN上查詢數(shù)據(jù)，獲取結(jié)果。（算法在此省略。）

數(shù)據(jù)查詢算法需要調(diào)用函數(shù)CalculateCorrelativeRS來獲得CorrelativeRSList，并傳送查詢腳本到每一個(gè)相關(guān)RS以獲得所有的數(shù)據(jù)。因?yàn)樵谙嗤琑S里，DN的數(shù)據(jù)是相同的，這樣AS只需要選擇一個(gè)RS中的一個(gè)DN檢索數(shù)據(jù)即可，前提是該DN必須可用。

5 數(shù)據(jù)節(jié)點(diǎn)（DN）層

DN層的主要功能包括以下內(nèi)容：①存儲數(shù)據(jù)和處理數(shù)據(jù)的操作。②DN的管理。③DN的自動故障切換。

5.1 DN的構(gòu)成

DN是由DN的處理程序（Handler）和數(shù)據(jù)庫實(shí)例（Database Instance）組成。DN的處理程序負(fù)責(zé)DN的管理，并通過心跳協(xié)議將自身的狀態(tài)報(bào)告給DS層。數(shù)據(jù)庫實(shí)例用來存儲數(shù)據(jù)和處理數(shù)據(jù)操作的請求。DN可以是物理機(jī)或虛擬機(jī)。在云計(jì)算環(huán)境下，虛擬機(jī)是一個(gè)更好的選擇。數(shù)據(jù)庫實(shí)例是獨(dú)立的關(guān)系型數(shù)據(jù)庫產(chǎn)品，它可以是所有標(biāo)準(zhǔn)的關(guān)系型數(shù)據(jù)庫，例如MySQL、PostgreSQL或其它。

5.2 節(jié)點(diǎn)組（NG）和冗余集（RS）

DN層可以擴(kuò)展到數(shù)百個(gè)DN來支持巨大的可擴(kuò)展性。管理數(shù)以百計(jì)的DN是非常復(fù)雜的，為了簡化管理，所有的DN將被分成不同的NG，每個(gè)NG都由幾個(gè)RS組成。

為了提高數(shù)據(jù)保護(hù)級別，每個(gè)RS有3個(gè)DN，這3個(gè)DN存儲相同的數(shù)據(jù)。表段被寫入這3個(gè)鏡像的DN后，表段只從一個(gè)關(guān)鍵節(jié)點(diǎn)中讀取。另外兩個(gè)DN被命名為該表段的備用節(jié)點(diǎn)。同一個(gè)冗余集中的3個(gè)DN都是活躍的工作模式。不同的表段有不同的關(guān)鍵節(jié)點(diǎn)。如圖6所示，DN 1是表段1的關(guān)鍵節(jié)點(diǎn)，DN 2是表段2的關(guān)鍵節(jié)點(diǎn)，DN 3是表段3的關(guān)鍵節(jié)點(diǎn)。

圖6 冗余集結(jié)構(gòu)

5.3 DN故障轉(zhuǎn)移機(jī)制

通常情況下，備用節(jié)點(diǎn)處在備用狀態(tài)。當(dāng)一個(gè)數(shù)據(jù)節(jié)點(diǎn)失敗時(shí)，一個(gè)備用節(jié)點(diǎn)用來取代失敗的數(shù)據(jù)節(jié)點(diǎn)。在DS層的SN將控制故障轉(zhuǎn)移過程，并要求MN更新元數(shù)據(jù)。

6 性能分析

本文設(shè)計(jì)了一個(gè)模擬系統(tǒng)，以測試該可擴(kuò)展性云關(guān)系型數(shù)據(jù)庫的性能。模擬系統(tǒng)主要參數(shù)見表1。測試場景模擬的應(yīng)用的數(shù)量從10增加到100，數(shù)據(jù)量從2TB增加到20TB的情況。

表1 模擬系統(tǒng)的主要參數(shù)

為了驗(yàn)證本文提出的云關(guān)系型數(shù)據(jù)庫的有效性，收集了響應(yīng)時(shí)間和數(shù)據(jù)吞吐率。在圖7中，對比了從20個(gè)應(yīng)用到200個(gè)應(yīng)用的數(shù)據(jù)操作時(shí)間開銷。X軸代表應(yīng)用的數(shù)目，實(shí)驗(yàn)結(jié)果表明，隨著應(yīng)用的增加，云關(guān)系型數(shù)據(jù)庫的響應(yīng)時(shí)間保持基本穩(wěn)定。在圖8中，對比了云關(guān)系型數(shù)據(jù)庫的數(shù)據(jù)請求處理，請求數(shù)目是從20到200。X軸代表的應(yīng)用的數(shù)目，實(shí)驗(yàn)結(jié)果表明，隨著應(yīng)用數(shù)量的增加，云關(guān)系型數(shù)據(jù)庫的整體數(shù)據(jù)吞吐率呈線性增長。

7 結(jié)束語

本文提出了一種云關(guān)系型數(shù)據(jù)庫平臺的架構(gòu)，它解決了當(dāng)前云數(shù)據(jù)庫不能提供基于標(biāo)準(zhǔn)Web Service協(xié)議的云關(guān)系型數(shù)據(jù)庫服務(wù)和簡單通用的API，且當(dāng)用戶使用這些云數(shù)據(jù)庫的時(shí)候，他們必須對應(yīng)用做大量的修改的問題。它支持多語言開發(fā)的SDK機(jī)制，此機(jī)制提高了云關(guān)系型數(shù)據(jù)庫的易用性，本文對SDK機(jī)制進(jìn)行了詳細(xì)說明。同時(shí)，對數(shù)據(jù)的垂直和水平分布機(jī)制和算法進(jìn)行了描述。此外，也描述了云關(guān)系型數(shù)據(jù)庫的可靠性，包括數(shù)據(jù)存儲管理和各種保護(hù)機(jī)制。通過仿真性能測試，結(jié)果表明，在大海量數(shù)據(jù)量下，此云關(guān)系型數(shù)據(jù)庫具有非常良好的快速響應(yīng)時(shí)間和巨大的數(shù)據(jù)吞吐率，并能提供呈線性增長的數(shù)據(jù)吞吐能力。

［1］ZHANG Longli.Cloud storage technology［J］.Telecommunications and Science，2010（S1）：71－74（in Chinese）.［張龍立.云存儲技術(shù)探討［J］.電信科學(xué)，2010（S1）：71－74.］

［2］GAO Jianxiu.Research on the application of cloud storage in digital preservation［J］.New Technology of Library and Information Service，2010（6）：1－6（in Chinese）.［高建秀.云存儲在數(shù)字資源長期保存中的應(yīng)用探討［J］.現(xiàn)代圖書情報(bào)技術(shù)，2010（6）：1－6.］

［3］HUANG Yongfeng.Encrypted storage and its retrieval in cloud storage applications［J］.ZTE Communitions，2010，16（4）：33－35（in Chinese）.［黃永峰.云存儲應(yīng)用中的加密存儲及其檢索技術(shù)［J］.中興通信技術(shù)，2010，16（4）：33－35.］

［4］ZHOU Ping.Cloud computing and cloud storage management technology［J］.Journal of Shanghai University of Electric Power，2010，26（5）：498－501（in Chinese）.［周平.云計(jì)算及云存儲的管理技術(shù)［J］.上海電力學(xué)院學(xué)報(bào)，2010，26（5）：498－501.］

［5］WANG Jiajun.Cloud computing technology development analysis and applications discussion［J］.Computer Engineering and Design，2010，31（20）：4404－4408（in Chinese）.［王佳雋.云計(jì)算技術(shù)發(fā)展分析及其應(yīng)用探討［J］.計(jì)算機(jī)工程與設(shè)計(jì)，2010，31（20）：4404－4408.］

［6］YE Yu.Using SimpleDB for distributed data cloud storage［J］.Journal of Taizhou Polytechnic College，2010，10（1）：9－10（in Chinese）.［葉鈺.基于SimpleDB進(jìn)行分布式數(shù)據(jù)云存儲［J］.泰州職業(yè)技術(shù)學(xué)院學(xué)報(bào)，2010，10（1）：9－10.］

［7］Michael Cafarella，Edward Chang， Andrew Fikes.Data management projects at Google［J］.ACM SIGMOD Record，2008，37（1）：34－38.

［8］HDFS.The hadoop distributed file system：Architecture and design［EB/OL］.［2009－08－26］.http：//hadoop.apache.org/common/docs/hdfs＿design.html.

［9］Dornemann T，Juhnke E，F(xiàn)reisleben B.On－demand resource provisioning for BPEL workflows using amazon＇s elastic computer cloud［C］.Proc of the 9th IEEE/ACM Int Symposium on Cluster Computing and the Grid，2009：140－147.

［10］SHI Liping.Analysis of cloud storage technology based on web［J］.Modern Computer，2010，27（3）：117－119（in Chinese）.［石利平.淺析基于Web的云存儲技術(shù)［J］.現(xiàn)代計(jì)算機(jī)，2010，27（3）：117－119.］

［11］LI Ting.Research on cloud computing resource management［J］.Computer ＆Telecommunication，2010，16（1）：62－64（in Chinese）.［李婷.云計(jì)算的資源管理方法研究［J］.電腦與電信，2010，16（1）：62－64.］

［12］LI Yumin.Cloud computing environment data storage［J］.Computer Knowledge and Technology，2010，6（5）：1032－1034（in Chinese）.［李煜民.云計(jì)算環(huán)境下的數(shù)據(jù)存儲［J］.電腦知識與技術(shù)，2010，6（5）：1032－1034.］