《云计算(第二版)》教材配套—第二章 Google云计算原理与应用

《《云计算(第二版)》教材配套—第二章 Google云计算原理与应用》由会员分享，可在线阅读，更多相关《《云计算(第二版)》教材配套—第二章 Google云计算原理与应用（54页珍藏版）》请在金锄头文库上搜索。

1、电子工业出版社 云计算 第二版 配套课件 解放军理工大学刘鹏教授主编华东交通大学刘鹏制作 第2章Google云计算原理与应用 云计算 第二版 购买网址 当当网京东商城 姊妹力作 实战Hadoop 购买网址 当当网京东商城 提纲 Google文件系统GFS 分布式数据处理MapReduce 分布式锁服务Chubby 分布式结构化数据表Bigtable 分布式存储系统Megastore 大规模分布式系统的监控基础架构Dapper Google应用程序引擎 设计目标及方案选择 Megastore数据模型 Megastore中的事务及并发控制 Megastore基本架构 核心技术 复制 产品性能及控制

2、措施 在互联网的应用中 为了达到好的可扩展性 常常会采用NoSQL存储方式 但是从应用程序的构建方面来看 传统的关系型数据库又有着NoSQL所不具备的优势 Google设计和构建了用于互联网中交互式服务的分布式存储系统Megastore 该系统成功的将关系型数据库和NoSQL的特点与优势进行了融合 设计目标及方案选择 可用性 实现了一个同步的 容错的 适合远距离传输的复制机制 引入Paxos算法并对其做出一定的改进以满足远距离同步复制的要求 可扩展性 借鉴了数据库中数据分区的思想 将整个大的数据分割成很多小的数据分区 每个数据分区连同它自身的日志存放在NoSQL数据库中 具体来说就是存放在Bi

3、gtable中 设计目标 一种介于传统的关系型数据库和NoSQL之间的存储技术 尽可能达到高可用性和高可扩展性的统一 数据分区和复制 数据分区和复制 Megastore中 这些小的数据分区被称为实体组集 EntityGroups 每个实体组集包含若干实体组 EntityGroup 相当于分区中表的概念 而一个实体组中又包含很多的实体 Entity 相当于表中记录的概念 从图中还可以看出单个实体组支持ACID语义 实体组集之间只具有比较松散的一致性 每个实体组都通过复制技术在数据中心中保存若干数据副本 这些实体组及其副本都存储在NoSQL数据库 Bigtable 中 设计目标及方案选择 Mega

4、store数据模型 Megastore中的事务及并发控制 Megastore基本架构 核心技术 复制 产品性能及控制措施 Megastore数据模型 传统的关系型数据库是通过连接 Join 来满足用户的需求的 但是就Megastore而言 这种数据模型是不合适的 主要有以下三个原因 1 对于高负载的交互式应用来说 可预期的性能提升要比使用一种代价高昂的查询语言所带来的好处多 2 Megastore所面对的应用是读远多于写 因此好的选择是将读操作所需要做的工作尽可能地转移到写操作上 3 在Bigtable这样的键 值存储系统中存储和查询级联数据 HierarchicalData 是很方便的 Me

5、gastore数据模型怎么设计 Google设计了一种能够提供细粒度控制的数据模型和模式语言 同关系型数据库一样 Megastore的数据模型是在模式 schema 中定义的且是强类型的 stronglytyped 每个模式都由一系列的表 tables 构成 表又包含有一系列的实体 entities 每实体中包含一系列属性 properties 属性是命名的且具有类型 这些类型包括字符型 strings 数字类型 numbers 或者Google的ProtocolBuffers 这些属性可以被设置成必须的 required 可选的 optional 或者可重复的 repeated 即允许单个属

6、性上有多个值 数据模型实例 照片共享服务数据模型实例 图中表Photo就是一个子表 因为它声明了一个外键 User则是一个根表 一个Megastore实例中可以有若干个不同的根表 表示不同类型的实体组集 图中实例还可以看到三种不同属性设置 既有必须的 如user id 也有可选的 如thumbnail url 值得注意的是Photo中的可重复类型的tag属性 这也就意味着一个Photo中允许同时出现多个tag属性 索引 Index Megastore索引分成两大类 局部索引 localindex 和全局索引 globalindex 局部索引定义在单个实体组中 作用域仅限于单个实体组 如Phot

7、osByTime 全局索引则可以横跨多个实体组集进行数据读取操作 如PhotosByTag Megastore还提供了一些额外的索引特性 STORING子句 STORINGClause 可重复的索引 RepeatedIndexes 内联索引 InlineIndexes Bigtable中数据存储情况 表中不难看出 Bigtable的列名实际上是表名和属性名结合在一起得到 不同表中实体可存储在同一个Bigtable行中 设计目标及方案选择 Megastore数据模型 Megastore中的事务及并发控制 Megastore基本架构 核心技术 复制 产品性能及控制措施 Megastore中的事务及

8、并发控制 Megastore三种方式的读 分别是current snapshot和inconsistent 其中current读和snapshot读总是在单个实体组中完成 对于snapshot读 系统取出已知的最后一个完整提交的事务的时间戳 接着从这个位置读数据 inconsistent读忽略日志的状态直接读取最新的值 Megastore中的事务及并发控制 Megastore事务中的写操作采用了预写式日志 Write aheadLog 一个写事务总是开始于一个current读以便确认下一个可用的日志位置 提交操作将数据变更聚集到日志 接着分配一个比之前任意一个都高的时间戳 然后使用Paxos将

9、数据变更加入到日志中 协议使用了乐观并发 OptimisticConcurrency 尽管可能有多个写操作同时试图写同一个日志位置 但只会有1个成功 读 获取最后一次提交的事务的时间戳和日志位置 完整事务周期 应用逻辑 从Bigtable读取且聚集数据到日志入口 提交 使用Paxos达到一致 将个入口追加到日志 生效 将数据更新到Bigtable中的实体和索引 清除 清理不再需要的数据 Megastore中的事务机制 消息队列机制 消息能够横跨实体组 每个消息都有一个发送和接收实体组 如果两个实体组是不同的 则传输将是异步 特点 规模 声明一个队列后可以在其他所有的实体组上创建一个收件箱 支持

10、两阶段提交 增加竞争风险 不鼓励使用 Megastore中的事务机制 设计目标及方案选择 Megastore数据模型 Megastore中的事务及并发控制 Megastore基本架构 核心技术 复制 产品性能及控制措施 Megastore的基本架构 Megastore中三种副本 完整副本 Bigtable中存储完整的日志和数据 见证者副本 在Paxos算法执行过程中无法产生一个决议时参与投票 只读副本 读取最近过去某一个时间点一致性数据 Megastore的基本架构 Megastore中提供快速读 FastReads 和快速写 FastWrites 机制 快速读 如果读操作不需要副本之间进行通

11、信即可完成 那么读取的效率必然相对较高 利用本地读取 LocalReads 实现快速读 能够带来更好的用户体验及更低的延迟 确保快速读成功的关键是保证选择的副本上数据是最新的 为了达到这一目标 引入了协调者的概念 协调者是一个服务 该服务分布在每个副本的数据中心里面 它的主要作用就是跟踪一个实体组集合 协调者的状态是由写算法来保证 快速写 Megastore采用了一种在主 从式系统中常用的优化方法 如果一次写成功 那么下一次写的时候就跳过准备过程 直接进入接受阶段 Megastore没有使用专门的主服务器 而是使用leaders leader主要是来裁决哪个写入的值可以获取0号提议 优化 提交

12、值最多的位置附近选择一副本作为leader 客户端 网络及Bigtable的故障都会导致一个写操作处于不确定的状态 设计目标及方案选择 Megastore数据模型 Megastore中的事务及并发控制 Megastore基本架构 核心技术 复制 产品性能及控制措施 复制的日志 预写式日志 当日志有不完整的前缀时我们就称一个日志副本有 缺失 Holes 图中0 99的日志位置已经被全部清除 100的日志位置被部分清除 101的日志位置被全部副本接受 102的日志位置被 获得 103的日志位置被副本A和C接受 副本B则留下了一个 缺失 104的日志位置则未达到一致性 数据读取 数据读取 数据读取过

13、程 本地查询 QueryLocal 发现位置 FindPosition 本地读取 LocalRead 多数派读取 MajorityRead 追赶 Catchup Paxos将会促使绝大多数副本达成一个共识值 达到一种分布式一致状态 验证 Validate 查询数据 QueryData 数据写入 数据写入 数据写入完整过程 1 接受leader 请求leader接受值作为0号提议 快速写方法 若成功 跳至步骤 3 2 准备 将值替换成拥有最高提议号的那个值 3 接受 请求剩余的副本接受该值 如果大多数副本拒绝这个值 返回步骤 2 4 失效 将不接受值的副本上的协调者进行失效操作 5 生效 将值的

14、更新在尽可能多的副本上生效 如果选择的值和原来提议的有冲突 返回一个冲突错误 协调者的可用性 协调者在系统中是比较重要的 协调者的进程运行在每个数据中心 每次的写操作中都要涉及协调者 因此协调者的故障将会导致系统的不可用 Megastore使用了Chubby锁服务 为了处理请求 一个协调者必须持有多数锁 一旦因为出现问题导致它丢失了大部分锁 协调者就会恢复到一个默认保守状态 除了可用性问题 对于协调者的读写协议必须满足一系列的竞争条件 设计目标及方案选择 Megastore数据模型 Megastore中的事务及并发控制 Megastore基本架构 核心技术 复制 产品性能及控制措施 可用性分布

15、情况 可用性分布情况 Megastore在Google中已经部署和使用了若干年 有超过100个产品使用Megastore作为其存储系统 从图中可以看出 绝大多数产品具有极高的可用性 99 999 这表明Megastore系统的设计是非常成功的 基本达到了预期目标 产品延迟情况分布 应用程序的平均读取延迟在万分之一毫秒之内 平均写入延迟在100至400毫秒之间 避免Megastore的性能下降 可采取以下三种应对方法 可能结合使用 1 重新选择路由使客户端绕开出现问题的副本 2 将出现问题副本上的协调者禁用 确保问题的影响降至最小 3 禁用整个副本 平均延迟的分布 需要指出 Megastore已

16、经是Google相对过时的存储技术 Google目前正在使用的存储系统是Spanner架构 Spanner的设计目标是能够控制一百万到一千万台服务器 Spanner最强大之处在于能够在50毫秒之内为数据传递提供通道 基本设计目标 Dapper监控系统简介 关键性技术 常用Dapper工具 Dapper使用经验 用户将一个关键字通过Google的输入框传到Google的后台 在我们看来很简单的一次搜索实际上涉及了众多Google后台子系统 这些子系统的运行状态都需要进行监控 广泛可部署性 不间断的监控 监控系统设计两个基本要求 设计目标 03 02 01 广泛可部署性的必然要求 监控系统的开销越低 对于原系统的影响就越小 系统的开发人员也就越愿意接受这个监控系统 Google的服务增长速度是惊人的 设计出的系统至少在未来几年里要能够满足Google服务和集群的需求 如果监控系统的使用需要程序开发人员对其底层的一些细节进行调整才能正常工作的话 这个监控系统肯定不是一个完善的监控系统 低开销 应用层透明 可扩展性 基本设计目标 Dapper监控系统简介 关键性技术 常用Dapper工具 Da