陈平平，谭定英，刘秀峰

（广州中医药大学 信息技术学院，广东 广州510006）

0 引 言

如何高效存储和管理企业日渐增长的庞大数据成为数据库服务一个挑战性问题。为了适应这Z种增长需求，云数据库服务产生了［1－2］。

到目前为止，Amazon的SimpleDB，Google的Bigtable和雅虎的HBase是公开的云数据库服务［3－4］。但是，它们都不是基于关系型数据库的［5－6］。因此，当用户想将关系数据库的应用迁移到 SimpleDB 时，必须做大量的修改［7－8］。Amazon的RDS是一种云关系型数据库，它提供了一种容易使用的云关系型数据库服务［9－10］。但它的可扩展性有限，目前只支持单实例［11－12］。

1 架构概述

可扩展的云关系型数据库平台架构如图1所示，平台分为四层。第一层为API层，它向第三方的应用程序提供可供调用的服务，包括SDK和开放式存储服务（open storage services，OSS）。第二层为应用服务器（app server，AS）层，它是核心层，向上提供数据操作服务供API层调用。第三层为分布服务器（distribution server，DS）层，提供数据分布策略。第四层为数据节点（data node，DN）层，提供了可扩展性的数据物理存储，在DN层，多个DN成组成冗余集（redundant set，RS），多个RS组成节点组（node group，NG）。

图1 可扩展云关系型数据平台架构

2 API层

API层是可扩展的云关系型数据库平台的服务层，包括SDK和OSS。API层的内部结构如图2所示。

图2 API层架构

2.1 SDK机制

SDK远程调用OSS，并提供简便的语言相关的开发接口。SDK提供面向对象的接口以屏蔽的调用远程Web服务的复杂性。

在架构中，用户的数据存储在关系数据库管理系统中，因此SDK必须解决面向对象和关系型数据的映射问题。SDK根据应用程序的对象类，自动生成关系型表结构并建立相应的索引，并为有引用关系的对象类之间生成外键关联。

此外，SDK提供平台的模拟器。在开发阶段，程序员可以在没有连接平台时测试它们的应用程序，因为在SDK中有一些本地的存储服务，能够为应用程序提供与实际的云关系型数据库服务相同的接口。

2.2 OSS机制

OSS是一系列通用的Web服务，可供各种多种不同语言的SDK调用。OSS是对AS层的封装。OSS包括3种服务：安全服务，数据定义服务和数据操作服务。

2.3 安全策略

API层还负责安全策略的管理，包括用户认证与权限管理。所有的用户认证与权限管理都是隐式的。当应用程序正式运行时，平台为每个应用程序生成相应的许可，SDK向平台发送请求时会自动调用属于自己的许可。这样，每个应用程序只操作属于自己的数据，从而隔离不同应用程序之间的影响。

3 分布服务器（DS）层

图3是DS层的架构，它包括下面的特征：

·DS层由一个主节点（master node，MN）和若干个从节点（slave node，SN）组成。每个MN和SN有两个单元：元节点和节点跟踪器。

·元节点是用来维持分布的元数据和处理来自AS层的查询。

·SN上的节点跟踪器是用来处理DS层和DN层之间的心跳协议。

·MN上的节点跟踪器负责汇总所有的DN状态，它会报告MN上的元节点状态的改变。

·所有MN和SN上的元节点是同步的。

图3 分布服务（DS）器层架构

3.1 DS层的构成

3.1.1 主从机制

MN和SN运行相同的程序，但运行不同的程序分支。为了提高性能，MN有两个线程，元节点线程接受来自AS层的查询（AppID，ObjectID和Object的关键字），并将结果发回给AS层，返回结果包含NGid、RSid和DNid；节点跟踪线程接受来自SN收集的DN状态改变信息并更新元数据。SN有两个线程，元节点线程接受来自MN的元数据更新要求并更新元数据，节点跟踪线程通过心跳协议与DN通信，监控DN的状态并控制DN的故障转移过程。

3.1.2 MN故障切换流程

当MN出现故障时，在所有的SN中必须选出一个新的MN。首先，所有的SN通过Status＿Discovery消息将自己的状态广播给其他的SN，Status＿Discovery消息包括CPU利用率和内存利用率。然后工作负载最少的SN的希望成为MN，它逐渐地通过广播Election＿Request信息告诉给其它的SN，其它的SN会通过Election＿ACK信息响应确认。最后，后备的MN会将其从属的角色转换为主角色并重新启动。此后，MN的故障转移过程完成。

3.1.3 SN的负载均衡

SN上的节点跟踪器主要负责监控DN的状态，并处理DS层和DN层之间的心跳协议。为了让所有的SN实现负载均衡，DN将均匀的分配给不同的SN。负载均衡的算法可以是轮询算法（Round Robin）或者最小效应时间优先算法（least response time）。

3.2 数据结构

数据结构如图4所示。AppID用来识别不同的应用，ObjectID是用来识别不同的表，KeyMin和KeyMax是用于定义表的段边界，HostGroupID、RedundantSetID和PrimaryNodeID是用来标识DN的表段存储位置。NodeID是DN的标识，每个NodeID是独一无二的。NetworkLinkProvider是用来标识不同的网络供应商。不同的DN可以跨越许多不同的数据中心。DN的状态可以是New、Ready、Failed和Recovering。ResourceRatio是指CPU和内存的利用率。

图4 DS层的数据结构

3.3 水平分布策略

水平分布策略是为了将不同的表分布到不同的NG、RS和DN上。当一个新表被创建时，MN会选择一个DN存储这个表的第一个段。为了让不同的DN工作负载平衡，许多因素都应该综合考虑。首先，要选择一个NG，这个NG的应该有数量最少的表和最多的空闲空间。其次，要选择一个RS，这个RS在当前NG内，应该有数量最少的表和最多的空闲空间。最后，选择一个主DN，这个DN在当前RS内部处理的请求最少。

3.4 垂直分布机制

3.4.1 表段定义

表通过主键分裂成表段，如图5所示，每段是256M字节，每段的所有数据将会存储到同一个DN。当新的记录插入到表，一个段可以分成两个部分。当记录从表中删除后，两个部分可能会合并成一个段。

图5 表段分布

表段元数据是由MN维护，并且与所有其他SN同步。为了获得最佳的查询性能，每个表段的元数据组成一棵3叉平衡树。该树节点的结构如下：

3.4.2 表段定位查询算法

AS层将查询请求发送给DS层，DS层将处理来自AS层的查询。下面的算法是表段定位查询算法，它是一个迭代算法。该算法是有3个参数，ParentTree是对某些表的元数据树，KeyMin和KeyMax定义查询的键范围。

4 应用服务器（AS）层

AS层是云关系型数据库平台的核心层，它接受来自OSS的请求和检索来自DN层的数据并返回到OSS。AS层从DN层中检索数据，需要在DS层中查询一些元数据。

所有从OSS发送的请求可以分为3种：表定义时发送的存储请求；数据操作请求，包括添加、删除和更新；数据查询请求。

4.1 表定义算法

当一个新类的对象存储请求通过应用程序发送时，SDK将生产一个表定义的请求。该表定义的请求将处理下面的算法。

4.2 数据添加、删除、更新算法

当某个类通过应用程序发送数据添加、删除、更新请求时，SDK将生成一个数据操作的请求。数据操作的请求将由AS层处理，算法如下：

由于同一个对象实例的数据可能存储在多个RS中，所以，删除或更新数据可能需要多个RS执行。该Calculate－CorrelativeRS函数计算的RS，都需要执行删除、更新操作。其计算原理是基于where－clause和从DS层返回的KeyRange。

4.3 数据查询算法

当数据发送查询请求的应用，SDK将生成一个数据查询请求。由于同一个对象实例的数据是有可能分布在多个DN上，因此AS层需要从多个DN上查询数据，获取结果。（算法在此省略。）

数据查询算法需要调用函数CalculateCorrelativeRS来获得CorrelativeRSList，并传送查询脚本到每一个相关RS以获得所有的数据。因为在相同RS里，DN的数据是相同的，这样AS只需要选择一个RS中的一个DN检索数据即可，前提是该DN必须可用。

5 数据节点（DN）层

DN层的主要功能包括以下内容：①存储数据和处理数据的操作。②DN的管理。③DN的自动故障切换。

5.1 DN的构成

DN是由DN的处理程序（Handler）和数据库实例（Database Instance）组成。DN的处理程序负责DN的管理，并通过心跳协议将自身的状态报告给DS层。数据库实例用来存储数据和处理数据操作的请求。DN可以是物理机或虚拟机。在云计算环境下，虚拟机是一个更好的选择。数据库实例是独立的关系型数据库产品，它可以是所有标准的关系型数据库，例如MySQL、PostgreSQL或其它。

5.2 节点组（NG）和冗余集（RS）

DN层可以扩展到数百个DN来支持巨大的可扩展性。管理数以百计的DN是非常复杂的，为了简化管理，所有的DN将被分成不同的NG，每个NG都由几个RS组成。

为了提高数据保护级别，每个RS有3个DN，这3个DN存储相同的数据。表段被写入这3个镜像的DN后，表段只从一个关键节点中读取。另外两个DN被命名为该表段的备用节点。同一个冗余集中的3个DN都是活跃的工作模式。不同的表段有不同的关键节点。如图6所示，DN 1是表段1的关键节点，DN 2是表段2的关键节点，DN 3是表段3的关键节点。

图6 冗余集结构

5.3 DN故障转移机制

通常情况下，备用节点处在备用状态。当一个数据节点失败时，一个备用节点用来取代失败的数据节点。在DS层的SN将控制故障转移过程，并要求MN更新元数据。

6 性能分析

本文设计了一个模拟系统，以测试该可扩展性云关系型数据库的性能。模拟系统主要参数见表1。测试场景模拟的应用的数量从10增加到100，数据量从2TB增加到20TB的情况。

表1 模拟系统的主要参数

为了验证本文提出的云关系型数据库的有效性，收集了响应时间和数据吞吐率。在图7中，对比了从20个应用到200个应用的数据操作时间开销。X轴代表应用的数目，实验结果表明，随着应用的增加，云关系型数据库的响应时间保持基本稳定。在图8中，对比了云关系型数据库的数据请求处理，请求数目是从20到200。X轴代表的应用的数目，实验结果表明，随着应用数量的增加，云关系型数据库的整体数据吞吐率呈线性增长。

7 结束语

本文提出了一种云关系型数据库平台的架构，它解决了当前云数据库不能提供基于标准Web Service协议的云关系型数据库服务和简单通用的API，且当用户使用这些云数据库的时候，他们必须对应用做大量的修改的问题。它支持多语言开发的SDK机制，此机制提高了云关系型数据库的易用性，本文对SDK机制进行了详细说明。同时，对数据的垂直和水平分布机制和算法进行了描述。此外，也描述了云关系型数据库的可靠性，包括数据存储管理和各种保护机制。通过仿真性能测试，结果表明，在大海量数据量下，此云关系型数据库具有非常良好的快速响应时间和巨大的数据吞吐率，并能提供呈线性增长的数据吞吐能力。

［1］ZHANG Longli.Cloud storage technology［J］.Telecommunications and Science，2010（S1）：71－74（in Chinese）.［张龙立.云存储技术探讨［J］.电信科学，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）.［高建秀.云存储在数字资源长期保存中的应用探讨［J］.现代图书情报技术，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）.［黄永峰.云存储应用中的加密存储及其检索技术［J］.中兴通信技术，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］.上海电力学院学报，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］.计算机工程与设计，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］.泰州职业技术学院学报，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，Freisleben 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的云存储技术［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］.电脑与电信，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］.电脑知识与技术，2010，6（5）：1032－1034.］