第9章云计算中的数据库技术9.1Google云计算中的数据库Bigtable9.2Hadoop中的数据库HBase9.3Amazon云计算中的简单数据服务SimpleDB9.4Amazon云计算中的中的关系数据库服务RDS9.5微软云计算中的数据库SQLAzure9.1Google云计算中的数据库BigtableGoogle云计算平台技术架构分布式文件存储GFS并行数据处理MapReduce分布式锁Chubby分布式结构化数据表BigTable分布式存储系统Megastore分布式监控系统Dapper。Bigtable是一个分布式的结构化数据存储系统,它被设计用来处理海量数据:通常是分布在数千台普通服务器上的PB级的数据。Google的很多项目使用Bigtable存储数据,包括Web索引、GoogleEarth、GoogleFinance。这些应用对Bigtable提出的要求差异非常大,无论是在数据量上(从URL到网页到卫星图像)还是在响应速度上(从后端的批量处理到实时数据服务)。尽管应用需求差异很大,但是,针对Google的这些产品,Bigtable还是成功的提供了一个灵活的、高性能的解决方案。分布式结构化数据表BigTable介绍设计动机与目标数据模型系统架构主服务器子表服务器Bigtable的设计动机需要存储的数据种类繁多:Google目前向公众开放的服务很多,需要处理的数据类型也非常多。包括URL、网页内容、用户的个性化设置在内的数据都是Google需要经常处理的;海量的服务请求:Google运行着目前世界上最繁忙的系统,它每时每刻处理的客户服务请求数量是普通的系统根本无法承受的;商用数据库无法满足Google的需求:一方面现有商用数据库设计着眼点在于通用性,根本无法满足Google的苛刻服务要求;另一方面对于底层系统的完全掌控会给后期的系统维护、升级带来极大的便利Bigtable的设计的设计目标Bigtable的设计的数据模型Bigtable的设计的数据模型---行Bigtable的行关键字可以是任意的字符串,但是大小不能超过64KB。Bigtable和传统的关系型数据库有很大不同,它不支持一般意义上的事务,但能保证对于行的读写操作具有原子性(Atomic)表中数据都是根据行关键字进行排序的,排序使用的是词典序。一个典型实例,其中com.cnn.就是一个行关键字。不直接存储网页地址而将其倒排是Bigtable的一个巧妙设计。这样做至少会带来以下两个好处同一地址域的网页会被存储在表中的连续位置,有利于用户查找和分析倒排便于数据压缩,可以大幅提高压缩率Bigtable的设计的数据模型---列Bigtable并不是简单地存储所有的列关键字,而是将其组织成所谓的列族(ColumnFamily),每个族中的数据都属于同一个类型,并且同族的数据会被压缩在一起保存。引入了列族的概念之后,列关键字就采用下述的语法规则来定义:族名:限定词(family:qualifier)族名必须有意义,限定词则可以任意选定图中,内容(Contents)、锚点(Anchor)都是不同的族。而cnnsi.com和my.look.ca则是锚点族中不同的限定词族同时也是Bigtable中访问控制(AccessControl)基本单元,也就是说访问权限的设置是在族这一级别上进行的Bigtable的设计的数据模型---时间戳Google的很多服务比如网页检索和用户的个性化设置等都需要保存不同时间的数据,这些不同的数据版本必须通过时间戳来区分。图2中内容列的t3、t5和t6表明其中保存了在t3、t5和t6这三个时间获取的网页。Bigtable中的时间戳是64位整型数,具体的赋值方式可以采取系统默认的方式,也可以用户自行定义为了简化不同版本的数据管理,Bigtable目前提供了两种设置:一种是保留最近的N个不同版本,图中数据模型采取的就是这种方法,它保存最新的三个版本数据。另一种就是保留限定时间内的所有不同版本,比如可以保存最近10天的所有不同版本数据。失效的版本将会由Bigtable的垃圾回收机制自动处理系统架构Bigtable主要由三个部分组成Bigtable主要由三个部分组成:客户端程序库(ClientLibrary)、一个主服务器(MasterServer)和多个子表服务器(TabletServer)客户访问Bigtable服务时,首先要利用其库函数执行Open()操作来打开一个锁(实际上就是获取了文件目录),锁打开以后客户端就可以和子表服务器进行通信和许多具有单个主节点分布式系统一样,客户端主要与子表服务器通信,几乎不和主服务器进行通信,这使得主服务器的负载大大降低主服务主要进行一些元数据操作以及子表服务器之间负载调度问题,实际数据是存储在子表服务器上。Bigtable中Chubby的作用在Bigtable中Chubby主要有以下几个作用:(1)选取并保证同一时间内只有一个主服务器(MasterServer)(2)获取子表的位置信息(3)保存Bigtable的模式信息及访问控制列表另外在Bigtable的实际执行过程中,Google的MapReduce和Sawzall也被用来改善其性能主服务器当一个新子表产生时,主服务器通过一个加载命令将其分配给一个空间足够的子表服务器。创建新表、表合并以及较大子表的分裂都会产生一个或多个新子表。对于前面两种,主服务器会自动检测到,而较大子表的分裂是由子服务发起并完成的,所以主服务器并不能自动检测到,因此在分割完成之后子服务器需要向主服务发出一个通知。由于系统设计之初就要求能达到良好的扩展性,所以主服务器必须对子表服务器的状态进行监控,以便及时检测到服务器的加入或撤销。Bigtable中主服务器对子表服务器的监控是通过Chubby完成的——子表服务器在初始化时都会从Chubby中得到一个独占锁。通过这种方式所有子表服务器基本信息被保存在Chubby中一个称为服务器目录(ServerDirectory)的特殊目录之中。主服务器主服务器会定期向其询问独占锁的状态。如果子表服务器的锁丢失或没有回应,则此时可能有两种情况:(1)要么是Chubby出现了问题(虽然这种概率很小,但的确存在,Google自己也做过相关测试);(2)要么是子表服务器自身出现了问题。对此主服务器首先自己尝试获取这个独占锁,如果失败说明Chubby服务出现问题,需等待恢复;如果成功则说明Chubby服务良好而子表服务器本身出现了问题。当在状态监测时发现某个子表服务器上负载过重时,主服务器会自动对其进行负载均衡操作主服务器基于系统出现故障是一种常态的设计理念,每个主服务器被设定了一个会话时间的限制。当某个主服务器到时退出后,管理系统就会指定一个新的主服务器,这个主服务器的启动需要经历以下四个步骤:(1)从Chubby中获取一个独占锁,确保同一时间只有一个主服务器;(2)扫描服务器目录,发现目前活跃的子表服务器;(3)与所有的活跃子表服务器取得联系以便了解所有子表的分配情况;(4)扫描元数据表,发现未分配的子表并将其分配到合适子表服务器。子表服务器Bigtable中的日志文件是一种共享日志,每个子表服务器上仅保存一个日志文件,某个子表日志只是这个共享日志的一个片段。这样会节省大量的空间,但在恢复时却有一定的难度。Google为了避免这种情况出现,对日志做了一些改进。Bigtable规定将日志的内容按照键值进行排序,这样不同的子表服务器都可以连续读取日志文件了。一般来说每个子表的大小在100MB到200MB之间。每个子表服务器上保存的子表数量可以从几十到上千不等,通常情况下是100个左右。子表服务器所有子表地址都被记录在元数据表中,元数据表也是由一个个的元数据子表(Metadatatablet)组成根子表是元数据表中一个比较特殊的子表,它既是元数据表的第一条记录,也包含了其他元数据子表的地址,同时Chubby中的一个文件也存储了这个根子表的信息。查询时,首先从Chubby中提取这个根子表的地址,进而读取所需的元数据子表的位置,最后就可以从元数据子表中找到待查询的子表。除了这些子表的元数据之外,元数据表中还保存了其他一些有利于调试和分析的信息,比如事件日志等。子表地址的查询是经常碰到的操作。在Bigtable系统的内部采用的是一种类似B+树的三层查询体系。缓存和预取技术为了减少访问开销,提高客户访问效率,Bigtable使用了缓存(Cache)和预取(Prefetch)技术子表的地址信息被缓存在客户端,客户在寻址时直接根据缓存信息进行查找。一旦出现缓存为空或缓存信息过时的情况,客户端就需要按照图示方式进行网络的来回通信(NetworkRound-trips)进行寻址,在缓存为空的情况下需要三个网络来回通信。如果缓存的信息是过时的,则需要六个网络来回通信。其中三个用来确定信息是过时的,另外三个获取新的地址预取则是在每次访问元数据表时不仅仅读取所需的子表元数据,而是读取多个子表的元数据,这样下次需要时就不用再次访问元数据表Bigtable数据存储及读/写操作9.2Hadoop中的数据库HBaseHadoop——Apache开源组织的一个分布式计算框架,可以在大量廉价的硬件设备组成的集群上运行应用程序,为应用程序提供了一组稳定可靠的接口,旨在构建一个具有高可靠性和良好扩展性的分布式系统.Hadoop优点(1)可扩展(2)经济(3)可靠(4)高效Hbase简介Hbase是一个分布式开源数据库,基于Hadoop分布式文件系统,模仿并提供了基于Google文件系统的Bigtable数据库的所有功能。Hbaes的目标是处理非常庞大的表,可以用普通的计算机处理超过10亿行数据,并且有数百万列元素组成的数据表。Hbase可以直接使用本地文件系统或者Hadoop作为数据存储方式,不过为了提高数据可靠性和系统的健壮性,发挥Hbase处理大数据量等功能,需要使用Hadoop作为文件系统。Hbase数据模型Hbase是一个类似Bigtable的分布式数据库,大部分特性和Bigtable一样,是一个稀疏的,长期存储的,多维度的,排序的映射表。这张表的索引是行关键字,列关键字和时间戳。每个值是一个不解释的字符数组,数据都是字符串,没类型。用户在表格中存储数据,每一行都有一个可排序的主键和任意多的列。由于是稀疏存储的,所以同一张表里面的每一行数据都可以有截然不同的列。Hbase数据模型列名字的格式是family:label,都是由字符串组成,每一张表有一个family集合,这个集合是固定不变的,相当于表的结构,只能通过改变表结构来改变。但是label值相对于每一行来说都是可以改变的。Hbase把同一个family里面的数据存储在同一个目录底下,而Hbase的写操作是锁行的,每一行都是一个原子元素,都可以加锁。所有数据库的更新都有一个时间戳标记,每个更新都是一个新的版本,而Hbase会保留一定数量的版本,这个值是可以设定的。客户端可以选择获取距离某个时间最近的版本,或者一次获取所有版本。Hbase逻辑模型一个表可以想象成一个大的映射关系,通过主键,或者主键+时间戳,可以定位一行数据,由于是稀疏数据,所以某些列可以是空白的上图是一个存储Web网页的范例列表片断。行名是一个反向URL{即com.cnn.}。contents列族存放网页内容,anchor列族存放引用该网页的锚链接文本。CNN的主页被SportsIllustrater{即所谓SI,CNN的王牌体育节目}和MY-look的主页引用,因此该行包含了名叫“anchor:cnnsi.com”和“anchhor:my.look.ca”的列。每个锚链接只有一个版本{由时间戳标识,如t9,t8};而contents列则有三个版本,分别由时间戳t3,t5,和t6标识。Hbase物理模型分布式