云数据库研究

云计算与云数据库背景

云计算（cloud computing）是 IT 技术发展的最新趋势，正受到业界和学术界的广泛关注。云计算是在分布式处理、并行处理和网格计算等技术的基础上发展起来的，是一种新兴的共享基础架构的方法。它可以自我维护和管理庞大的虚拟计算资源（包括计算服务器、存储服务器、宽带资源等等），从而提供各种 IT 服务。用户在使用云计算提供的服务时按需付费，这不仅降低了使用门槛，也极大地节省了开销。

随着云计算技术的不断升温，它对各个技术领域的影响开始显现,其中比较典型的包括数据库领域。截止到 2011 年 6 月，传统的数据库厂商，比如 Oracle、Teradata、IBM、Microsoft 等，都已经推出了基于云计算环境的相关数据库产品。原来没有从事数据库产品开发的知名大公司，比如 Amazon 和 Google 等，也发布了 SimpleDB 和 BigTable 等产品。

云数据库概述

云数据库是在 SaaS（software-as-a-service：软件即服务）成为应用趋势的大背景下发展起来的云计算技术，它极大地增强了数据库的存储能力，消除了人员、硬件、软件的重复配置，让软、硬件升级变得更加容易，同时也虚拟化了许多后端功能。云数据库具有高可扩展性、高可用性、采用多租形式和支持资源有效分发等特点。

如图 $1$ 所示，在云数据库应用中，客户端不需要了解云数据库的底层细节，所有的底层硬件都已经被虚拟化，对客户端而言是透明的。它就像在使用一个运行在单一服务器上的数据库一样，非常方便、容易，同时又可以获得理论上近乎无限的存储和处理能力。

图 1    云数据库应用示意图

云数据库与传统分布式数据库

分布式数据库是计算机网络环境中各场地或节点上的数据库的逻辑集合。逻辑上它们属于同一系统，而物理上它们分散在用计算机网络连接的多个节点，并统一由一个分布式数据库管理系统管理。

分布式数据库已经存在很多年，它可以用来管理大量的分布存储的数据，并且通常采用非共享的体系架构。云数据库和传统的分布式数据库具有相似之处，比如，都把数据存放到不同的节点上。但是，分布式数据库在可扩展性方面是无法与云数据库相比的。由于需要考虑数据同步和分区失败等开销，前者随着节点的增加会导致性能快速下降。而后者则具有很好的可扩展性，因为后者在设计时就已经避免了许多会影响到可扩展性的因素，比如采用更加简单的数据模型、对元数据和应用数据进行分离以及放松对一致性的要求等等。另外，在使用方式上，云数据库也不同于传统的分布式数据库。云数据库通常采用多租户模式，即多个租户共用一个实例，租户的数据既有隔离又有共享，从而解决数据存储的问题，同时也降低了用户使用数据库的成本。

云数据库产品

云数据库供应商主要分为 3 类：

• 传统的数据库厂商：Teradata，Oracle，IBM DB2 和 Microsoft SQL Server
• 涉足数据库市场的云供应商：Amazon，Google 和 Yahoo
• 新兴小公司：Vertica，LongJump 和 EnterpriseDB

常见的云数据库产品如表 $1$ 所示。

表 1    云数据库产品

Amazon 是云数据库市场的先行者。Amazon 除了提供著名的 S3 存储服务和 EC2 计算服务以外，还提供基于云的数据库服务Dynamo。Dynamo 采用“键/值”存储，其所存储的数据是非结构化数据，不识别任何结构化数据，需要用户自己完成对值的解析。Dynamo 系统中的键（key）不是以字符串的方式进行存储，而是采用 mds_key（通过 md5 算法转换后得到）的方式进行存储，因此，它只能根据 key 去访问，不支持查询。SimpleDB 是 Amazon 公司开发的一个可供查询的分布数据存储系统，它是 Dynamo “键/值”存储的补充和丰富。顾名思义，SimpleDB 的目的是作为一个简单的数据库来使用，它的存储元素（属性和值）是由一个 id 字段来确定行的位置。

Google BigTable 是一种满足弱一致性要求的大规模数据库系统。Google 设计 BigTable 的目的，是为了处理 Google 内部大量的格式化及半格式化数据。目前，许多 Google 应用都是建立在 BigTable 上的，比如 Web 索引、Google Earth、Google Finance、Google Maps 和 Search History。BigTable 是构建在其他几个 Google 基础设施之上的：首先，BigTable 使用了分布式 Google 文件系统 GFS（Google file system）来存储日志和数据文件；其次，BigTable 依赖一个高可用的、持久性的分布式锁服务 Chubby；再次，BigTable 依赖一个簇管理系统来调度作业、在共享机器上调度资源、处理机器失败和监督机器状态。

云数据库领域的研究问题

对于学术界而言，要想在云数据库中提供类似于现有 DBMS 的丰富功能，比如查询、索引和事务处理，仍然有许多亟待解决的问题。云数据库领域中的研究问题主要包括：云数据库中数据模型设计、编程模型、服务器体系架构设计、事务一致性、基于云数据库的容灾和 SLA（service level agreement）监控、云数据的访问控制和授权管理、云应用数据访问体系的调优、云数据生命周期管理、云数据库与本地数据库的协同和联邦设计、测试基准等。

云数据库的设计可以采用不同的数据模型，不同的数据模型可以满足不用应用类型的需求，主要包括：键/值模型和关系模型。

BigTable 和它的同类开源产品 HBase，提供了一个不同于以往的简单的、动态的、非关系型的数据模型。BigTable 采用了键/值数据模型。在 BigTable 中，包括行列以及相应的时间戳在内的所有数据都存放在表格的单元里。BigTable 的内容按照行来划分,多个行组成一个小表（Tablet），保存到某一个服务器节点中。这就意味着，每个 Tablet 包含了位于某个区间内的所有数据。对于 BigTable 而言，一个数据簇中存储了许多表，其中每个表都是一个 Tablet 集合。在最初阶段，每个表只包含 1 个 Tablet。随着表的增长，它会被自动分解成许多 Tablet，每个 Tablet 默认尺寸大约是 100MB ~ 200MB。BigTable 使用一个类似于 B+ 树的 3 层架构来存储 Tablet 位置信息。由于 BigTable 采用了键/值数据模型，因此不存在表间的联接操作，这也使得数据分区操作相对简单，只需要根据键的区间来划分即可。

微软的 SQL Azure 云数据库采用了关系模型，它的数据分区方式和 BigTable 有些不同。关系型云数据库的数据模型涉及行组和表组等相关概。一个表是一个逻辑关系，它包含一个分区键，用来对表进行分区。具有相同分区键的多个表的集合称为表组。在表组中，具有相同分区键值的多个行的集合称为行组。一个行组中包含的行总是被分配到同一个数据节点上。每个表组会包含多个行组，这些行组会被分配到不同的数据节点上。一个数据分区包含了多个行组.因此，每个数据节点都存储了位于某个分区键值区间内的所有行。

图 $2$ 所示为云数据库的数据访问方法。当客户端请求数据时，它首先向管理器请求一份分区映射图，管理器向客户端发送分区映射图；客户端收到以后，在图中进行搜寻，根据键值找到自己所需数据的存储位置；然后，客户端到指定的数据节点请求数据；最后，由该数据节点把数据返回给客户端。实际上，为了改进性能，同时也为了避免管理器的性能瓶颈，通常会在客户端缓存常用的分区映射图。这样，客户端在很多情况下不必与管理器交互就可以直接访问相应的数据节点。

图 2    云数据库中的数据访问方法

云数据库的安全性也是影响其普及与应用的关键因素。云数据库虽然提供了对海量数据的存储，但同时也对数据的保密性和访问控制等安全问题提出了新的挑战：一方面，一些敏感的数据，比如企业财务数据、医疗机构的病例档案、政府机构的文件等，必须经过加密才能放到云数据库中；另一方面，针对众多的用户，必须设置不同的访问控制级别，保证不同层次的用户只能授权访问限定范围内的数据。

云数据管理的新数据模型

传统关系型数据库系统在处理超大规模数据的存储 、高并发的数据访问、半结构化和非结构化数据存储等新型应用时已经出现瓶颈。而关系数据模型用关系表示实体及实体之间的联系，以关系代数为基础，数据独立性强，并且其非过程化的数据存取方式大大降低了数据库编程的难度。非关系数据模型有更好的可扩展性，很好地解决了多机并行处理的瓶颈，存储容量也不再受限，并且能更好地存储各种复杂的数据类型，查询效率也更高。

基于以上的考虑，可以从数据的具体特性出发，结合关系数据模型与非关系数据模型，建立一种新的云数据模型，用新模型中的关系部分处理复杂的事务需求，非关系部分处理复杂的海量数据需求，具体来说就是对数据实体的切分。在传统的关系数据模型中，实体根据范式要求而被划分为不同的关系模式;然而在新模型中，可以根据实体的属性类型对实体再次进行划分，划分后的一个实体型由很多子实体组成，并且每个子实体要么属于关系型，要么属于非关系型，各个子实体的物理储存介质都是 shared-nothing 结构。此外，新模型在数据管理的对外接口上，保持已有的关系接口不变，新的功能封装在已有的关系接口中。在处理新的复杂的数据类型时，首先在实体模式的定义中标记数据的对应属性（用 Blob 做约束)，然后系统模型就会自动转换到对应的处理模块，例如当用户处理事务性较弱的大批量数据操作时，系统就会进行自动转换。新模型数据实体有低耦合、高内聚的特性，因此有很好的可扩展性;并且不限于存储基本的数据类型，做到了与结构化数据的关系模型的平滑过渡，有很好的可用性。图 $3$ 说明了一个实体型的划分。

图 3    实体划分

由于新模型要同时管理了小字段的结构化数据和大字段的非结构化数据，并且扩展了数据库管理系统中垂直分片的技术，所以总体上表现为层次结构的数据模型。新数据模型与传统的层次模型主要有以下几方面的不同：

• 整个数据实体只有两层，关系层和非关系层
• 关系层和非关系层均由表结构表示数据
• 关系表中的一个数据项和非关系表中的一个数据项是一一对应的
• 关系表和非关系表是 n:1 的关系，并且组成倒立的树形结构
• 关系层和非关系层的划分都是针对同一个实体型的数据，属于同一实体型的横向分层，不同与传统的不同实体型之间的纵向分层
• 由于横向分层的原因，在处理实体间的无论一对多，还是多对多都很方便，不需要建立冗余结点和虚拟结点，均封装在系统的关系层中，克服了纵向分层结构的弱点

在非关系层中，只有数据表存储了实际的大字段数据，包括其 key 及 value。其他都是索引表，二层索引表 Tablet 保存了数据表 Tablet 的地址信息以及其它元数据信息，二层索引表 Tablet 中每行记录对应一个数据表 Tablet。根索引表 Tablet 保存了二层索引表 Tablet 的地址信息以及其他元数据信息，根索引表 Tablet 中每条记录对应一个二层索引表 Tablet。数据寻址时，涉及到分散的多台服务器的磁盘查询，为了降低磁盘读取次数，差用变形的 B+ 结构存储索引表和数据表，每个结点即为一个 Tablet。变形 B+ 树的很多操作与 3 阶 B+ 树一致，与传统 B+ 树有以下几点不同：

• 简化了第一-层根索引结点和第二层索引结点的操作，根索引结点不分裂，永远只有一个
• 数据结点的合并和分裂不由B十树的最小度数或者阶数决定，而是根据可自定义的结点大小与其文件大小而定
• 无论数据插入还是删除，都在数据结点进行，树永远都由两层索引结点和一层数据结点组成
• 索引结点（包括根索引结点）的子树个数等于索引结点的记录项数目，不由 B+ 树的最小度数或者阶数决定
• 索引结点的记录项数目等于可自定义的节点大小除以每行记录大小

通过与 HBase 作对比，对大字段的数据进行连续写入和读取，作者得出了如图 $4$ 试验结果。

图 4    数据写入(左)与数据读取(右)对比

可以看出新模型与 HBase 相比，在大字段数据写入时，效率相当。因为新模型的 Blob 数据写入语法语义较简单，与 HBase 相似，都是 key-value 操作，而 Blob 数据索引在关系层的写人数据量与 Blob 本身相比较小。系统每写入 1MB 的数据（一行）大概是 0.36 秒，吞吐量为 23Mb/s，当写入 10000 行时，数据量达到 30GB，在写入过程中会发生很多次的 tablet 的拆分与合并。在大字段数据读取时，效率稍低。因为系统首先会分析查询条件，而且有相当一部分 Blob 数据的复杂查询都会涉及到关系层中索引的操作。系统每读取 1MB 的数据（一行）大概是 0.1 秒，吞吐量为 80Mb/s。

从数据库到云计算：亚马逊的大数据

云计算有 SaaS、 PaaS、laaS 三层，亚马逊着力的是 IaaS 的底层建设。亚马逊云计算解决方案和网络服务部高级经理在接受媒体采访时表示，在网络互联的需求之上，直接就是亚马逊的最底层的IT基础架构 AWS，包括计算、存储、内容分发等；在 AWS 基础上，用户才可以构建自己的应用层，这些应用层包括构建数据库、应用服务器；最上层是应用软件。亚马逊已经不是一个云服务提供商，而是云基础设施供应商。

亚马逊的 IaaS 以弹性计算云 EC2、存储云 S3 为主。分析师和投资者目前主要通过 AWS 提供的 S3 服务中存储的数据量来了解 AWS 的发展情况，S3 主要销售基于云计算系统的存储空间。亚马逊的数据显示，2011 年亚马逊云服务 S3 的对象量翻了 3 番，增加了 5000 亿对象，相当于每个季度增加 1250 亿对象。据美国调查公司 451 Group 的报告，AWS 已经占据了美国 59% 的基础设施及服务（IaaS）市场份额，领先优势相当明显。

AWS 提供的另一个主要服务为 EC2，该服务提供基于云计算系统的额外计算能力。根据云计算专家盖伊·罗森的调查，2011 年 1 月，全球排名前 50 万的网站中有 3674 家网站使用该服务，较去年同期增长了近 50%。这使得亚马逊超过 Rackspace Hosting，成为全球最大的云计算服务提供商。