当前位置:文档之家› 云数据库研究

云数据库研究

云数据库研究
云数据库研究

软件学报ISSN 1000-9825, CODEN RUXUEW E-mail: jos@https://www.doczj.com/doc/9a13457946.html,

Journal of Software,2012,23(5):1148?1166 [doi: 10.3724/SP.J.1001.2012.04195] https://www.doczj.com/doc/9a13457946.html,

+86-10-62562563 ?中国科学院软件研究所版权所有. Tel/Fax:

?

云数据库研究

林子雨1, 赖永炫2+, 林琛1, 谢怡1, 邹权1

1(厦门大学计算机科学系,福建厦门 361005)

2(厦门大学软件学院,福建厦门 361005)

Research on Cloud Databases

LIN Zi-Yu1, LAI Yong-Xuan2+, LIN Chen1, XIE Yi1, ZOU Quan1

1(Department of Computer Science, Xiamen University, Xiamen 361005, China)

2(School of Software, Xiamen University, Xiamen 361005, China)

+ Corresponding author: E-mail: laiyx@https://www.doczj.com/doc/9a13457946.html,

Lin ZY, Lai YX, Lin C, Xie Y, Zou Q. Research on cloud databases. Journal of Software, 2012,23(5):

1148?1166. https://www.doczj.com/doc/9a13457946.html,/1000-9825/4195.htm

Abstract: With the recent development of cloud computing, the importance of cloud databases has been widely

acknowledged. Here, the features, influence and related products of cloud databases are first discussed. Then,

research issues of cloud databases are presented in detail, which include data model, architecture, consistency,

programming model, data security, performance optimization, benchmark, and so on. Finally, some future trends in

this area are discussed.

Key words: cloud computing; cloud database; key-value store; transaction consistency

摘要: 随着云计算的发展,云数据库的重要性和价值日益显现.介绍了云数据库的特性、影响、相关产品.详细讨

论了云数据库领域的研究问题,包括数据模型、系统体系架构、事务一致性、编程模型、数据安全、性能优化和测

试基准等.最后讨论了云数据库未来的研究方向.

关键词: 云计算;云数据库;键值存储;事务一致性

中图法分类号: TP311文献标识码: A

云计算(cloud computing)[1]是IT技术发展的最新趋势,正受到业界和学术界的广泛关注[2,3].云计算是在分

布式处理、并行处理和网格计算等技术的基础上发展起来的,是一种新兴的共享基础架构的方法.它可以自我

维护和管理庞大的虚拟计算资源(包括计算服务器、存储服务器、宽带资源等等),从而提供各种IT服务.用户

在使用云计算提供的服务时按需付费,这不仅降低了使用门槛,也极大地节省了开销.由于云计算存在着巨大的

潜在市场,Google,IBM,Microsoft,Amazon,Sun,HP,Yahoo,Oracle等国际知名大公司都已经涉足云计算.云计算也

开始在电信、金融等需要大规模并行处理的领域得到应用,比如中国移动研究院开发的云数据挖掘平台BC-

?基金项目: 厦门大学基础创新科研基金(中央高校基本科研业务费专项资金)(2011121049, 2010121066); 国家自然科学基金

(61001013, 61102136); 福建省自然科学基金(2011J05156, 2011J05158)

收稿时间:2011-06-21; 修改时间: 2011-09-02, 2011-10-17; 定稿时间: 2012-02-15; jos在线出版时间: 2012-02-27

CNKI网络优先出版: 2012-02-27 11:43, https://www.doczj.com/doc/9a13457946.html,/kcms/detail/11.2560.TP.20120227.1143.001.html

林子雨等:云数据库研究1149

PDM[4]和云数据库产品HugeTable[5].

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

迅速发展的云数据库市场极大地影响着数据库技术的未来发展方向,甚至出现了关系数据库是否已经没落的争议.与此同时,许多云数据库的相关问题开始被关注,比如云数据库的体系架构、数据模型、事务一致性、数据安全和性能优化等等.由于云数据库是一个比较新的研究领域,目前还很少有相关研究对这个领域进行全面概括的介绍.因此,本文将结合我们在过去两年中已经进行的大量调研成果,对云数据库及其相关研究进行综合阐述.

本文第1节介绍云数据库,包括云数据库的特性、影响、云数据库与传统分布式数据库的区别.第2节介绍相关的云数据库产品.第3节阐述云数据库领域的研究问题.第4节是本文的结论,并给出未来研究展望.

1 云数据库概述

云数据库是在SaaS(software-as-a-service:软件即服务)成为应用趋势的大背景下发展起来的云计算技术,它极大地增强了数据库的存储能力,消除了人员、硬件、软件的重复配置,让软、硬件升级变得更加容易,同时也虚拟化了许多后端功能.云数据库具有高可扩展性、高可用性、采用多租形式和支持资源有效分发等特点.可以说,云数据库是数据库技术的未来发展方向.目前,对于云数据库的概念界定不尽相同,本文采用的云数据库定义是:云数据库是部署和虚拟化在云计算环境中的数据库[12].

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

客户端

云数据库数据节点云数据库管理器

物理磁盘

Fig.1 A diagram showing the application of cloud databases

图1 云数据库应用示意图

1.1 云数据库的特性

云数据库具有以下特性:

(1) 动态可扩展:理论上,云数据库具有无限可扩展性,可以满足不断增加的数据存储需求.在面对不断变化的条件时,云数据库可以表现出很好的弹性.例如,对于一个从事产品零售的电子商务公司,会存在季节性或突发性的产品需求变化;或者对于类似Animoto的网络社区站点,可能会经历一个指数级的增长阶段.这时,就可以分配额外的数据库存储资源来处理增加的需求,这个过程只需要几分钟.一旦需求过去以后,就可以立即释放这些资源.

(2) 高可用性:不存在单点失效问题.如果一个节点失效了,剩余的节点就会接管未完成的事务.而且在云数

1150 Journal of Software软件学报 V ol.23, No.5, May 2012

据库中,数据通常是复制的,在地理上也是分布的.诸如Google,Amazon和IBM等大型云计算供应商具有分布在世界范围内的数据中心,通过在不同地理区间内进行数据复制,可以提供高水平的容错能力.例如,Amazon SimpleDB会在不同的区间内进行数据复制,因此,即使整个区域内的云设施发生失效,也能保证数据继续可用.

(3) 较低的使用代价:通常采用多租户(multi-tenancy)的形式,这种共享资源的形式对于用户而言可以节省开销;而且用户采用按需付费的方式使用云计算环境中的各种软、硬件资源,不会产生不必要的资源浪费.另外,云数据库底层存储通常采用大量廉价的商业服务器,这也大幅度降低了用户开销.

(4) 易用性:使用云数据库的用户不必控制运行原始数据库的机器,也不必了解它身在何处.用户只需要一个有效地链接字符串就可以开始使用云数据库.

(5) 大规模并行处理:支持几乎实时的面向用户的应用、科学应用和新类型的商务解决方案.

1.2 云数据库是海量存储需求的必然选择

云数据库在当前数据爆炸的时代具有广阔的应用前景.根据IDC的研究报告,在未来的5年中,企业对结构化数据的存储需求会每年增加20%左右,而对非结构化数据的存储需求将会每年增加60%左右.在小规模应用的情况下,系统负载的变化可以由系统空闲的多余资源来处理;但是在大规模应用的情况下,不仅存在海量的数据存储需求,而且应用对资源的需求也是动态变化的,这意味着大量虚拟机器的增加或减少.对于这种情形,传统的关系数据库已经无法满足要求,云数据库成为必然的选择.换句话说,海量存储催生了云数据库.

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

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

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

1.4 云数据库的影响

云数据库的影响主要体现在以下几个方面:

(1) 极大地改变企业管理数据的方式.Forrester Research分析师Yuhanna指出,18%的企业正在把目光投向云数据库.对于中小企业而言,云数据库可以允许他们在Web上快速搭建各类数据库应用,越来越多的本地数据和服务将逐渐被转移到云中.企业用户在任意地点通过简单的终端设备,就可以对企业数据进行全面的管理.此外,云数据库可以很好地支持企业开展一些短期项目,降低开销,而不需要企业为某个项目单独建立昂贵的数据中心.但是,云数据库的成熟仍然需要一段时间.中小企业会更多地采用云数据库产品,但是对于大企业而言,云数据库并非首选,因为大企业通常自己建造数据中心.

(2) 催生新一代的数据库技术.IDC的数据库分析师Olofson认为,云模型提供了无限的处理能力以及大量的RAM,因此,云模型将会极大地改变数据库的设计方式,将会出现第三代数据库技术.第一代是20世纪70年代的早期关系数据库,第二代是20世纪80年代~90年代的更加先进的关系模型.第三代的数据库技术,要求数据库能够灵活处理各种类型的数据,而不是强制让数据去适应预先定制的数据结构.事实上,从目前云数据库产品中的数据模型设计方式来看,已经有些产品(比如SimpleDB,Hbase,Dynamo,BigTable)放弃传统的行存储方式,而采用键/值存储,从而可以在分布式的云环境中获得更好的性能.可以预期的是,云数据库将会吸引越来越多的学术界的目光,该领域的相关问题也将成为未来一段时间内数据库研究的重点内容,比如云数据库的体系架构和数据模型等等.

林子雨等:云数据库研究1151

(3) 数据库市场份额面临重新分配.在过去的几十年里,数据库市场一直被诸如Teradata,Oracle,IBM DB2, Microsoft SQL Server,Sybase等传统数据库厂商所垄断.随着云数据库的出现和不断发展,市场将面临重新洗牌.首先,Amazon和Google等原本并不从事数据库业务的国际知名企业,也乘着云计算的东风,开发了云中的数据库产品,加入这场新兴市场的角逐.实际上,对于云数据库市场而言,Amazon SimpleDB和Google BigTable这类产品扮演了引领者的角色,传统的数据库厂商已经成为跟进者;其次,一些新的云数据库厂商开始出现,并且推出了具有影响力的产品,比如Vertica的Analytic Database for the Cloud和EnterpriseDB的Postgres Plus in the Cloud.因此,数据库市场份额的重新分配不可避免.

2 云数据库产品

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

? 传统的数据库厂商:Teradata,Oracle,IBM DB2和Microsoft SQL Server;

? 涉足数据库市场的云供应商:Amazon,Google和Yahoo;

? 新兴小公司:Vertica,LongJump和EnterpriseDB.

就目前阶段而言,虽然一些云数据库产品,如Google BigTable,SimpleDB和HBase,在一定程度上实现了对于海量数据的管理,但是这些系统暂时还不完善,只是云数据库的雏形.让这些系统支持更加丰富的操作以及更加完善的数据管理功能(比如复杂查询和事务处理)以满足更加丰富的应用,仍然需要研究人员的不断努力.

表1给出了目前市场上常见的云数据库产品,对于其中一些主要产品,下面我们会作简要介绍.

Table 1 Cloud database products

表1云数据库产品

企业产品

Amazon Dynamo, SimpleDB, RDS

FusionTable

Google BigTable,

Microsoft Microsoft SQL Server Data Services或SQL Azure

Cloud

Oracle Oracle

Yahoo! PNUTS

Vertica Analytic Database v3.0 for the Cloud

EnerpriseDB Postgres Plus in the Cloud

开源项目Hbase, Hypertable

其他EnerpriseDB, FathomDB, ScaleDB, Objectivity/DB, M/DB:X

2.1 Amazon的云数据库产品

Amazon是云数据库市场的先行者.Amazon除了提供著名的S3存储服务和EC2计算服务以外,还提供基于云的数据库服务Dynamo[14].Dynamo采用“键/值”存储,其所存储的数据是非结构化数据,不识别任何结构化数据,需要用户自己完成对值的解析.Dynamo系统中的键(key)不是以字符串的方式进行存储,而是采用md5_key(通过md5算法转换后得到)的方式进行存储,因此,它只能根据key去访问,不支持查询.SimpleDB是Amazon公司开发的一个可供查询的分布数据存储系统,它是Dynamo“键/值”存储的补充和丰富.顾名思义, SimpleDB的目的是作为一个简单的数据库来使用,它的存储元素(属性和值)是由一个id字段来确定行的位置.这种结构可以满足用户基本的读、写和查询功能.SimpleDB提供易用的API来快速地存储和访问数据.但是, SimpleDB不是一个关系型数据库,传统的关系型数据库采用行存储,而SimpleDB采用了“键/值”存储,它主要是服务于那些不需要关系数据库的Web开发者.

Amazon RDS(Amazon relational database service)是Amazon开发的一种Web服务,它可以让用户在云环境中建立、操作关系型数据库(目前支持MySQL和Oracle数据库).用户只需要关注应用和业务层面的内容,而不需要在繁琐的数据库管理工作上耗费过多的时间.

此外,Amazon和其他数据库厂商开展了很好的合作,Amazon EC2应用托管服务已经可以部署很多种数据库产品,包括SQL Server,Oracle 11g,MySQL和IBM DB2等主流数据库平台,以及其他一些数据库产品,比如

1152 Journal of Software软件学报 V ol.23, No.5, May 2012

EnerpriseDB.作为一种可扩展的托管环境,开发者可以在EC2环境中开发并托管自己的数据库应用.

2.2 Google的云数据库产品

Google BigTable是一种满足弱一致性要求的大规模数据库系统.Google设计BigTable的目的,是为了处理Google内部大量的格式化及半格式化数据.目前,许多Google应用都是建立在BigTable上的,比如Web索引、Google Earth、Google Finance、Google Maps和Search History.文献[15]描述了BigTable提供的简单数据模型,它允许客户端对数据部署和格式进行动态控制,并且描述了BigTable的设计和实现方法.BigTable是构建在其他几个Google基础设施之上的:首先,BigTable使用了分布式Google文件系统GFS(Google file system)[16]来存储日志和数据文件;其次,BigTable依赖一个高可用的、持久性的分布式锁服务Chubby[17];再次,BigTable依赖一个簇管理系统来调度作业、在共享机器上调度资源、处理机器失败和监督机器状态.

但是,与Amazon SimpleDB类似,目前来说,BigTable实际上还不是真正的DBMS(database management system),它无法提供事务一致性、数据一致性.这些产品基本上可以被看成是云环境中的表单.

Google开发的另一款云计算数据库产品是Fusion Tables[18].它采用了基于数据空间的技术.该技术在上世纪90年代就已经出现.Google充分利用了该技术的潜力.Fusion Tables是一个与传统数据库完全不同的数据库,可以弥补传统数据库的很多缺陷.比如通过采用数据空间技术,它能够简单地解决RDBMS中管理不同类型数据的麻烦,以及排序整合等常见操作的性能问题.Fusion Tables可以上传100MB的表格文件,同时支持CSV和XLS格式,并且具有处理大规模数据的能力.

2.3 Microsoft的云数据库产品

2008年3月,微软通过SQL Data Service(SDS)提供SQL Server的RDBMS功能,这使得微软成为云数据库市场上的第一个大型数据库厂商.此后,微软对SDS功能进行了扩充,并且重新命名为SQL Azure.微软的Azure 平台提供了一个WEB服务集合,可以允许用户通过网络在云中创建、查询和使用SQL SERVER数据库,云中的SQL SERVER服务器的位置对于用户而言是透明的.对于云计算而言,这是一个重要的里程碑.SQL Azure具有以下特性:

? 属于关系型数据库:支持使用TSQL(transact structured query language)来管理、创建和操作云数据库;

? 支持存储过程:它的数据类型、存储过程和传统的SQL Server具有很大的相似性,因此,应用可以在本地进行开发,然后部署到云平台上;

? 支持大量数据类型:包含了几乎所有典型的SQL Server 2008的数据类型;

? 支持云中的事务:支持局部事务,但是不支持分布式事务.

2.4 开源云数据库产品

HBase[19]和Hypertable利用开源MapReduce平台Hadoop,提供了类似于BigTable的可伸缩数据库实现. MapReduce[20]是Google开发的、用来运行大规模并行计算的框架.采用MapReduce的应用更像一个人提交的批处理作业,但是这个批处理作业不是在单个服务器上运行,应用和数据都是分布在多个服务器上.Hadoop是由Yahoo资助的一个开源项目,是MapReduce的开源实现,从本质上来说,它提供了一个使用大量节点来处理大规模数据集的方式.

HBase已经成为Apache Hadoop项目的重要组成部分,并且已经在生产系统中得到应用[5].与HBase类似的是Hypertable.不过,HBase的开发语言是Java,而Hypertable则采用C/C++开发.与HBase相比,Hypertable具有更高的性能.但是,HBase不支持SQL(structual query language)类型的查询语言.

甲骨文开源数据库产品BerkelyDB也提供了云计算环境中的实现.

2.5 其他云数据库产品

Yahoo! PNUTS[21]是一个为网页应用开发的、大规模并行的、地理分布的数据库系统,它是Yahoo!云计算平台重要的一部分.Vertica Systems在2008年发布了云版本的数据库.10Gen公司的Mongo、AppJet的AppJet

林子雨等:云数据库研究1153

数据库也都提供了相应的云数据库版本.M/DB:X是一种云中的XML数据库,它通过HTTP/REST访问. FathomDB旨在满足基于Web的公司提出的高传输要求,它所提供的服务更倾向于在线事务处理而不是在线分析处理.IBM投资的EnerpriseDB也提供了一个运行在Amazon EC2上的云版本.LongJump是一个与Salesforce. com竞争的新公司,它推出了基于开源数据库PostgreSQL的云数据库产品.Intuit QuickBase也提供了自己的云数据库系列.麻省理工学院研制的Relational Cloud[22]可以自动区分负载的类型,并把类型近似的负载分配到同一个数据节点上,而且采用了基于图的数据分区策略,对于复杂的事务型负载也具有很好的可扩展性.此外,它还支持在加密的数据上运行SQL查询.

3 云数据库领域的研究问题

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

3.1 数据模型

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

3.1.1 键/值模型

BigTable,Dynamo,SimpleDB,PNUTS,HBase等产品都采用了键/值模型存储数据.

下面我们以Google BigTable的数据模型为例来介绍键/值模型.

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

一个BigTable实际上就是一个稀疏的、分布的、永久的多维排序图,它采用行键盘(row key)、列键(column key)和时间戳(timestamp)对图进行索引.图中的每个值都是未经解释的字节数组[15]:

? 行键:BigTable在行键上根据字典顺序对数据进行维护.对于一个表而言,行区间是根据行键的值进行动态划分的.每个行区间称为一个Tablet,它是负载均衡和数据分发的基本单位,这些Tablet会被分发到不同的数据服务器上.

? 列键:被分组成许多“列家族”的集合,它是基本的访问控制单元.存储在一个列家族当中的所有数据,通常都属于同一种数据类型,这通常意味着具有更高的压缩率.数据可以被存放到列家族的某个列键下面,但是在把数据存放到这个列家族的某个列键下面之前,必须首先创建这个列家族.在创建完成一个列家族以后,就可以使用同一个家族当中的列键.

? 时间戳:在BigTable中的每个单元格当中都包含相同数据的多个版本,这些版本采用时间戳进行索引.BitTable时间戳是64位整数.一个单元格的不同版本是根据时间戳降序的顺序进行存储的,这样,最新的版本可以被最先读取.

这里以文献[15]中的一个实例来阐释BigTable的数据模型.图2显示了存储了网页数据的WebTable的一个片段.行名称是反转的URL,contents列家族包含了网页内容,anchor列家族包含了任何引用这个页面的

1154 Journal of Software软件学报 V ol.23, No.5, May 2012

anchor文本.CNN的主页被Sports Illustrated和MY-look主页同时引用,因此,这里的行包含了名称为“anchor: https://www.doczj.com/doc/9a13457946.html,”和“anchor:my.look.ca”的列.每个anchor单元格都只有1个版本,contents列有3个版本,分别对应于时间戳t3,t5和t6.

Fig.2 An example of the data model of BigTable

图2 BigTable数据模型的一个实例

HBase[19]和BigTable一样,也采用了键/值数据模型,它是一个开放源码、分布式、面向列、多维、高可用、高性能的存储技术,采用JAVA语言编写.作为一个使用了Hadoop的分布式数据库,HBase可以实现结构化数据的可靠存储.就像Google BigTable充分利用Google File System提供的分布式数据存储功能一样,HBase的目的就是在HDFS(hadoop distributed file system)上提供类似BigTable的功能.HBase采用多层索引表来执行键/值映射,获得了优越的主键查询性能.

Hbase,BigTable中的数据库模式和关系型模式有很大的区别:第一,不存在表间的联接操作;第二,整个模式也只有1个索引——行键.与RDBMS(relational database management system)不同的是,开发者不需要使用WHERE从句的等价表达形式.通过设计,HBase中的所有访问方法或者通过行键访问,或者通过行键扫描,从而使得整个系统不会慢下来.由于HBase位于Hadoop框架之上,MapReduce就可以用来生成索引表[19].

HBase列家族可以被配置成支持不同类型的访问模式.一个家族也可以被设置成放入内存当中,以消耗内存为代价,从而换取更好的响应性能.

此外,Amazon Dynamo,SimpleDB也都和BigTable一样采用了键/值存储.SimpleDB中包含3个概念: domain,item和attribute.其中,domain相当于一个table;item相当于一行;attribute相当于一列,一列可以有多个值.但是,SimpleDB和BigTable在数据划分的方式上存在一些差别:

? SimpleDB的数据划分:采用静态数据划分方法,利用哈希函数把数据分发到多个数据节点,这使得SimpleDB更像一个哈希系统.这种方法的优点是实现难度小;但是缺点也很明显,即用户的一些domain 存放不连续.为了降低不连续数据存放对用户查询性能带来的负面影响,SimpleDB对用户domain的大小进行限制,比如一个domain大小不超过10GB.

? BigTable的数据划分:采用动态划分方法,一个用户的数据可能会被划分成多个Tablet,分发到不同的数据节点上.这种方法的优点是可以很好地支持负载均衡,缺点是需要相关的Tablet分拆与合并机制.

BigTable,Dynamo,SimpleDB,PNUTS,HBase等产品虽然都采用了键/值模型存储数据,但是这些系统在进行数据访问的时候都是以单个键作为访问粒度,这种方式对于一些网页应用而言无法取得好的性能,比如在线游戏、社区网络、合作编辑等包含合作性质的应用,这些应用需要对一个键组(key group)进行一致性的访问.由此,文献[23]设计了名为G-Store的键/值系统,并提出“键组协议”来对一组键进行一致的、高效的访问.也就是说,在该系统中,数据访问的粒度不再是单个的键,而是一个键组.

3.1.2 关系模型

微软的SQL Azure云数据库采用了关系模型,它的数据分区方式和BigTable有些不同.关系型云数据库的数据模型涉及行组和表组等相关概念.

一个表是一个逻辑关系,它包含一个分区键,用来对表进行分区.具有相同分区键的多个表的集合称为表组.在表组中,具有相同分区键值的多个行的集合称为行组.一个行组中包含的行总是被分配到同一个数据节点

林子雨 等:云数据库研究 1155

上.每个表组会包含多个行组,这些行组会被分配到不同的数据节点上.一个数据分区包含了多个行组.因此,每个数据节点都存储了位于某个分区键值区间内的所有行.

这里以一个实例来解释关系型云数据库的数据模型.如图3所示,一个表组包含了两个相关的表,即图3中的表1和表2.表1和表2分别包含了一个分区键列,每个分区键列是由多个分区键值组成的,这两个分区键列具有相同类型的分区键,都是ID 类型的数值型数据.表1中的ID 列和表2中的ID 列存在主外键关联.因此,表1中和表2中的ID 列值为27的3个行(图中用灰色底纹表示,并且用虚线框包围的部分)就属于一个行组.从图中也可以看出,表组被分割成多个分区.而且,同一行组中的

内容都位于同一个数据分区内.

一个表组通常包含那些会被某个应用同时使用的多

个表,因此需要把这些表存储在一起,从而加快查询效率.

比如,有两个表STUDENT _INFO 和BOOKBORROWING _

INFO ,前者记录的信息包括名字、性别、年龄、电话等

等,后者记录了借书的相关信息.当图书馆管理员查询一

个人的借书记录时,通常需要同时查看借阅者姓名、年

龄、电话、借书数量、借书时间等信息,这就需要在

STUDENT _INFO 和BOOKBORROWING _INFO 这两个表

之间进行联接操作.显然,如果把这两个表存储在同一个

数据节点上,联接操作则会快很多.

类似地,把一个行组中的多个行存储在一个数据分

区内也具有明显的好处.比如,图3中表1和表2中的ID

为27的的多个行构成一个行组,它们之间存在主外键关

联,把它们存放在一起可以加快查询的效率.

3.1.3 支持多种数据模型

SQL Azure 等云数据库产品采用了关系模型,BigTable 等产品采用了键/值模型,而文献[24]中描述的CloudDB 则可以同时支持关系模型和键/值模型,甚至可以采用列式存储(columnar store)[25].CloudDB 可以同时维护3种不同类型的数据存储,从而有效处理各种不同类型的负载.在CloudDB 中,针对一个具体的应用而言,采用何种存储类型,取决于应用环境、负载类型特点和SLA 需求等因素.

3.2 系统体系架构

这里主要讨论在存储层面采用非共享架构的云数据库.我们将阐述其体系架构和数据访问方法,并介绍几个系统实例.

3.2.1 体系架构

这里将以HBase 和SQL Azure 为例,分别介绍采用键/值数据模型和关系数据模型的具有代表性的云数据库体系架构.

3.2.1.1 采用键/值数据模型的云数据库体系架构

HBase [19]作为BigTable 的一个开源实现,基本采用了和BigTable 类似的架构.如图4所示,HBase 体系架构中包括Client,Zookeeper,Hmaster,HRegionServer 和Store,具体功能如下[26]:

? Client:访问HBase 的接口.

? Zookeeper:存储了HBase 的数据库模式和所有HRegion 的寻址入口,实时监控HRegionServer 的状态. ? HMaster:管理用户对Table 的增、删、改、查操作,管理HRegionServer 的负载均衡,调整Region 分布等. ? HRegionServer:负责响应用户I/O 请求,向HDFS 文件系统中读写数据,是HBase 中最核心的模块.

? Store:是HBase 存储的核心,由MemStore 和StoreFiles 两部分组成.用户写入的数据首先会放入MemStore,当MemStore 满了以后会被存放到一个StoreFile 中,StoreFile 将被存放在HDFS 文件系统的Fig.3 Data model of relational cloud databases 图3 关系型云数据库的数据模型 表组表21627558916272789分区键列分区行组表1

1156

Journal of Software 软件学报 V ol.23, No.5, May 2012

HFile 中.

Fig.4 Architecture of HBase

图4 HBase 的体系架构

3.2.1.2 采用关系数据模型的云数据库体系架构

如图5所示,SQL Azure 的体系架构[27]中包含了一个虚拟机簇,可以根据工作负载的变化,动态增加或减少虚拟机的数量.每台虚拟机SQL Server VM(virtual machine)安装了SQL Server 2008数据库管理系统,以关系模型存储数据.通常,一份数据库会被散存储到3台~5台SQL Server VM 中.每台SQL Server VM 同时安装了SQL Azure Fabric 和SQL Azure 管理服务,后者负责对每个数据库间的数据复写工作,以保障SQL Azure 的基本高可用性要求.不同SQL Server VM 内的SQL Azure Fabric 和管理服务之间会彼此交换监控信息,以保持整体服务的可监控性.

SQL Azure Fabric SQL server 实例管理服务数据库

连接到位于另一台

机器上的

SQL Azure Fabric

连接到位于另一台机器上的SQL Azure

管理服务SQL Azure Fabric

管理服务SQL Azure Fabric 管理服务SQL Azure Fabric 管理服务...

SQL server 实例SQL server 实例SQL server

实例

Fig.5 Architecture of SQL Azure

图5 SQL Azure 的体系架构

MemStore MemStore HFile

HMaster StoreFile StoreFile

HFile HFile Store StoreFile Store ………

………HRegion

HRegionServer

HRegionServer H L o g Client Zookeeper

林子雨 等:云数据库研究

1157

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

云数据库管理器1. 请求分区映射图

2. 返回分区映射图4. 请求数据

5. 返回数据

客户端

1~100101~200201~300301~400401~500

3. 根据分区映射图找到数据存储位置

Fig.6 Data accessing method in cloud databases

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

3.2.3 系统实例

在BigTable 中,数据节点服务器称为Tablet 服务器,管理器称为主服务器.主服务器负责把Tablet 分配到Tablet 服务器,探测Tablet 服务器的信息,进行Table 服务器的负载均衡,以及GFS 文件系统中的垃圾收集(数据分区被存储在GFS 文件中).此外,它还处理模式变化,比如表和列家族创建.就像许多单服务器分布式存储系统一样,客户端并不是直接从主服务器读取数据,而是直接从Tablet 服务器上读取数据.因为客户端函数库会缓存Tablet 位置信息,所以BigTable 客户端并不依赖于主服务器来获得Tablet 的位置信息,因而大多数客户端从来不和主服务器通信,这就使得在实际应用中主服务器的负载很小.

HBase [19]采用了和BigTable 类似的实现方法,不同的是,它的数据分区存储在HDFS 中.一个数据分区是由一个表中排序的行构成的,从而使得所有的表行都包含在一个数据分区的集合中.HBase 依赖于Zookeeper (Zookeeper 和BigTable 一样,依赖于Chubby [17])来保证在任何时候都有总有一个主服务器可以用来存储HBase 数据的位置引导信息,这些信息可以帮助发现数据分区服务器的位置.采用单个主服务器的设置很简单,但是可能会导致较差的可用性.

HugeTable [5]是一个分布式结构化数据库系统,它采用了标准的SQL 语言查询接口,支持高性能的全局索引,并且在设计上采用了多主服务器机制、TabletServer 持续服务保证以及可靠的Zookeeper 系统,已经被完全避免了类似HBase 系统中的单点失效问题.HugeTable 的基本框架包含4个层次:应用层、ODBC/JDBC 驱动层、SQL 服务层和Hadoop 云基础层.在应用层,HugeTable 支持朴素应用接口(它支持使用批更新的直接数据访问)和标准的SQL 接口.ODBC/JDBC 驱动层就位于应用层的下面,它为上面的SQL 应用提供了JDBC/ODBC 驱动. SQL 服务层会分析所有到达的SQL 语句,并生成相应的并行查询过程.Hadoop 云基础层包括一些基本的系统架构组件,比如MapReduce [20],DFS,Zookeeper 和HBase [19],HugeTable 依赖这些组件来实现自己的功能.

3.3 事务一致性

2000年,UC Berkeley 的Brewer 教授提出了著名的CAP 理论[28],后来,Gilbert 和Lynch 两人证明了CAP 理论的正确性[29].所谓的CAP 指的是:

1158 Journal of Software软件学报 V ol.23, No.5, May 2012

? C: Consistency(一致性):任何一个读操作总是能读取到之前完成的写操作结果;

? A: Availability(可用性):每一个操作总是能够在确定的时间内返回;

? P: Tolerance of network Partition(分布性):在出现网络分区的情况下,仍然能够满足一致性和可用性.

CAP理论告诉我们,一个分布式系统不可能同时满足一致性、可用性和分区容错性这3个需求,最多只能同时满足2个.

因此,根据CAP理论,我们在设计一个系统时可以有几种选择:

? 第1种:放弃分布性.把所有与事务相关的东西都放置到同一台机器上.显然,这种方法可扩展性很差.

? 第2种:放弃可用性.比如,可以把所有的数据都放置到一个节点上,当其他节点存在访问请求时,都被转向到该节点.显然,这方方案存在明显的单点性能瓶颈问题.

? 第3种:放弃一致性.由于不同用户对数据的一致性要求不一样,当用户的这种要求不高时,就要果断考虑放弃一致性.

传统的数据库提供强一致性保证,可以保证调用时序的一致性.在分布式的云环境中,维护事务的一致性具有很大的难度,通常代价很高.很多现有的云数据库产品在实现时,为了获得CAP理论中的可用性和分布性,都放松了对事务ACID(atomicity,consistency,isolation,durability)四性的要求.比如,Google BigTable就弱化了事务的原子性要求,只支持单行事务,可以允许对存储在某个行键下面的数据执行原子的“读-修改-写”操作. BigTable当前不支持通用的跨行键的事务,虽然它在客户端提供了跨行键批量写入数据的接口[11].类似地, Amazon SimpleDB等都没有实现通用的事务[30].比如,Amazon SimpleDB放松了对事务的一致性和隔离性的要求,转而采用最终一致性(用户B虽然不能立即看到用户A修改的信息,但是用户B最终会看到用户A的修改信息),使得所有副本不必都获得数据副本的当前最新值.但是,SimpleDB可以支持强一致读以及基于条件更新或者删除的乐观锁机制,并提供了简单的SQL Select子集支持.Amazon Dynamo[14]也采用了最终一致性.Yahoo! PNUTS考虑到大部分WEB应用对一致性并没有非常严格的要求,因此在设计上放弃了对强一致性的追求(采用时间线一致性),转而追求更高的可用性、容错能力和更快的响应等[21].

文献[31]提出了一种基于树的一致性方法,并为云数据库引入了部分一致性和完整一致性的概念,从而有效减少不同数据副本之间的依赖性,极大地降低了事务失败的概率.

Chohan等人[32]认为,支持对分布在不同数据库中的多行数据进行并发式地原子更新(要么全部更新,要么都不更新),可以极大推动云数据库的商业化应用.因此,该文针对键/值模型的云数据库提出了称为DAT (database agnostic transactions)的事务处理方法.该方法采用了一个单独的、独立于数据库的软件层,并采用了Zookeeper服务(云计算和其他分布式环境中使用的一种开源的锁服务),只需要底层的云数据库提供行级别的原子更新支持,就可以实现针对多行数据更新的原子性、一致性、隔离性和持久性.Chohan等人在HBase和HyperTable等云数据库产品上对DAT进行了事务处理性能的测试,取得了较好的效果.

实际上,分布式环境下的事务一致性并不是云数据库才面临的问题,云存储系统也同样存在该问题.文献[33]研究了在Amazon S3中的一种新的事务模型,它不仅允许设计者在事务级水平定义数据的一致性保障水平,而且允许在运行时自动切换一致性保障水平,并且提出了许多技巧,它允许系统通过监督数据和收集数据时间统计信息来自动地调整一致性水平.相信这方面的研究会给云数据库的相关研究带来一定的启示.

事务型数据管理系统当中存在维护分布式环境下的事务一致性的开销,在分析型数据管理系统当中就没有这个问题.对于事务型的工作负载,一个DBMS可以从一个失败中恢复,而不会丢失任何数据;并且在分布式数据库环境中,即使在面临节点失效的情况下,系统也可以成功地提交事务,这其中涉及各种保障机制的设计和相关开销.对于分析型负载当中的只读查询,根本不包含需要提交的写事务,也不必担心节点失效时会丢失更新操作.因此,一个分析型DBMS只是一个非常简单的DBMS,当查询涉及的某个节点失效时,不需要让查询重启.这也是分析型数据库管理系统更适合部署在云环境中的原因.

文献[34]提出把云环境下数据库中的事务服务从数据管理组件中单独分离出来.传统的DBMS都存在一个事务存储管理器,它包含相互紧密结合的4个组件:(1) 负责并发控制的锁管理器;(2) 负责恢复的日志管理器;

林子雨等:云数据库研究1159

(3) 进行分批I/O处理的数据缓冲池;(4) 负责如何在磁盘上存放数据的访问控制方法.云计算时代的到来,产生了对事务服务和数据管理进行分离的需求.该文献把存储引擎分成两个部分,即事务组件(transactional component)和数据组件(data component).事务组件只在逻辑层面工作,即它知道事务以及事务的逻辑并发控制和恢复,但是并不知道的底层存储页(page)的结构(比如可能采用B-树);数据组件知道物理存储结构,它可以支持面向记录的原子访问操作,但是不知道事务.这种分离方法支持在云数据库中实现比较灵活的事务处理.

3.4 编程模型

云数据库存储了海量数据,涉及到大量的数据运算,如果仍然采用传统的数据处理方法,则将无法充分发挥云环境的优势.因此,采用一种机制简单而又具有高可扩展性的编程方法就显得尤为重要.查询这种大型的数据集,可以采用Google发明的一种新的编程模型,称为MapReduce[20].

MapReduce编程模型用来处理跨越成百上千个机器的大规模数据集,该软件架构隐藏了并行计算、数据分布和失败处理的细节.它背后的思想是,在分布式环境下处理数据,总是包括两个基本步骤:(1) 映射所需的数据;(2) 对这些数据进行聚集(aggregate)操作.它让用户定义一个映射函数,这个映射函数把一个“key/value”对的集合转换成一个中间临时的“key/value”对的集合,然后使用一个reduce函数把所有那些与同一个键相关的中间临时值都进行合并.许多现实世界的任务都可以采用这个模型来表达.MapReduce可以运行在大规模商用服务器簇上,并且具有很高的可扩展性[20].一个典型的MapReduce计算会在成千上万的机器上处理许多TB的数据.

但是,传统的关系型数据库和MapReduce对数据的处理方式存在很大的区别,因此需要把关系数据库中的一些操作转换成MapReduce操作,这其中一类典型的操作就是联接(join)操作.

总的来说,在MapReduce环境下执行两个关系的联接操作的方法如下[35]:假设关系R(A,B)和S(B,C)都存储在一个文件中.为了联接这些关系,必须把来自每个关系的各个元组都与一个key关联,这个key就是属性B的值.可以使用一个Map进程集合把来自R的每个元组(a,b)转换成一个key-value对,其中的key就是b,值就是(a,R).注意,这里把关系R包含到value中.这样做使得我们可以在Reduce阶段,只把那些来自R的元组和来自S 的元组进行匹配.类似地,可以使用一个Map进程集合把来自S的每个元组(b,c)转换成一个key-value对,key是b,value是(c,S).这里把关系名字包含在属性值中,可以使得在Reduce阶段只把那些来自不同关系的元组进行合并.Reduce进程的任务就是把来自关系R和S的具有共同属性B值的元组进行合并.这样,所有具有特定B值的元组必须被发送到同一个Reduce进程.假设使用k个Reduce进程.这里选择一个哈希函数h,它可以把属性B 的值映射到k个哈希桶,每个哈希值对应一个Reduce进程.每个Map进程把key是b的key-value对都发送到与哈希值h(b)对应的Reduce进程.Reduce进程把联接后的元组(a,b,c)写到一个单独的输出文件中.

虽然采用MapReduce可以带来很多收益,但并不是说可以不要任何代价.实际上,它有时也会影响到数据库其他方面的性能.文献[36]开展了一系列实验,对Hadoop和几个性能优秀的并行数据库进行性能比较.实验结果表明,对于一些分析型的负载,MapReduce不仅没有性能优势,而且要比并行数据库慢3.1倍~6.5倍.针对这个问题,文献[13]的研究发现,当云数据库中的数据节点数量众多(几千个节点),并且是经常需要动态分发资源的分析型应用时,MapReduce可以带来很好的性能.

此外,类似BSP(bulk synchronous parallel)[37]和MapReduce Online[38]等并行编程框架也将在云数据库中发挥重要作用.BSP包含了许多通过通信网络连接起来的处理器,每个处理器都有非常快速的局部内存,可以开展多线程计算.MapReduce Online是一种针对MapReduce的改进框架.MapReduce只能支持批作业处理,每个MapReduce任务的输出都会首先被存储到磁盘然后才被使用;而MapReduce Online可以对各种操作进行流水线化处理,提高了并行性,大量降低作业完成时间,提高了系统的利用率.

3.5 数据安全

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

1160 Journal of Software软件学报 V ol.23, No.5, May 2012

同的访问控制级别,保证不同层次的用户只能授权访问限定范围内的数据.因此,如何在云数据库中对数据实行加密和应用不同等级的访问控制约束规则,就成为新的研究热点.

文献[12]提出了衡量云计算环境的各种资源的私有性的有效方法,并且通过采用基于元数据和特权访问控制的方法来实现对云数据库资源的可信授权访问.该文献为每个VMM(virtual machine memory)中的授权策略和云数据库中的资源都构建成以图表示的特权链,用来进行访问和安全控制.

文献[10]重点研究了支持多个用户在加密云数据库上执行SQL查询,并允许数据库管理员对不同用户设置不同级别的访问权限.为了实现只有授权用户才能对数据进行访问,文中采用KP-ABE(key-policy attribute based encryption)加密策略,即每条策略都和用户的解密密钥关联,分配给每个用户的访问策略就被内嵌到该用户的解密密钥中.因此,只有当一个用户的解密密钥中包含的访问策略允许该用户访问某个数据时,该用户才可以访问该数据.

此外,同态加密也是云数据库安全领域未来的重点研究方向.同态加密是基于数学难题的计算复杂性理论的密码学技术.对经过同态加密的数据进行处理得到一个输出,将这一输出进行解密,其结果与用同一方法处理未加密的原始明文数据得到的输出结果是一样的.同态加密不同于传统的数据加密,它允许在没有解密算法和解密密钥的条件下对加密的数据进行运算.

3.6 性能优化

云计算是一个虚拟机器环境,在虚拟机器环境中部署软件的一个公共模型是虚拟器具(virtual appliance)模型.一个虚拟器具是一个VM(virtual machine)镜像,具有预装和配置的应用.配置一个应用,只需把这个VM镜像拷贝到一个物理机器上面,启动这个VM,然后执行配置任务即可.随着虚拟化和云计算的日益普及,我们期望可以采用一种更加普遍的方式来提供数据库服务,也就是通过部署在云当中的数据库器具来提供数据库服务,这是云数据库的一种实现方式.例如,Amazon在EC2平台上提供了MySQL,ORACLE和Microsoft SQL Server数据库服务.由于云环境中的负载模式是不断变化的,这就会导致各种资源的动态分配.如何在这种动态环境下获得最好的数据库性能,是一个值得研究的问题.

文献[39]讨论了在云中部署数据库器具的一些性能优化方面的挑战,并给出了相应的解决方案;并以一个在不同的数据库器件之间分配CPU处理能力的例子阐述了虚拟环境调优方案.文献[7]简单讨论了在云计算的虚拟化环境下,如何根据资源使用情况对数据库实例进行迁移,从而达到资源最大化利用,优化数据库服务性能.文献[40]提出了Albatross,可以用较小的代价处理面向OLTP应用的云数据库中的数据库实例动态迁移问题,从而实现有效的负载均衡;Albatross在迁移过程中可以记录数据库缓存和活跃事务状态,迁移结束后相关事务可以继续执行,从而使得对事务的影响最小化.文献[41]设计了名为“Dolly”的原型系统,它采用VM克隆技术和自定义代价模型,可以根据不同应用情况调整数据库配置策略.文献[42]研究了如何在云数据库中为多个用户所使用的资源进行智能化管理和分配,从而实现整体性能优化.该文提出了一个名为SmartSLA的系统,它包含两个模块:系统建模模块和资源分配决策模块.前者可以利用机器学习算法为不同资源分配模式构建代价模型,进行代价和收益评估;后者可以根据代价评估结果动态决定资源分配,使得整个云数据库系统实现收益最大化.文献[43]研究了在给定查询负载和满足QoS(quality of service)的情况下,为不同的云数据库实例分配资源,实现系统性能的最优化.文中提出了两种方法,即白盒方法和黑盒方法.前者对负载所消耗的系统资源进行精细地评估,而后者则只进行粗略评估.文中把两种方法等价变换成多维装箱(bin-packing)问题,并使用通用约束求解器(generic constraint solver)来解决该问题.

3.7 测试基准

在云数据库逐渐走向成熟时,有很多企业开始考虑是否要将自己的企业应用搬到云环境中.由于云数据库市场存在种类繁多的相关产品,企业必须决定究竟要选择哪个厂商的产品.企业做出决定需要首先考虑的一个因素是,是否可以取得更好的性能和更低的代价.因此,这里就需要一个测试不同云数据库产品性能的测试基准(benchmark).

林子雨等:云数据库研究1161

目前,已经有一些可以使用的测试基准,比如:

? Google’s BigTable采用的性能测试方法[15]:可以对那些不支持结构化查询语言的系统进行性能评估.

? Hadoop采用的性能评估方法:可以对一些结构化查询的性能进行评估.

? Yahoo! Cloud Serving Benchmark (YCSB)[44]:支持在测试时采用不同类型负载的组合,包括插入、读取、更新和扫描等;该测试主要针对类似PNUTS的系统,因为这些系统主要提供对数据的在线读写访问.

? 其他:比如文献[36]采用的方法.

但是,上述性能测试方法都没有体现当采用不同的系统实现方法时对系统整体性能的影响.实际上,系统实现方法多种多样,比如存储体系架构、数据模型、一致性和可用性水平等等,都不尽相同.因此,文献[45]对多个系统采用不同的实现方法进行了详尽的性能指标测试,可以作为评估不同系统性能的参考.

文献[46]则采用TPC-W测试基准对采用不同架构(比如分区、复制、分布式控制和缓存等)的多种云数据库产品的性能进行了比较和分析,比较的产品包括AWS MySQL,AWS MySQL/R,AWS RDS,AWS SimpleDB, MS Azure等.总体而言,该文侧重于对事务型操作(比如读和更新操作)的性能分析,而没有针对OLAP(on-line analytical processing)操作进行分析.

3.8 其他研究

文献[13]描述了如何在云环境中提供高效可扩展的数据库服务,并介绍了作者开发的一个新系统epiC,它可以根据负载类型的需求,同时支持OLAP和OLTP(on-line transaction processing)类型的存储.在epiC中,OLAP 查询是通过并行扫描的方式进行处理,而OLTP查询则采用索引和局部查询优化.文献[47]描述了epiC系统所采用的多维数据索引方法RT-CAN,它可以大大改善查询的性能.

文献[48]重点研究了数据库之间的动态数据迁移技术,可以有效支持云数据库环境下的动态负载均衡.该文结合了按需拉取(on-demand pull)和异步推给(asynchronous push),从而实现在最小的时间间隔内迁移数据库实例.通过使用轻量级的同步,不仅极大地减小了数据迁移过程中的失败操作数量,也极大地减小了迁移操作所涉及的数据量.

数据质量也是云数据库在设计和应用中需要考虑的重要问题.数据质量问题一般都是由于脏数据(dirty data)造成的.这里所谓的脏数据,包括不一致性、不准确性、错误性、冗余性和过期数据.在云数据库这种海量数据环境下,更容易产生脏数据,这里主要有两个方面的原因:一是由于在大规模数据环境下,一个错误会传播到许多数据中;另一方面,在大规模数据环境下,数据不一致性的概率进一步增大.数据清洗是传统的处理脏数据的方法,但是在云数据库的海量数据环境下,数据清洗的代价很高,会影响系统的效率.为此,文献[49]没有采用基于清洗的脏数据处理方法,而是直接在脏数据上进行查询,同时能够取得很好的查询效率和质量.文中提出了针对云数据库的脏数据库的存储架构,把相似的元组分成多个簇,脏数据被分布到多个节点上.为了保证在脏数据上进行查询也可以取得好的性能,文中采用了3层索引结构:(1) 代表层:同一个簇中的元组都由一个元组来统一代表,查询直接作用于这个元组代表,从而极大地缩减了扫描真实数据的开销;(2) 数据索引层:为代表元组中的列建立索引,从而使得查询能够快速找到相应的元组;(3) 节点索引层:可以快速定位那些可能包括查询相关结果的节点.

文献[8]提出了采用数据分裂(data fission)和数据融合(data fusion)的方法,在云计算环境下设计可扩展的数据库管理体系架构.该文献采用低代价的数据库迁移来支持轻量级的可伸缩性,并且设计了全自动的控制器,避免了人工操作.

4 结束语及未来研究展望

云数据库伴随着云计算技术的成熟而迅速发展,并且越来越受到业界和学术界的关注.本文阐述了云数据库的特性及其影响,并根据大量调研结果对相关的云数据库产品进行了归类和介绍;针对围绕云数据库的一些争议,我们做了简要分析,并给出了结论;同时,我们列出了云数据库领域的相关研究.

综合过去两年对云计算和云数据库的关注和研究,我们认为,在未来几年,数据模型、体系架构、编程模型、

1162 Journal of Software软件学报 V ol.23, No.5, May 2012

性能优化等方面将会有更多的研究成果出现.同时,以下问题是云数据及其相关研究领域的重点:

(1) 事务一致性.目前,只有SQL Azure等少数关系型云数据库能够支持严格的事务四性.BigTable和HBase 等采用了键/值模型的云数据库,都采用放松对ACID四性的要求,以保证系统的性能.事务型系统是企业应用中的一个重要部分,若要使云数据库很好地支持事务处理,必须设计相应机制,既能实现事务处理,又能够不对系统性能造成严重影响.类似于文献[34]中的事务服务和数据管理进行分离的方法,是一种可行的研究方向.

(2) 企业本地数据库和云数据库中数据的有效融合机制.经过几十年的应用,企业本地数据库存储了大量数据,纵然云数据库能够带来诸多好处,但是企业全面步入云数据库仍然需要一个过程,这期间,必然有一个长期的本地数据和云数据并存的局面.这就需要设计有效的机制,实现本地数据库和云数据库的有效融合,支持对两种数据库的统一管理.一种思路是,采用视图的机制,在逻辑层面对两种数据库进行整合.对于用户而言,看到的只是一个统一的逻辑数据视图,并不知道数据的物理存储地点;但是在物理层面,这些数据分布在企业本地数据库和云数据库中.如果采用视图机制,将会涉及数据模型的统一构建和来自不同数据源的数据的快速合并机制等方面的研究.

(3) 向云数据库中迁移数据.目前,大多数企业数据库都存储在企业内部的数据库里.在云数据库不断发展的过程中,如何把这些数据迁移到云中,是一个具有挑战性的问题.尤其是一些包含海量数据的科学数据库,可能无法直接迁移到云中,需要做一些模式和设置上的修改才可以.而且,科学数据库通常需要使用一些DBMS提供的高级管理功能,比如用户自定义函数和存储过程等,要在云数据库中实现所有这些高级功能,从目前来看还存在一定的困难.Thakar等人[50]在一个基于SQL SERVER的天文数据库上进行了大量实验,结果表明,在当前技术条件下,把如此复杂的数据库迁移到云数据库中几乎是不可能实现的.因此,需要研究向云数据库中迁移数据的有效方法.这里需要重点研究企业已采用的不同数据模型(比如面向对象或者关系模型)到云数据库产品所采用数据模型(比如键/值模型)的转换.文献[51]在这个方面做了初步的探索与尝试,总结了一些困难挑战和可能的解决方法.

(4) 云数据库的容灾.云数据库的数据存储在分布式环境中,不同的云数据库产品可能采用不同的存储平台.比如:Oracle云数据库托管在Amazon EC2平台上,使用了Amazon S3存储服务;而SQL Azure则可以直接使用微软自己的数据中心.这些云环境已经设计了相应的容灾机制,但它们都是针对通用的文件存储情形,而云数据库由于涉及事务处理,对故障的处理要更加复杂.因此,云数据库的容灾是一个需要重点研究的内容.一种比较新的尝试是,把灾难处理作为云环境中的一种服务提供给各种应用(包括云数据库)使用.

(5) 云数据库性能优化.云数据库同时为多个用户提供服务,不同用户的负载类型各不相同.如何根据用户的负载类型为不同用户合理分配资源,从而既能满足用户的处理要求,又能实现云数据库整体性能最大化,是一个需要继续深入研究的问题.我们认为,可以从3个方面开展相关研究:

? 研究智能资源管理模型,采用代价函数有效评估不同资源分配方法的代价,发现最优的资源分配方法.

比如,文献[43]把这类问题转换成多维装箱问题,并使用通用约束求解器来解决,是一个可行的思路;再比如,文献[22]采用的方法也很典型,它可以自动区分负载的类型,并把类型近似的负载分配到同一个数据节点上,实现资源的合理分配.

? 研究结合经济效益的负载均衡方法.一种好的负载均衡方法,应该使得服务器总体开销最小化.具体来说,候选服务器节点可能来自企业内部,例如内部私有云;也可能来自企业外部,例如公共云计算服务供应商.当采用企业内部服务器时,不同的服务器显然具备不同的负载处理开销.当采用企业外部服务器资源时,比如Amazon,Google和Microsoft等公司提供的公共云计算资源,同样需要考虑价格因素.这些云计算资源采取租赁的方式,按照CPU和带宽使用情况计费.当企业对IT资源需求量增加时,可以随时租赁更多的IT资源;而当企业需求减少时,又可以及时退租多余的IT资源.通过这种方式,可以使得企业最小化IT建设和维护开销.不同云计算服务提供商的服务水平和租赁价格通常各不相同,因此在处理负载均衡问题时,为了实现开销最小化,无论使用内部服务器资源还是外部服务器资源,都需要考虑经济因素.而现有的负载均衡方法在选择目标服务器时无法考虑经济因素.我们认为,可以考虑采用基于

林子雨等:云数据库研究1163

市场机制和Agent的负载均衡方法.市场机制是经济学领域非常成熟的资源分配方法,并且已经被计算机研究人员引入解决资源分配问题,但是还没有用市场机制解决云数据库负载均衡的相关研究.

? 研究动态数据迁移方法.云数据库的负载分布是一个动态变化的过程,为了保持性能最优,需要动态进行负载均衡和资源再分配.其中将涉及数据的动态迁移问题,即如何把数据从一个服务器节点迁移到另一个节点.数据迁移必须保证服务间断时间尽可能短,对系统性能的影响尽可能地小,这就对相关的算法提出了很高的效率要求.比如,文献[48]重点研究了数据库之间的动态数据迁移技术,可以有效地支持云数据库环境下的动态负载均衡.

(6) 云数据库测试基准.众多的云数据库产品可以满足不同类型的用户的应用需求.对于用户而言,在选择具体产品时,必须基于可靠的产品性能评测结果.因此,必须继续深入研究针对不同类型负载特点的测试基准,能够清晰呈现不同产品在不同负载类型下的性能变化.

(7) 云数据库相关标准.由于现阶段包括云数据库在内的各种云计算技术都是由各大厂商独立发展的,彼此都没有遵循统一的规范,这就造成了数据共享和迁移的诸多障碍,不利于网络数据应用的实现.当这个技术领域逐渐成熟时,将会出现各种云数据库标准,例如云数据库的SQL语言、云数据库的应用模型、云数据库的安全标准等等.比如,AtomPub已经成为基于云的数据存储的事实访问标准,可以让不同的存储平台之间(包括云数据库)具有统一的访问方法.

随着市场的发展和云数据库的不断成熟,一些围绕云数据库的问题将逐渐得到解决,一些争议也将会有更加明晰的结果.可以说,云数据库是数据库技术在未来一段时间内的发展趋势,该领域的相关问题也将成为数据库研究的重点内容.云数据库的发展、成熟与应用需要学术界和业界人员的共同努力.

References:

[1] Chen K, Zheng WM. Cloud computing: System instances and current research. Journal of Software, 2009,20(5):1337?1348 (in

Chinese with English abstract). https://www.doczj.com/doc/9a13457946.html,/1000-9825/3493.htm [doi: 10.3724/SP.J.1001.2009.03493]

[2] Dash D, Kantere V, Ailamaki A. An economic model for self-tuned cloud caching. In: Ioannidis YE, Lee DL, Ng RT, eds. Proc. of

the 25th Int’l Conf. on Data Engineering (ICDE 2009). New York: IEEE Computer Society Press, 2009. 1687?1693. [doi: 10.1109/ ICDE.2009.143]

[3] Feng DG, Zhang M, Zhang Y, Xu Z. Study on cloud computing security. Journal of Software, 2011,22(1):71?83 (in Chinese with

English abstract). https://www.doczj.com/doc/9a13457946.html,/1000-9825/3958.htm [doi: 10.3724/SP.J.1001.2011.03958]

[4] Xu M, Gao D, Deng C, Luo ZG, Sun SL. Cloud computing boosts business intelligence of telecommunication industry. In: Jaatun

MG, Zhao GS, Rong CM, eds. Proc. of the 1st Int’l Conf. on Cloud Computing (CloudCom 2009). Berlin: Springer-Verlag, 2009.

224?231. [doi: 10.1007/978-3-642-10665-1_20]

[5] Qi J, Qian L, Luo ZG. Distributed structured database system HugeTable. In: Jaatun MG, Zhao GS, Rong CM, eds. Proc. of the 1st

Int’l Conf. on Cloud Computing (CloudCom 2009). Berlin: Springer-Verlag, 2009. 338?346. [doi: 10.1007/978-3-642-10665- 1_31]

[6] Abouzeid A, Bajda-Pawlikowski K, Abadi DJ, Silberschatz A, Rasin A. HadoopDB: An architectural hybrid of MapReduce and

DBMS technologies for analytical workloads. PVLDB, 2009,2(1):922?933.

[7] Ahrens M, Alonso G. Relational databases, virtualization, and the cloud. In: Abiteboul S, B?hm K, Koch C, Tan KL, eds. Proc. of

the 27th Int’l Conf. on Data Engineering (ICDE 2011). New York: IEEE Computer Society Press, 2011. 1254. [doi: 10.1109/ICDE.

2011.5767966]

[8] Agrawal D, Abbadi AE, Das S, Elmore AJ. Database scalability, elasticity, and autonomy in the cloud—(extended abstract). In: Yu

JX, Kim MH, Unland R, eds. Proc. of the 16th Int’l Conf. on Database Systems for Advanced Applications (DASFAA 2011).

Berlin: Springer-Verlag, 2011. 2?15. [doi: 10.1007/978-3-642-20149-3_2]

[9] Soares L, Pereira J. Improving the scalability of cloud-based resilient database servers. In: Felber P, Rouvoy R, eds. Proc. of the

11th IFIP WG 6.1 Int’l Conf. on Distributed Applications and Interoperable Systems (DAIS 2011). Berlin: Springer-Verlag, 2011.

136?149. [doi: 10.1007/978-3-642-21387-8_11]

1164 Journal of Software软件学报 V ol.23, No.5, May 2012

[10] Ion M, Russello G, Crispo B. Enforcing multi-user access policies to encrypted cloud databases. In: Proc. of the IEEE Int’l Symp.

on Policies for Distributed Systems and Networks (POLICY 2011). New York: IEEE Computer Society Press, 2011. 175?177. [doi:

10.1109/POLICY.2011.14]

[11] Chang F, Dean J, Ghemawat S, Hsieh WC, Wallach DA, Burrows M, Chandra T, Fikes A, Gruber RE. Bigtable: A distributed

storage system for structured data. ACM Trans. on Computer Systems, 2008,26(2):1?26. [doi: 10.1145/1365815.1365816]

[12] Yoon JP. Access control and trustiness for resource management in cloud databases. In: Fiore S, Aloisio G, eds. Proc. of the Int’l

Conf. on Grid and Cloud Database Management. Berlin: Springer-Verlag, 2011. 109?131. [doi: 10.1007/978-3-642-20045-8_6] [13] Chen C, Chen G, Jiang DW, Ooi BC, Vo HT, Wu S, Xu QQ. Providing scalable database services on the cloud. In: Chen L,

Triantafillou P, Suel T, eds. Proc. of the 11th Int’l Conf. on Web Information Systems Engineering (WISE 2010). Berlin: Springer-Verlag, 2010. 1?19. [doi: 10.1007/978-3-642-17616-6_1]

[14] DeCandia G, Hastorun D, Jampani M, Kakulapati G, Lakshman A, Pilchin A, Sivasubramanian S, Vosshall P, Vogels W. Dynamo:

Amazon’s highly available key-value store. In: Bressoud TC, Kaashoek MF, eds. Proc. of the 21st ACM Symp. on Operating Systems Principles (SOSP 2007). New York: ACM Press, 2007. 205?220. [doi: 10.1145/1294261.1294281]

[15] Chang F, Dean J, Ghemawat S, Hsieh WC, Wallach DA, Burrows M, Chandra T, Fikes A, Gruber RE. Bigtable: A distributed

storage system for structured data. In: Proc. of the 7th Symp. on Operating Systems Design and Implementation (OSDI 2006).

Seattle: USENIX Association, 2006. 205?218.

[16] Ghemawat S, Gobioff H, Leung ST. The Google file system. In: Scott ML, Peterson LL, eds. Proc. of the 19th ACM Symp. on

Operating Systems Principles (SOSP 2003). New York: ACM Press, 2003. 29?43. [doi: 10.1145/945445.945450]

[17] Burrows M. The Chubby lock service for loosely coupled distributed systems. In: Proc. of the 7th Symp. on Operating Systems

Design and Implementation (OSDI 2006). Seattle: USENIX Association, 2006. 335?350.

[18] Gonzalez H, Halevy AY, Jensen CS, Langen A, Madhavan J, Shapley R, Shen WR, Goldberg-Kidon J. Google fusion tables: Web-

centered data management and collaboration. In: Elmagarmid AK, Agrawal D, eds. Proc. of the ACM SIGMOD Int’l Conf. on Management of Data (SIGMOD 2010). New York: ACM Press, 2010. 1061?1066. [doi: 10.1145/1807167.1807286]

[19] Cryans JD, April A, Abran A. Criteria to compare cloud computing with current database technology. In: Dumke RR, Braungarten

R, Büren G, Abran A, Cuadrado-Gallego JJ, eds. Proc. of the Int’l Conf. on Software Process and Product Measurement (IWSM/ Metrikon/Mensura 2008). Berlin: Springer-Verlag, 2008. 114?126. [doi: 10.1007/978-3-540-89403-2_11]

[20] Dean J, Ghemawat S. MapReduce: Simplified data processing on large clusters. In: Proc. of the 6th Symp. on Operating Systems

Design and Implementation (OSDI 2004). Seattle: USENIX Association, 2004. 137?150.

[21] Cooper BF, Ramakrishnan R, Srivastava U, Silberstein A, Bohannon P, Jacobsen HA, Puz N, Weaver D, Yerneni R. Pnuts:

Yahoo!’s hosted data serving platform. Proc. of the VLDB Endowment, 2008,1(2):1277?1288. [doi: 10.1145/1454159.1454167] [22] Curino C, Jones EPC, Popa RA, Malviya N, Wu E, Madden S, Balakrishnan H, Zeldovich N. Relational cloud: A database service

for the cloud. In: Proc. of the 5th Biennial Conf. on Innovative Data Systems Research (CIDR 2011). 2011. 235?240. http://www.

https://www.doczj.com/doc/9a13457946.html,

[23] Das S, Agrawal D, Abbadi AE. G-Store: A scalable data store for transactional multi key access in the cloud. In: Hellerstein JM,

Chaudhuri S, Rosenblum M, eds. Proc. of the 1st ACM Symp. on Cloud Computing (SoCC 2010). New York: ACM Press, 2010.

163?174. [doi: 10.1145/1807128.1807157]

[24] Hacigümüs H, Tatemura J, Hsiung WP, Moon HJ, Po O, Sawires A, Chi Y, Jafarpour H. CloudDB: One size fits all revived. In:

Proc. of the 6th World Congress on Services (SERVICES 2010). New York: IEEE Computer Society, 2010. 148?149. [doi:

10.1109/SERVICES.2010.96]

[25] Stonebraker M. Technical perspective—One size fits all: An idea whose time has come and gone. Communications of the ACM,

2008,51(12):76. [doi: 10.1145/1409360.1409379]

[26] The architecture of HBase. https://www.doczj.com/doc/9a13457946.html,/book.html#architecture

[27] The architecture of SQL Azure. https://www.doczj.com/doc/9a13457946.html,/wiki/SQL_Azure

[28] Browne J. Brewer’s CAP theorem. 2009. https://www.doczj.com/doc/9a13457946.html,/article/viewer/brewers-cap-theorem

[29] Gilbert S, Lynch NA. Brewer’s conjecture and the feasibility of consistent, available, partition-tolerant Web services. SIGACT

News, 2002,33(2):51?59. [doi: 10.1145/564585.564601]

林子雨等:云数据库研究1165

[30] Abadi DJ. Data management in the cloud: limitations and opportunities. IEEE Data Engineering Bulletin, 2009,32(1):3?12.

[31] Islam MA, Vrbsky SV. Tree-Based consistency approach for cloud databases. In: Proc. of the 2nd Int’l Conf. on Cloud Computing

(CloudCom 2010). New York: IEEE Computer Society, 2010. 401?404. [doi: 10.1109/CloudCom.2010.87]

[32] Chohan N, Bunch C, Krintz C, Nomura Y. Database-Agnostic transaction support for cloud infrastructures. In: Liu L, Parashar M,

eds. Proc. of the IEEE Int’l Conf. on Cloud Computing (CLOUD 2011). New York: IEEE Computer Society, 2011. 692?699. [doi:

10.1109/CLOUD.2011.111]

[33] Kraska T, Hentschel M, Alonso G, Kossmann D. Consistency rationing in the cloud: Pay only when it matters. Proc. of the VLDB

Endowment, 2009,2(1): 253?264.

[34] Lomet DB, Fekete A, Weikum G, Zwilling MJ. Unbundling transaction services in the cloud. In: Proc. of the 4th Biennial Conf. on

Innovative Data Systems Research (CIDR 2009). 2009. 1?10. https://www.doczj.com/doc/9a13457946.html,

[35] Afrati FN, Ullman JD. Optimizing joins in a map-reduce environment. In: Manolescu I, Spaccapietra S, Teubner J, Kitsuregawa M,

Léger A, Naumann F, Ailamaki A, ?zcan F, eds. Proc. of the 13th Int’l Conf. on Extending Database Technology (EDBT 2010).

New York: ACM Press, 2010. 99?110. [doi: 10.1145/1739041.1739056]

[36] Pavlo A, Paulson E, Rasin A, Abadi DJ, DeWitt DJ, Madden S, Stonebraker M. A comparison of approaches to large-scale data

analysis. In: ?etintemel U, Zdonik SB, Kossmann D, Tatbul N, eds. Proc. of the ACM SIGMOD Int’l Conf. on Management of Data (SIGMOD 2009). New York: ACM Press, 2009. 165?178. [doi: 10.1145/1559845.1559865]

[37] BSP Worldwide. Co-Ordinating bulk synchronous parallel computing. https://www.doczj.com/doc/9a13457946.html,

[38] Condie T, Conway N, Alvaro P, Hellerstein JM, Gerth J, Talbot J, Elmeleegy K, Sears R. Online aggregation and continuous query

support in MapReduce. In: Elmagarmid AK, Agrawal D, eds. Proc. of the 2010 ACM SIGMOD Conf. on Management of Data (SIGMOD 2010). New York: ACM Press, 2010. 1115?1118. [doi: 10.1145/1807167.1807295]

[39] Aboulnaga A, Salem K, Soror AA, Minhas UF, Kokosielis P, Kamath S. Deploying database appliances in the cloud. IEEE Data

Engineering Bulletin, 2009,32(1):13?20.

[40] Das S, Nishimura S, Agrawal D, Abbadi AE. Albatross: Lightweight elasticity in shared storage databases for the cloud using live

data migration. Proc. of the VLDB Endowment, 2011,4(8):494?505.

[41] Cecchet E, Singh R, Sharma U, Shenoy PJ. Dolly: Virtualization-driven database provisioning for the cloud. In: Petrank E, Lea D,

eds. Proc. of the 7th Int’l Conf. on Virtual Execution Environments (VEE 2011). New York: ACM Press, 2011. 51?62. [doi:

10.1145/1952682.1952691]

[42] Xiong PC, Chi Y, Zhu SH, Moon HJ, Pu C, Hacigümüs H. Intelligent management of virtualized resources for database systems in

cloud environment. In: Abiteboul S, B?hm K, Koch C, Tan KL, eds. Proc. of the 27th Int’l Conf. on Data Engineering (ICDE 2011). New York: IEEE Computer Society, 2011. 87?98. [doi: 10.1109/ICDE.2011.5767928]

[43] Rogers J, Papaemmanouil O, ?etintemel U. A generic auto-provisioning framework for cloud databases. In: Proc. of the 4th Int’l

ICDE Workshop on Ranking in Databases (DBRank 2010). New York: IEEE Computer Society, 2010. 63?68. [doi: 10.1109/ ICDEW.2010.5452746]

[44] Cooper BF, Silberstein A, Tam E, Ramakrishnan R, Sears R. Benchmarking cloud serving systems with YCSB. In: Hellerstein JM,

Chaudhuri S, Rosenblum M, eds. Proc. of the 1st ACM Symp. on Cloud Computing (SoCC 2010). New York: ACM Press, 2010.

143?154. [doi: 10.1145/1807128.1807152]

[45] Shi YJ, Meng XF, Zhao J, Hu XM, Liu BB, Wang HP. Benchmarking cloud-based data management systems. In: Meng XF, Chen

Y, Xu JL, Lu JH, eds. Proc. of the 2nd Int’l CIKM Workshop on Cloud Data Management (CloudDB 2010). New York: ACM Press, 2010. 47?54. [doi: 10.1145/1871929.1871938]

[46] Kossmann D, Kraska T, Loesing S. An evaluation of alternative architectures for transaction processing in the cloud. In:

Elmagarmid AK, Agrawal D, eds. Proc. of the ACM SIGMOD Int’l Conf. on Management of Data (SIGMOD 2010). New York: ACM Press, 2010. 579?590. [doi: 10.1145/1807167.1807231]

[47] Wang JB, Wu S, Gao H, Li JZ, Ooi BC. Indexing multi-dimensional data in a cloud system. In: Elmagarmid AK, Agrawal D, eds.

Proc. of the ACM SIGMOD Int’l Conf. on Management of Data (SIGMOD 2010). New York: ACM Press, 2010. 591?602. [doi:

10.1145/1807167.1807232]

1166 Journal of Software软件学报 V ol.23, No.5, May 2012

[48] Elmore AJ, Das S, Agrawal D, Abbadi AE. Zephyr: Live migration in shared nothing databases for elastic cloud platforms. In:

Sellis TK, Miller RJ, Kementsietsidis A, Velegrakis Y, eds. Proc. of the ACM SIGMOD Int’l Conf. on Management of Data (SIGMOD 2011). New York: ACM Press, 2011. 301?312. [doi: 10.1145/1989323.1989356]

[49] Wang HZ, Li JZ, Wang JB, Gao H. Dirty data management in cloud database. In: Fiore S, Aloisio G, eds. Proc. of the Int’l Conf.

on Grid and Cloud Database Management. Berlin: Springer-Verlag, 2011. 133?150. [doi: 10.1007/978-3-642-20045-8_7]

[50] Thakar A, Szalay AS, Church K, Terzis A. Large science databases—Are cloud services ready for them? Scientific Programming,

2011,19(2-3):147?159. [doi: 10.3233/SPR-2011-0325]

[51] Thakar A, Szalay AS. Migrating a (large) science database to the cloud. In: Hariri S, Keahey K, eds. Proc. of the 19th ACM Int’l

Symp. on High Performance Distributed Computing (HPDC 2010). New York: ACM Press, 2010. 430?434. [doi: 10.1145/1851476.

1851539]

附中文参考文献:

[1] 陈康,郑纬民.云计算:系统实例与研究现状.软件学报,2009,20(5):1337?1348. https://www.doczj.com/doc/9a13457946.html,/1000-9825/3493.htm [doi:

10.3724/SP.J.1001.2009.03493]

[3] 冯登国,张敏,张妍,徐震.云计算安全研究.软件学报,2011,22(1):71?83. https://www.doczj.com/doc/9a13457946.html,/1000-9825/3958.htm [doi: 10.3724/

SP.J.1001.2011.03958]

林子雨(1978-),男,吉林柳河人,博士,讲师,CCF会员,主要研究领域为数据库,实时主动数据仓库,数据挖掘.

谢怡(1979-),女,博士,讲师,CCF会员,主要研究领域为网络性能优化和安全技术,系统建模与仿真,软件开发

.

赖永炫(1981-),男,博士,讲师,主要研究

领域为数据库,传感器网络数据管理.

邹权(1982-),男,博士,讲师,主要研究领

域为生物信息学,大规模数据挖掘.

林琛(1982-),女,博士,讲师,CCF会员,主

要研究领域为数据挖掘,信息检索,社会网

络分析.

腾讯云的品牌资质分析报告

“腾讯云”品牌资质分析报告 尊敬的用户: 随着经济全球化的深入发展,各市场领域的竞争已逐渐表现为品牌竞争。根据中国互联网络信息中心(CNNIC)公布的最新数据显示,中国网民规模已达8.02亿,互联网普及率57.7%。而网民规模增长的推动力正是由于互联网商业模式的不断创新以及线上线下服务融合的加速,因此,互联网时代的到来也意味着网络品牌标识的价值提升。习总书记不断强调知识产权战略的重要性,同时每年5月10日“中国品牌日”的确立也标志着品牌建设与保护已经刻不容缓。 根据您查询的“腾讯云”品牌,及“网络服务-网络建站,商务服务-市场营销”行业,腾讯云的品牌分析报告如下: 目录 一、腾讯云品牌商标分析 1、行业注册分析 1.1 网络服务-网络建站行业注册分析 1.1.1 网络服务-网络建站行业品牌注册量 1.1.2 腾讯云品牌在网络服务-网络建站行业的主要注册情况 1.1.3 网络服务-网络建站行业下腾讯云同名品牌的主要竞争对手 1.2 商务服务-市场营销行业注册分析 1.2.1 商务服务-市场营销行业品牌注册量 1.2.2 腾讯云品牌在商务服务-市场营销行业的主要注册情况 1.2.3 商务服务-市场营销行业下腾讯云同名品牌的主要竞争对手 2、腾讯云品牌商标注册分析 2.1 网络服务-网络建站,商务服务-市场营销行业类别分析 2.2 腾讯云品牌在网络服务-网络建站,商务服务-市场营销行业的保护现状 3、腾讯云品牌字样在各行业的注册情况表 二、腾讯云品牌域名分析 1、全球知名品牌案例 2、腾讯云品牌域名匹配分析 3、品牌域名注册概况 4、Typo域名

“腾讯云”品牌在网络服务-网络建站行业,主要注册了以下几个类别:1、42类

云数据库

云数据库:放眼无穷处 [11-27 17:51:08]作者:王翔责任编辑:heyaorong 作为广义云计算的一种高级应用,云数据库蕴含着前所未有的数据服务交付能力。它倡导类似于自来水取用一般的服务机制,在理想状态下,它能够支持无限的并发用户,提供永不枯竭的数据应用资源。 作为企业IT系统的核心部件之一,数据库承载着最重要的信息资产——数据。不过,随着时间的推移、业务的拓展,越来越多的企业发觉正在逐渐失去对数据的控制力。数据形态的多元化、数据容量如脱缰野马般的爆炸性增长,让企业的数据环境接近容量的极限。与此同时,数据的维护于管理工作日益繁重,DBA(数据库管理员)们日复一日地在备份、优化、扩容、高可用的工作间往复循环。 如何解决数据容量激增与管理任务繁琐的矛盾?最近一段时间被业内各界大肆追捧的云计算技术或许担当拯救者的角色。通过营造服务型的数据库应用环境,立足于“云”之上的数据库系统有望被赋予全新的数据服务交付能力。 云计算与云数据库 作为一种基于互联网的超级计算模式,云计算同时也构建起一种全新的商业模式。云计算使用的硬件设备主要是成堆的服务器,企业和个人用户可以通过互联网获取计算能力,未来也可能出现一些超大型企业内容通过广域网获得计算能力的模式。这种运算模式从表面看是避免了大量的硬件投资,更深层次的优势是对运维成本的节省。其基本原理为,通过使计算分布在大量的分布式计算机上,而非本地计算机或远程服务器中,从而为更大范围的用户提供“足够用”的计算能力。 虽然运行方式存在很大差别,但与现有的应用一样,云环境下计算的主要对象仍是数据,因此“云+数据库”的结合产生了两种模式。一种模式为运行在“云”中的DBaas(即Database as a Service)。另一种模式为云数据库(即CloudDB,或者简称为“云库”)。 比较而言,DBaas更接近于关系数据库管理系统(RDBMS)。实施方面,我们跟运营商说需要一个运行在云中的数据库实例,MySQL也好、Oracle也好,他们基于云存储体系完成后提供给我们一个连接许可,然后我们使用这个实例即可。 反观云数据库,其与现有的RDBMS存在较大差别,虽然都是关系数据模型,但我们不应该也无法做出其是MySQL还是Oracle的假设,它就是一系列的二维表格,操作方式也是基于简化版本的类SQL或访问对象。 虽然云数据库看似相对“简陋”,但在使用上它的扩展性却更好。因为数据库实例对于并发用户的支持是有限的,即便是在基于近乎无限的云存储环境中进行操作;而云数据库的使用就

云计算与数据库

云计算基础知识 公有云:公有云通常指第三方提供商用户能够使使用的云,公有云一般可通过Internet 使用。能够以低廉的价格,提供有吸引力的服务给最终用户,创造新的业务价值,公有云作为一个支撑平台,还能够整合上游的服务(如增值业务, 广告)提供者和下游最终用户,打造新的价值链和生态系统。 私有云:私有云是为一个客户单独使用而构建的,因而提供对数据、安全性和服务质量的最有效控制。该公司拥有基础设施,并可以控制在此基础设施上部署应用程序的方式。私有云可部署在企业数据中心的防火墙内,也可以将它们 部署在一个安全的主机托管场所。 私有云可由公司自己的IT 机构,也可由云提供商进行构建。在此“托管式专用”模式中,像DMT这样的云计算提 供商可以安装、配置和运营基础设施,以支持一个公司企业数据中心内的专用云。此模式赋予公司对于云资源使 用情况的极高水平的控制能力,同时带来建立并运作该环境所需的专门知识。 企业云:一种基于云计算的,满足企业高扩展性、高可用性、组织和业务快速变更,实现企业协同管理,满足企业扩X、创新升级需求的平台技术框架。随着产业链整合、市场竞争日趋全球化,企业的需求和用户的消费习惯都在改变, 企业需要提供简单、快捷的商务云计算服务来满足企业扩X、产业链整合及创新升级的需要。 SaaS:SaaS提供商为企业搭建信息化所需要的所有网络基础设施及软件、硬件运作平台,并负责所有前期的实施、后期的维护等一系列服务,企业无需购买软硬件、建设机房、招聘IT人员,即可通过互联网使用信息系统。就像打 开自来水龙头就能用水一样,企业根据实际需要,从SaaS提供商租赁软件服务。 IaaS:I aaS提供给消费者的服务是对所有设施的利用,包括处理、存储、网络和其它基本的计、算资源,用户能够部署和运行任意软件,包括操作系统和应用程序。消费者不管理或控制任何云计算基础设施,但能控制操作系统的选 择、储存空间、部署的应用,也有可能获得有限制的网络组件(例如,防火墙,负载均衡器等)的控制。PaaS:P aas提供给消费者的服务是把客户采用提供的开发语言和工具(例如Java,python, .Net等)开发的或收购的应用程序部署到供应商的云计算基础设施上去。客户不需要管理或控制底层的云基础设施,包括网络、服务器、 操作系统、存储等,但客户能控制部署的应用程序,也可能控制运行应用程序的托 云计算:关系数据库你就要被淘汰了.enet../cio/ 2010年10月24日10:11 来源:网界网字号:小| 大 【文章摘要】这些数据库具有一些共同特征,正是这些特征使它们特别适用于服务云计算式的应用。它们中的大多数可以在分布式环境中运行----意味着他们可以分布在多个地点的多台服务器上。它们本质上都不是事务性的,并且都牺牲了一些高级查询能力以换取更好的性能。(在很多情况下,这些数据库可以通过对象调用来检索,而不用SQL,无论如何,对程序员来说,前者更自然些)。 “在云计算计划里将找不到关系数据库的影子,这并非偶然,因为关系数据库不适合用于云计算环境“Geir Magnusson,10Gen工程副总裁这样认为。10Gen是一家按需平台服务供应商。 Magnusson帮助编写过Apache Geronimo应用服务器软件,本周在纽约举行的O'Reilly Web 2.0 会议上发言中他指出:“云计算是一种不同的技术,不同得足够改变开发者看待问题和解决问题的方式”。“我们将不得不重新审视我们做事的方式”,他说。 在发言期间,Magnusson列举了许多被专门开发用于云计算环境的新型数据库,包括

腾讯云-TDSQL分布式数据库服务概述

TDSQL分布式数据库服务 产品概述

目录 产品简介产品概述 (4) 简介 (4) 解决问题 (4) 单机数据库瓶颈 (4) 应用层分片开发工作量大 (4) 开源方案或 NoSQL 难题 (4) 产品优势 (6) 超高性能 (6) 专业可靠 (6) 简单易用 (6) 应用场景 (7) 大型应用(超高并发实时交易场景) (7) 物联网数据(PB 级数据存储访问场景) (7) 文件索引(万亿行数据毫秒级存取) (7) 高性价比商业数据库解决方案 (7) 基本原理水平分表 (9) 概述 (9) 水平切分 (9) 写入数据( SQL 语句含有 shardkey ) (11) 数据聚合 (12) 读取数据(有明确 shardkey 值) (12) 读取数据(无明确 shardkey 值) (12) 读写分离 (14) 功能简介 (14) 基本原理 (14) 只读账号 (14) 弹性拓展 (15) 概述 (15) 扩容过程 (15) 新增分片扩容 (15) 现有分片扩容 (15) 强同步 (17)

背景 (17) 存在问题 (17) 解决方案 (17) 实例架构 (19) 地域选择 (20)

产品简介 产品概述 19-11-19 10:36:08 简介 分布式数据库 TDSQL(TencentDB for TDSQL,TDSQL)是部署在腾讯云上的一种支持自动水平拆分、Shared Nothing 架构的分布式数据库。分布式数据库即业务获取的是完整的逻辑库表,而后端会将库表均匀的拆分到多个物理分片节点。TDSQL 默认部署主备架构,提供容灾、备份、恢复、监控、迁移等全套解决方案,适用于 TB 或 PB 级的海量数据库场景。 解决问题 单机数据库瓶颈 面对互联网类业务百万级以上的用户量,单机数据库由于硬件和软件的限制,数据库在数据存储容量、访问容量、容灾等方面都会随着业务的增长而到达瓶颈。 TDSQL 目前单分片最大可支持6TB存储,如果性能或容量不足以支撑业务发展时,在控制台自动升级扩容。升级过程中,您无需关心分布式系统内的数据迁移,均衡和路由切换。升级完成后访问 IP 不变,仅在自动切换时存在秒级闪断,您仅需确保有重连机制即可。 应用层分片开发工作量大 应用层分片将业务逻辑和数据库逻辑高度耦合,给当前业务快速迭代带来极大的开发工作量。 基于 TDSQL 透明自动拆分的方案,开发者只需要在第一次接入时修改代码,后续迭代无需过多关注数据库逻辑,可以极大减少开发工作量。 开源方案或 NoSQL 难题 选择开源或 NoSQL 产品也能够解决数据库瓶颈,这些产品免费或者费用相对较低,但可能有如下问题: 产品 bug 修复取决于社区进度。 您的团队是否有能持续维护该产品的人,且不会因为人事变动而影响项目。 关联系统是否做好准备。 您的业务重心是什么,投入资源来保障开源产品的资源管控和生命周期管理、分布式逻辑、高可用部署和切换、容灾备份、自助运维、疑难排查等是否是您的业务指标。

五款最常见的云数据库

五款最常见的云数据库 对于SQL Server用户,你可能已经知道Windows Azure SQL Database(原名SQL Azure)这一微软的云数据库。事实上除了SQL Database之外,还有很多关系型或者非关系型的数据库云服务。在本文中,我们就将为您总结五款最常见的云数据库,可以根据您的具体情况选择不同的服务。 亚马逊AWS 亚马逊关系型数据库服务(RDS)是最早一批基于云的数据库服务,它也是由Amazon Web Services(AWS)提供的首个数据库服务。在RDS基础之上,你可以部署Oracle、MySQL或是SQL Server数据库实例,同时使用标准存储或是Provisional IOPS存储,并且它还针对I/O密集型工作负载进行了优化。RDS还给你了这样的选择,就是使用亚马逊虚拟私有云服务来隔离你的数据库实例。此外,你还可以利用亚马逊CloudWatch Service来查看实例的关键运行指标。 当然AWS也有自己的云数据库产品,包括DynamoDB、Redshift以及SimpleDB,它们目前都是作为公共测试服务提供的。DynamoDB是一个NoSQL数据库服务,其所有的数据是存储在固态硬盘上的并复制到三个可用站点,这使其成为了一个快速而且高可用的系统。Redshift 是一个数据仓库服务,它使用列存储技术结合了分布式,并行查询所支持的数据集,范围从GB级别到PB级别甚至更多。而SimpleDB服务提供了一个非关系型,非模式化的数据存储,通过简单查询可以访问小字符数据集。 除了以上四项数据库服务,AWS还为迁移和处理数据提供了Data Pipeline(数据管道)工作流服务,以及在缓存中维护数据的ElastiCache服务。 谷歌云平台 和Amazon一样,Google提供多种数据相关的服务。首先是Cloud SQL,它是一个基于MySQL 的关系型数据库服务,它可以作为SQL Azure的替代品。Cloud SQL是与App Engine和其他Google服务全面而紧密集成的。Cloud SQL还支持同步复制到多个站点。此外,Google还提供BigQuery服务,它是一个实时大数据分析工具,可以让你对数十亿条记录数据集执行随机查询。此服务利用Google的庞大计算能力来让你可以从TB级别的数据集中分析数据。Google产品家族的最新成员Cloud Datastore,它是一个非模式化,非关系型数据库服务,它支持ACID事务,与那些在传统关系型数据库管理系统(RDBMS)中的服务是类似的。ACID指的是用于保证可预测性和安全事务的四个属性:原子性,一致性,隔离性和持久性。Cloud Datastore服务目前提供有一个预览版并且App Engine服务使用的是相同的Datastore存储。

浅析-腾讯云数据库行业解决方案

浅析-腾讯云数据库行业解决方案在这个大数据兴起的时代,移动互联网和智能终端的普及及发展十分迅速,数据信息正以每年40%的速度增长,大家是不是经常会在处理数据的时候遇到这些问题,处理数据时间长,数据太多不易管理,担心自建数据库不安全等等,今天小编结合腾讯云市场相关资讯给大家介绍腾讯云数据库解决方案,为大家分析为什么选择腾讯云。 腾讯云数据库方案是什么? 腾讯云数据库是拥有性能卓越,弹性扩展,同时免运维,减少开发成本等优点。并为行业提供容灾、备份、恢复、监控、迁移等数据库运维全套解决方案。 首先使用腾讯云数据库具有以下优势: 1)灵活配置,快速部署:按使用场景配置,秒级快速部署数据库服务,弹性式一键升级扩容; 2)数据可靠,持续可用:多重备份保证数据可靠性,主备多活架构使数据可用性强; 3)性能卓越:超大内存和高性能读写的物理机型支撑,支持海量访问; 4)全方位服务:提供7*24 小时的问题咨询,专业解答所有疑惑,同时监控各项业务指标。 腾讯云数据库可覆盖不同行业领域的专属方案,应对各类场景需求,为了更高效完善的应用腾讯云数据库,我们需要一个围绕典型数据库使用场景下的综合解决方案——腾讯云数据库解决方案。

给大家介绍几个常见行业下场景需求的痛点: (1)游戏行业:游戏玩家数据量大,多个分区数据服务,每个分区都需要快速读取数据。 (2)金融行业:存储和处理金融交易数据、账户数据等比较繁杂,安全可靠性需求高(3)电商行业:高并发流量,活动节日大促时遭遇业务高峰,访问请求压力大,海量数据需要处理 (4)医疗:健康数据采集量大,对数据处理能力要求高 (5)大数据:存储数据量大,对计算能力要求极高,数据增长快速,对分布式数据处理能力要求高 还有其他行业需求难点等等·,而此时,使用腾讯云数据库就可以解决上述问题。 腾讯云数据库解决方案优势: (1)针对游戏行业-云数据库可以解决游戏玩家数据快速存取的问题,同时弹性的扩展能力)能轻松应对开服合服; (2)针对金融行业-云数据库可为金融行业提供安全审计,跨地域容灾,数据强一致的数据库服务,保证金融数据安全高可靠; (3)针对电商行业-云数据库CDB for MySQL高性能特性以及Redis快速读写能力帮你在活动大促时解决访问高峰带来的请求压力。 还有其他行业解决方案等等,这里就不一一介绍了,实际使用腾讯云数据库有很多复杂的问题需要解决,并且腾讯云数据库体系覆盖目前主流数据库,部署便捷,选型更佳灵活,如果您需要购买腾讯云,可关注微盛网络官网,同时与腾讯云官方优惠叠加,优惠相当于折

十大最有用的云数据库

十大最有用的云数据库 随着商业交易内所蕴含数据量的不断增加,服务提供商正在想办法让公有云的数据管理变得更加轻松。大数据正变得越来越重要,云服务提供商希望涉足企业数据库领域。研究机构IDC 预言,大数据将按照每年60%的比率增加,其中包含结构化和非结构化数据。企业需要想办法发挥这些数据的作用,而长期以来数据库就是一个非常好的解决方案。目前服务提供商正通过云技术推出更多可在公有云中托管这些数据库的方法,将用户从繁琐的数据库硬件定制中解放出来,同时让用户拥有数据库扩展能力。研究公司Wikibon的大数据研究专家Jeff Kelly说:“这是一个非常大的市场。云将是许多大数据的最终目的地。”当然在DBaaS(数据库即服务)中仍然存在着许多问题,尤其是关于存储在云上的敏感信息,以及云服务中断等问题。不过,云数据库和工具这一新兴市场明显在加速发展。以下是美国《Network World》所关注的10个云数据库工具。其中一些是直接关系型数据库、SQL或者NoSQL数据库提供商,还有一些则将重点放在了开源数据库上。当然这里列出的10个云数据库不可能面面俱到,像甲骨文、惠普以及EMC/VMware这些大型的市场参与者也已经推出了他们各自基于云的产品,以及针对这些工具的策略。1.亚马逊Web服务(AWS)亚马逊Web服务(AWS)拥有多种基于云的数据库服务,包括关系型数据库和非关系型数据库。亚马逊关系型数据库(RDS)能够运行MySQL、甲骨文以及SQL Server等多种实例,而亚马逊简单数据库(Amazon SimpleDB)则是一种专门针对小工作负载的非模式化数据库。在NoSQL方面,Amazon DynamoDB是一种支持固态硬盘的数据库,它能够自动在至少3个可用空间中复制工作负载。亚马逊Web服务的CTO Wemer Vogles表示,DynamoDB是亚马逊Web服务历史上增速最快的服务。此外,亚马逊还发布了一些辅助的数据管理服务,例如最新发布的Redshift数据仓库,以及能够帮助用户整合多来源数据以方便管理的Data Pipeline。 2.EnterpriseDBEnterpriseDB将重点放在了开源的PostgreSQL数据库上,不过让它名声鹊起的原因却是其与甲骨文数据库应用协同工作的能力。通过使用EnterpriseDB的Postgres Plus Advance Server,用户可以通过EnterpriseDB的使用为本地甲骨文数据库编写的应用。目前EnterpriseDB已能够在惠普和亚马逊Web服务的云服务上运行。此外,EnterpriseDB 还具备二元复制及定期备份等功能。 3.Garantia DataGarantia为用户提供了一个网关服务,通过这个服务,用户可以在亚马逊Web服务公有云上运行开源的Redis和Memcached内存非关系数据库服务。Garantia软件可以帮助开发者为这些开源数据平台自动扩展节点,创建集群以及容错模型。 4.谷歌Cloud SQL谷歌的云数据库服务主要集中在谷歌Cloud SQL和BigQuery这两大产品上。前者被谷歌描述了一种类似MySQL的完全关系型数据库基础设施,而BigQuery则被塑造成在谷歌的云基础设施上运行大数据集查询的分析工具。 5.微软Azure 微软利用其SQL Server技术研发了一个关系型数据库,允许用户直接访问云中SQL数据库,或者在虚拟主机中托管SQL服务器实例。微软对混合型数据库也非常关注,该公司使用SQL Data Sync整合了用户本地及Azure云上的数据。微软还拥有一个名为Tables的服务,这一基于云的NoSQL数据库服务采用了Blobs(二进制大对象存储)算法,并专门针对视频和音频等媒体文件进行了优化。 6.MongoLab在NoSQL的世界中,有各种各样的数据库平台可以选择,其中包括MongoDB。MongoLab允许用户通过亚马逊Web服务、微软Azure和Joyent等大型云服务提供商访问MongoDB。与其他网关类型服务一样,MongoLab同样在应用层整合了多种PaaS(平台即服务)工具。MongoLab既可以在共享的环境中访问,也可以在专用的环境中运行,不过后者的开销通常比前者稍大一些。 7.Rackspace通过名为“Cloud Databases”的产品,Rackspace的数据库既可以成为一个云,也可以成为一个托管服务解决方案。Rackspace将重点放在了Cloud Databases基于容器的虚拟化上,他们认为这将赋予数据库服务远甚于基于纯虚拟化基础设施的性能。Cloud Databases还以OpenStack

Oracle云数据库实施方案

Oracle云数据库实施方案

————————————————————————————————作者:————————————————————————————————日期:

Oracle 私有云架构解决方案 一、解决方案概览 现在中国移动已经建立了自己基于Openstack标准的底层IaaS云架构,已经可以通过这种架构满足自身的企业级私有云架构需求同时为多种行业的企业级用户提供标准的软件基础架构。但是一直以来都没有一个完整的方案可以为自己和企业级客户提供标准的PaaS服务,主要包括数据库服务和中间件服务。并且希望这种方案是对现有中国移动IaaS架构的一种扩展而不是重新开发部署一套新的系统,并且要求新增加的功能可以统一的通过现有的中国移动云平台进行集中的管理和调度,也就是说新增加的功能可以对外开放基于Openstack标准的调用API,通过调用这样API可以实现PaaS层的相关管理和计费功能。 二、Oracle EM功能介绍 Oracle EM是业界第一的企业级应用管理平台,可以集中的实现企业级从底层磁盘到上层的应用的监控和管理、多个层次的系统快速部署、优化、计费等核心功能,并且可以用于企业公有云和私有云的集中管理,从而满足企业级用户混合云架构的需求。Oracle的EM 的一个重要功能是实现企业级的云管理,包括满足客户在本地、私有云和Oracle 公有云建立、部署、管理应用的需求。在实现丰富灵活的企业级监控、管理的前提下最大化的实现整个流程的可视化和管理灵活性并且采用标准的IT标准和协议可以非常灵活的融入企业现有的IT 架构中。总结一下EM在云管理方面主要实现了以下的四个功能: 数据库云服务 快速的建立新的数据库,实现多个数据库的融合,并提供丰富的管理功能。比如通过快照复制和RMAN备份快速的建立数据库云服务。 中间件云服务 所有的中间件产品的云化,快速的建立中间件云服务,实现快捷的应用运行环境部署和丰富的监控管理功能 IaaS云服务 通过简单的点击、配置快速的实现IaaS环境的搭建并提供丰富的管理功能。 混合云管理 Oracle EM丰富的管理和监控功能,全面的对本地环境、公有云环境的监控和管理,通过单一平台实现全面的管理和监控。 三、使用Oracle EM 实现私有PaaS-----Oracle数据库云 通过使用Oracle Enterprise Manager 客户可以对本地和云端的Oracle环境进行统一的管理。EM已经和Oracle的核心产品做了深度的融合、可以实现全环境的自动化的监控和管理,包括了从数据库、中间件和硬件的管理。客户通过使用这个平台简化的管理、开发、运维工作,极大了降低了整体的系统运维成本。 使用EM的数据库云管理包,可以实现全数据库云生命周期的管理,从资源的分配、基于规则的访问配置、服务等级分类到计费的全部管理功能。它容易用户申请数据库服务、根据需要进行消费;它也容许根据应用的需要进行资源的缩放。最后,它容许管理人员和消费客户全面的的了解所有的成本和支出。

腾讯云-智能钛工业AI平台概述

智能钛工业 AI 平台 产品概述

目录 智能钛工业 AI 平台 (1) 产品简介产品概述 (3) 产品功能 (3) 产品优势 (4) AI 训练系统 (4) AI 推理系统 (4) 应用场景 (6)

产品简介 产品概述 19-07-08 16:30:25 智能钛工业 AI 平台(Tencent Intelligence Industry Insight,TI-Insight,以下简称平台)是基于智能钛基础功能打造的一站式工业 AI 平台。它包含了 AI 训练系统,AI 推理系统两个功能组件。平台提供了包含数据工厂、内置通用和行业算法库、模型迭代训练引擎、基于题库测试的模型评估引擎、多版本模型对比分析、模型微服务管理和部署、硬件资源优化调度与管理等全栈 AI 能力。支持算法工程师、及具备有限深度学习知识的业务用户可以从0到1快速构建模型、1到 N 快速迭代训练模型。同时,平台提供优化调度算法微服务能力,可以帮助团队快速地部署模型,高效利用硬件计算资源,提高生产力。 产品功能 AI 训练系统 提供数据集管理、新建模型、模型迭代提升、模型在线评估、题库测试、结果分析和洞察、内置通用/行业/定制算法等功能,通过AI 训练系统可持续提升模型精度,在上线后短时间内就可以达到相当稳定的运行精度,识别速度高、准确率好、效率高。 AI 推理系统 提供微服务部署、运行管理、CPU/GPU 资源管理、请求负载均衡、服务高可用、计算实例自动扩缩容等功能。

产品优势 19-07-08 15:27:44 智能钛工业 AI 平台(TI-Insight)包括 AI 训练系统和 AI 推理系统两个业务模块: AI 训练系统 简单易用,快速上手 功能界面简洁清晰,集数据管理、模型训练、评估、预测和结果洞察于一体,覆盖全工作流程,形成模型训练的完整闭环,操作流程方便易用,基于内置的算法工具集和直观的操作指导可以让业务专家无需具备编程或深度学习的专业知识就可以创建出业务模型。 全面提高线上生产能力 内置了一体化的训练集和题库集管理工具,以及自动化模型迭代环境,可以将原有模型快速迭代更新,适应生产中不断出现的新变化,紧密贴合实际生产业务的需求,大幅提高生产能力。 强大的算法通用化能力 提供多种通用/行业/定制算法镜像,可适应不同行业客户需求。用户可基于此进行模型训练,为算法工程师免除定制化模型开发之苦。 开放式平台 在内置的算法包不满足客户需求情况下,客户或实施合作伙伴根据可以根据软件提供的算法包封装文档在短短数周内就封装出一个定制算法,并且能导入到平台中用来训练出新的业务模型。 集成方便,部署灵活 可将模型一键部署至 AI 推理系统,用户可以脱离线下人工部署的繁琐流程和操作,只需关注于模型的优化迭代。 系统可靠,维护成本低 采用腾讯云容器服务 TKE 进行训练,具备稳定的运行性能,可进行服务架构的快速升级,安全可靠,性价比高。AI 推理系统 异构算力虚拟化 GPU 算力虚拟化,一键部署不同类型的机器学习模型和深度学习模型,为用户提供最佳推理服务。 自动弹性扩缩容

腾讯云-腾讯智慧建筑管理平台概述

腾讯智慧建筑管理平台 产品概述

目录 腾讯智慧建筑管理平台 (1) 产品简介产品概述 (3) 什么是腾讯智慧建筑管理平台 (3) 产品优势 (3) 产品功能 (5) 应用场景 (6)

产品简介 产品概述 19-07-29 10:45:47 什么是腾讯智慧建筑管理平台 腾讯智慧建筑管理平台(Smart Building Operating System,以下简称微瓴)是深度适配智慧建筑场景的物联网类操作系统,针对建筑内的硬件、应用等资源,提供物联、管理与数字服务,为建筑赋予了综合协同智慧能力,并为建筑管理运营者与建筑业主方提供安全、高效、便利的建筑综合管理运营系统,助力地产行业数字化和智能化转型,提升建筑的运营效率与服务品质,创造全新的服务模式与用户体验。 产品优势 联动灵活性高 用户可根据自身业务,搭建多样化的建筑联动规则。 建筑监管度高 腾讯云微瓴对建筑内的设备、应用、用户、场景进行统一监管,打破用户盲区。 物联能力丰富化 硬件:支持 SDK、MQTT、智能网关、软网关等快速对接方式。 应用:支持各行业的数据对接协议、权限对接协议、硬件控制协议等。 服务:支持 API 对接服务。 空间数字化 腾讯云微瓴实现了建筑、楼层、设备点位与空间映射的数字化,让建筑变成一个智慧空间,可以衍生出丰富标准的空间能力与空间服务。 建筑智能化 腾讯云微瓴通过融合多样 AI 算法,实现建筑智慧化响应与决策。 升级持续化 腾讯云微瓴支持云端持续升级与软硬件分离,且建筑的各项软、硬件服务都支持组态化的拆卸升级,实现建筑服务的优质灵活更换。

运营管理智慧化 增强系统之间的关联性,解决业务系统彼此孤立的问题,提高建筑运营效率,降低运营成本。业务数据沉淀与应用为建筑运营提供了数据支撑,助力建筑智慧化发展。 智能监控能帮助用户定位故障问题,缩短问题的响应时间与处理周期。

如何迁移到腾讯云

腾讯云相信大家都不陌生,作为中国云市场的几大巨头之一,腾讯云的应用范围还是非常广的,受到很多企业的青睐和认可。因此越来越多的企业选择在腾讯云上构建自己的核心业务系统,而这就涉及到一个问题,就是数据的迁移。那么如何才能将数据迁移到腾讯云上呢?今天就跟大家分享一下将数据迁移到腾讯云上的步骤和一款实用的腾讯云数据迁移软件。 将数据迁移到腾讯云和迁移到其他的云的步骤也基本相同,基于海量客户迁移的实践,它的大致步骤有如下五步: 1.评估设计:评估现有的系统架构,充分考虑对迁移的影响因素,根据评估方案作出整体迁移方案设计。

2.测试验证:通过POC 测试、性能测试验证迁移方案的可行性,确认网络带宽、迁移时长、迁移工具等方案细节。 3.环境部署:在目标部署方案中的资源,并完成相应安全策略配置,对目标环境、迁移链路做联通测试。 4.迁移上线:执行迁移操作,完成数据、文件、主机、大数据等的迁移,做完整的业务功能验证,将线上流量切换至目标环境。 5.云上优化:根据云上的监控数据和用户痛点需求,做云上的系统优化,适当考虑客户系统对于公有云模块的适配性优化。 不同的迁移工具对应了不同的使用场景,今天给大家整理的这款常用的腾讯云在线迁移工具——Smart MS:支持在线一键迁移物理服务器、虚拟机、公有云主机至腾讯云CVM,并支持多任务并行、数据增量复制,实现业务无缝切割,业务不中断。适用场景最广且操作最便捷,这是一款轻量级的迁移工具,支持任意源host飞向腾讯

云「Any Source Fly 2 Tencent Cloud」通过SmartMS能让任何人具备“云计算迁移工程师”的能力,帮助更多个人、企业用户打通通向腾讯云的“荣耀之路”。 安畅网络是中国市场专业的云托管服务商(Cloud MSP),在数据中心和云计算领域有近十年的专业交付和管理经验,目前正服务于2000多家企业级客户并与全球多家超大规模公有云服务商建立了战略合作关系。在云计算驱动产业变革的今天,安畅以客户需求为驱动,积极投资于核心技术研发和团队组织的云原生技能,致力于成为IT 新生态和产业互联网的新一代连接器。为客户提供“云+大数据+AI”的咨询、集成和管理服务,以及数字化解决方案,帮助客户利用新技术进行业务创新,实现数字化变革。

云数据库体系架构的研究

云数据库体系架构的研究 一、云技术现状 云计算(cloud computing)是IT 技术发展的最新趋势,正受到业界和学术界的广泛关注。云计算是在分布式处理、并行处理和网格计算等技术的基础上发展起来的,是一种新兴的共享基础架构的方法。它可以自我维护和管理庞大的虚拟计算资源(包括计算服务器、存储服务器、宽带资源等等),从而提供各种IT 服务。用户在使用云计算提供的服务时按需付费,这不仅降低了使用门槛,也极大地节省了开销。由于云计算存在着巨大的潜在市场,Google,IBM,Microsoft,Amazon,Sun,HP,Yahoo,Oracle 等国际知名大公司都已经涉足云计算。云计算也开始在电信、金融等需要大规模并行处理的领域得到应用,比如中国移动研究院开发的云数据挖掘平台BC-PDM和云数据库产品HugeTable。 随着云计算技术的不断升温,它对各个技术领域的影响开始显现,其中比较典型的包括数据库领域。截止到现在,传统的数据库厂商,比如Oracle,Teradata,IBM,Microsoft 等,都已经推出了基于云计算环境的相关数据库产品。原来没有从事数据库产品开发的知名大公司,比如Amazon 和Google 等,也发布了Simple DB 和Big Table等产品。 面对数据的海量存储以及需求的动态变化,传统关系型数据

库已经显得力不从心。为了满足互联网发展以及互联网用户对数据海量存储的需求,Amazon、Google、Microsoft等公司相继对云数据库管理系统进行了深入研究,并生产了自己企业的云数据库。具有代表性的云数据库有Amazon的simpleDB、Google的BigTable以及yahoo的PNUTS等。与此同时,许多云数据库的相关问题开始被关注,比如云数据库的体系架构、数据模型、事务一致性、数据安全和性能优化等等。 二、云数据库介绍 1、云数据库概述 云数据库是在SaaS(software-as-a-service:软件即服务)成为应用趋势的大背景下发展起来的云计算技术,它极大地增强了数据库的存储能力,消除了人员、硬件、软件的重复配置,让软、硬件升级变得更加容易,同时也虚拟化了许多后端功能。云数据库具有高可扩展性、高可用性、采用多租形式和支持资源有效分发等特点。可以说,云数据库是数据库技术的未来发展方向。目前,对于云数据库的概念界定不尽相同,本文采用的云数据库定义是:云数据库是部署和虚拟化在云计算环境中的数据库。 如图1 所示,在云数据库应用中,客户端不需要了解云数据库的底层细节,所有的底层硬件都已经被虚拟化,对客户端而言是透明的。它就像在使用一个运行在单一服务器上的数据库一样,非常方便、容易,同时又可以获得理论上近乎无限的存储和处理

腾讯知识图谱数据库

腾讯知识图谱数据库 产品简介 产品文档

【版权声明】 ?2013-2019 腾讯云版权所有 本文档著作权归腾讯云单独所有,未经腾讯云事先书面许可,任何主体不得以任何形式复制、修改、抄袭、传播全部或部分本文档内容。 【商标声明】 及其它腾讯云服务相关的商标均为腾讯云计算(北京)有限责任公司及其关联公司所有。本文档涉及的第三方主体的商标,依法由权利人所有。 【服务声明】 本文档意在向客户介绍腾讯云全部或部分产品、服务的当时的整体概况,部分产品、服务的内容可能有所调整。您所购买的腾讯云产品、服务的种类、服务标准等应由您与腾讯云之间的商业合同约定,除非双方另有约定,否则,腾讯云对本文档内容不做任何明示或模式的承诺或保证。

文档目录 产品简介 产品概述 应用场景

产品简介 产品概述 最近更新时间:2019-11-04 14:35:09 腾讯知识图谱(Tencent Knowledge Graph,TKG),是一个集成图数据库、图计算引擎和图可视化分析的一站式平台。在金融、安全、泛互联网、政府、企业等领域中,海量数据之间彼此关联产生了数以万亿计的数据,这种复杂的关联关系数据隐藏着大量的业务信息和商业价值。 腾讯知识图谱支持千亿级节点关系的存储和计算,准实时响应节点搜索、多跳查询、最短路径分析等在线查询操作。支持 PageRank、社群发现、相似度计算、模糊子图匹配等离线计算模型。支持高效的从异构数据中抽取融合实体和关系生成知识图谱。支持多种图结构布局和渲染等可视化方案。基于腾讯海量的社交数据和业务据进行测试和验证,为客户在各个场景的定制化需求提供一站式的解决方案。 在知识图谱研究中,有如下领域产生了20余项国内国际专利和数十篇国际领先的学术论文: 准实时响应千亿节点关系的在线查询。 高速处理超大规模图谱中子图匹配等运算。 优化图分析算法,如社区发现、PageRank 等。 产品优势 便捷的知识图谱构建 腾讯知识图谱一站式平台通过用户上传原始数据,定义知识模型,配置原始数据与知识模型之间的映射关系即可构建一个完整可用的知识图谱。用户也可以上传文本数据,系统可以自动从文本中抽取人物及其之间的关系构建知识图谱。 高效的图谱在线查询 腾讯知识图谱一站式平台使用更紧凑的数据存储和索引查找技术,对图查询操作及高级图查询可做到准实时响应,同时支持动态秒级更新和分钟级批量更新。 丰富的图计算模型 腾讯知识图谱一站式平台的离线计算功能涵盖了多种图关联算法,包括:图嵌入、图聚类、社区发现、PageRank 等批量迭代式处理算法。 多样的可视化分析方法 腾讯知识图谱一站式平台拥有丰富的图数据可视化展现方式。提供多种图结构布局和节点可视化渲染方案,支持节点多跳扩展,路径探寻分析,混合条件查询,计算结果展示等操作。直观展现数据间的复杂关系,大幅度提升知识图谱的探索效率。

基于MySQL的云数据库设计与实现

单位代码:10293密级:公开 专业学位硕士论文 论文题目:基于MySQL的云数据库设计与实现 学号1213012235 姓名牛小宝 导师钱学荣 专业学位类别工程硕士 类型全日制 专业(领域)电子与通信工程 论文提交日期2016年4月

The design and implementation of cloud database base on MySQL Thesis Submitted to Nanjing University of Posts and Telecommunications for the Degree of Master of Engineering By Xiaobao Niu Supervisor:Prof.Xuerong Qian April2016

南京邮电大学学位论文原创性声明 本人声明所呈交的学位论文是我个人在导师指导下进行的研究工作及取得的研究成果。尽我所知,除了文中特别加以标注和致谢的地方外,论文中不包含其他人已经发表或撰写过的研究成果,也不包含为获得南京邮电大学或其它教育机构的学位或证书而使用过的材料。与我一同工作的同志对本研究所做的任何贡献均已在论文中作了明确的说明并表示了谢意。 本人学位论文及涉及相关资料若有不实,愿意承担一切相关的法律责任。 研究生签名:_____________日期:____________ 南京邮电大学学位论文使用授权声明 本人授权南京邮电大学可以保留并向国家有关部门或机构送交论文的复印件和电子文档;允许论文被查阅和借阅;可以将学位论文的全部或部分内容编入有关数据库进行检索;可以采用影印、缩印或扫描等复制手段保存、汇编本学位论文。本文电子文档的内容和纸质论文的内容相一致。论文的公布(包括刊登)授权南京邮电大学研究生院办理。 涉密学位论文在解密后适用本授权书。 研究生签名:____________导师签名:____________日期:_____________

腾讯云-数据及文件迁移技术指引

数据及文件迁移技术指引

目录 COS 的迁移场景 (3) COS 的迁移方式 (3) 在线迁移 (3) 离线迁移 (4)

文件迁移指引 19-08-21 15:20:12 数据迁移支持多种场景的文件迁移,并且提供灵活的迁移工具和可靠的合作伙伴帮助用户完成迁移。腾讯云提供了多种文件存储服务:COS(对象存储)、CFS(文件存储)、CAS(归档存储),其中数据迁移在 COS 的应用相对比较广泛。本文主要介绍 COS 的迁移,关于 CFS 和 CAS 的迁移需求,请参见CFS 文档和CAS 文档。 COS 的迁移场景 1.本地文件迁移至腾讯云 COS。 2.第三方云对象存储迁移至腾讯云 COS。 COS 的迁移方式 结合用户的迁移场景,综合考虑用户的业务需求和迁移的时间成本(网络速度和存储容量)可以选择在线迁移或者离线迁移两种方式。 如果用户的存储容量不是很大(10TB以下),而且业务场景不太允许停服,可以考虑在线迁移方式。 如果用户的存储容量很大(TB - PB级别),或者带宽有限,在线迁移时间成本较高,业务场景允许停服,则可以考虑离线的迁移方式。 具体的使用的迁移方式需根据用户的实际情况选择。可参考以下建议: 在线迁移 通过腾讯云提供的 COS 相关的迁移工具进行迁移,包括本地文件上云迁移工具和第三方云迁移上云工具。为真正达到不停服迁移,用户可以参考以下的迁移流程: 1.配置好迁移工具,指定源和目标。如果是第三方云迁移至腾讯云,例如 oss、七牛或者 aws 的 s3,配置项略有不同,请严格按照工具指引操作。

2.启动迁移工具。 3.配置 CDN 和 COS。 i.已经迁移完的文件直接提供访问。 ii.配置镜像回源,未迁移过来的文件通过回源的方式提供访问,要适用于小文件。 iii.配置重定向回源,未迁移过来的文件通过配置重定向的方式,访问到源站(腾讯云提供的回源方式同时支持镜像回源和重定向回源)。 4.完整性校验,完成迁移。 离线迁移 针对大容量的TB - PB级别的迁移需求,腾讯云提供了离线的迁移工具 CDM。可参考以下方式操作: 1.根据迁移容量确定迁移设备型号和所需数量并提交在线申请。 2.收到由腾讯云寄出的专用迁移设备后,将数据拷贝至设备中。 3.在控制台提交设备回寄申请。 4.设备回寄之后,由腾讯云负责把数据拷贝至云端存储。 5.验证,完成数据迁移。

云数据库方案设计

云数据库方案设计 一、云数据库的云化改造 面向云化环境,数据库在多个方面需要进行改造,包括快捷的安装部署,提供数据库的动态伸缩和资源隔离,以及监控、迁移、备份等一体化管理,以适应云环境中自动安装部署、一体化监控管理,资源动态分配等需求。 1.快速安装及部署 1.1 一键部署和分钟级实例的创建: 1. 准备好预置数据库的docker镜像 a. 初始化好空数据目录(也支持根据场景预置数据) b. 数据库配置文件放置在docker镜像之外,通过映射的 方式进入镜像内部 2. 用户选择实例资源后(CPU、内存),系统自动计算最佳设 置 a. 用户选择实例的内存、CPU数量,使用场景(OLTP、OLAP) b. 根据用户选择,自动调整、优化参数(共享缓存、work_mem、等等)

3. 使用docker镜像加载外置配置文件启动数据 1.2 多种部署方式 1. 单机(单独的docker镜像) 2. 主备和负载均衡 a). 配置好的三个独立docker镜像,分别扮演主机、备机、读写分离节点 b). 三个节点配置文件都在外部,映射到内部运行 c). 启动时,根据用户的资源选择和网络场景,自动规划配置文件内容 3. KADB 集群 a). 根据角色配置好独立的docker镜像,分别扮演数据节点、协调器节点等 b). 节点的配置文件都放在外部,映射到内部运行 c). 根据用户设置的资源,场景,自动分配节点数量,配置节点参数. 2.在线伸缩 云环境中,支持在线调整任何一个实例使用的资源。对于数据库而言,若分配的资源,包括CPU、内存、磁盘等资源发生变化,数据库同样需要对于资源的变化实施生效。 CPU变化时,主要影响数据库的并发连接数和并行参数,在金仓

相关主题
相关文档 最新文档