当前位置：文档之家 › 《云计算(第二版)》教材配套课件4—第二章 Google云计算原理与应用(3)

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

  • 格式：ppt
  • 大小：4.55 MB
  • 文档页数：54

下载文档原格式

  / 54

合集下载

《云计算(第三版)》配套PPT之五：第2章 Google云计算原理与应用(四)

《云计算(第三版)》配套PPT之五：第2章 Google云计算原理与应用(四)


MapReduce
优点：便携 缺点：效率低
Google的团队结合其自身的实际需求，借鉴搜 索引擎和并行数据库的一些技术，开发出了实 时的交互式查询系统Dremel。
5 of 64
2 . 7 海 量 数 据 的 交 互 式 分 析 工 具 D r e m e l 《云计算》第三版配套PPT课件
Dremel支持的典型应用
《云计算》第三版配套PPT课件
云 计 算 （第三版）
CLOUD COMPUTING Third Edition
第2章
Google云计算原理与应用（四）
主编：刘鹏 教授
of 64
《云计算》第三版配套PPT课件
目 录
2.1 Google文件系统GFS 2.2 分布式数据处理MapReduce 2.3 分布式锁服务Chubby 2.4 分布式结构化数据表Bigtable 2.5 分布式存储系统Megastore 2 . 6 大规模分布式系统的监控基础架构Dapper 2.7 海量数据的交互式分析工具Dremel 2.8 内存大数据分析系统PowerDrill 2.9 Google应用程序引擎
符合该模式的两条记录
11 of 64
《云计算》第三版配套PPT课件
2.7 海量数据的交互式分析工具Dremel
2.7.1 产生背景 2.7.2 数据模型 2.7.3 嵌套式的列存储 2.7.4 查询语言与执行 2.7.5 性能分析 2.7.6 小结
of 64
2 . 7 海 量 数 据 的 交 互 式 分 析 工 具 D r e m e l 《云计算》第三版配套PPT课件 数据结构的无损表示
15 of 64
2 . 7 海 量 数 据 的 交 互 式 分 析 工 具 D r e m e l 《云计算》第三版配套PPT课件
云计算第二章2-3教学

云计算第二章2-3教学


云计算的特点
通用性
云计算不针对特定的应用，在“ 云”的支撑下可以构造出千变万 化的应用，同一个“云”可以同 时支撑不同的应用运行。
高可扩展性
“云”的规模可以动态伸缩，满 足应用和用户规模增长的需要。
云计算的发展历程
萌芽期
过热期
在20世纪80年代网格计算、90年代 公用计算，21世纪初虚拟化技术、 SOA、SaaS应用的支撑下，云计算 作为一种新兴的资源使用和交付模式 逐渐为学界和产业界所认知。中国云 计算发展可分为两个阶段，第一阶段 为市场准备期（技术储备期），第二 阶段为起飞期（行业市场导入期）。
软件层（SaaS） 提供软件应用程序服务，用户可以通过云服务提供商的 Web界面或客户端来访问和使用这些应用程序。
云计算的服务类型
计算服务
提供虚拟或物理服务器的计算 能力，用户可以根据需要租用
不同配置的计算资源。
存储服务
提供文件存储、块存储和对象存储 等不同类型的存储服务，用户可以 根据需求选择适合的存储方式。
混合云
结合公有云和私有云的优势，构建统 一的云计算环境，实现资源的灵活调 度和管理。
社区云
由多个组织共同搭建和使用的云计算 平台，旨在满足特定社区或行业的共 同需求。
03 云计算的关键技术
虚拟化技术
01
02
03
计算虚拟化
通过虚拟化技术，将物理 服务器抽象成虚拟服务器， 提高资源利用率和灵活性。
存储虚拟化
云计算第二章2-3教学
目 录
• 云计算概述 • 云计算的架构与服务 • 云计算的关键技术 • 云计算在各个领域的应用 • 云计算的优势与挑战 • 云计算的实践与探索
01 云计算概述
云计算的定义
最新2019-云计算第二章2-4教学ppt-PPT课件

最新2019-云计算第二章2-4教学ppt-PPT课件

数据库——分布式存储数据库 Data Store
Google账户 ——开发应用程序必须拥有一个Google账户
App Engine服务——Google App Engine提供了一些服务
开发流程 ——Google App Engine开发应用程序必须遵守一定的开发
流程
配额和限制 ——Google账户提供的免费空间和流量有一定的配额和
自01己的其接ta应他口S用计上to程r算通e数机过序据；HT只T库P能或来在H存0TT标储2P准S应
用程序运行期间持续存在
03
（几秒之内完成）
同时，请求处理的
来的进数行据
序不能在自己的响
发送后产生子进程
执行代码
Google App Engine SDK
➢使用SDK时，可以在本地计算机上模拟包括所有Google App Engine服务的网络服务器应用程序，该SDK包括Google App Engine中的所有API和库。该网络服务器还可以模拟沙盒环境
沙盒给用o网应p行用gp开户l址用写程eE发应抓程n入序Ag人pi代用取序操pn码程无作eA员的EP序法，n上I提文和g只对只i的供n件电能能eG文沙了提o系子通读o件一供g统邮盒l，过取e进件的个对并应GAo虚用拟户的进环行境如，下这限个制环境使应用 应网程用络序程请与序求其只时他有才在运响行
开发者服且开务该发A应P使I用来程用访序的问必程互须序联使相网用中隔Da离，从而保证每个使用者可以且安响全应地时开间发必须极
➢使用Python实现，这个开发套件可以在装有Python 2.5的任 何平台上面运行，包括Windows、Mac OS X和Linux等，开发人 员可以在Python网站上获得适合自己系统的Python
云计算第2章-Google云计算原理与应用(2)

云计算第2章-Google云计算原理与应用(2)

p2c：如果一个编号为n的提案具有值v，那么存在一个“多数派”，要么它们中没有谁批 准过编号小于n的任何提案，要么它们进行的最近一次批准具有值v。
为了保证决议的唯一性，acceptors也要满足一个约束条件：当且仅当 acceptors 没有收到编号大于n的请求时，acceptors 才批准编号为n的提案。
文件I/O 快照
14 of 55
2.3 分布式锁服务 Chubby
容错日志的API
副本1 值 客户端 应用程序 Paxos 构架 提交 副本2
《云计算》第三版配套PPT课件
副本3
响应
响应
响应
Paxos 协议
值
值
值
15 of 55
《云计算》第三版配套PPT课件
2.3 分布式锁服务 Chubby
2 . 3 . 1 Pa x o s 算 法
2 . 3 . 1 Pa x o s 算 法
2.3.2 Chubby系统设计
2 . 3 . 3 C h u b b y 中 的 Pa xo s 2.3.4 Chubby文件系统 2.3.5 通信协议 2.3.6 正确性与性能
of 55
2.3 分布式锁服务 Chubby
正确性与性能
《云计算》第三版配套PPT课件
客户端 应用程序
Chubby 程序率
…
客户端 应用程序 Chubby 程序率
远程过程调用
服务器端
服务器一端称为Chubby单元，一般 是由五个称为副本（Replica）的服务 器组成的，这五个副本在配置上完全 一致，并且在系统刚开始时处于对等
主服务器
客户端进程
地位。
12 of 55
《云计算》第三版配套PPT课件
4. 云计算 之四：第2章 Google云计算原理与应用(三)

4. 云计算 之四：第2章 Google云计算原理与应用(三)


Dinner, Paris …
101,502
12:15:22
Betty, Paris
…
102
Mary
Bigtable的列名实际上是表名和属性名结合在一起得到，不同表中实体可 存储在同一个Bigtable行中
11 of 58
《云计算》第三版配套PPT课件
2.5 分布式存储系统Megastore
2.5.1 设计目标及方案选择 2.5.2 Megastore数据模型 2.5.3 Megastore中的事务及并发控制 2.5.4 Megastore基本架构 2.5.5 核心技术——复制 2.5.6 产品性能及控制措施
属性是命名的且具有类型，这些类型包括字符 型（strings）、数字类型（numbers）或者 Google的Protocol Buffers。
8 of 58
Hale Waihona Puke 2.5 分布式存储系统Megastore 照片共享服务数据模型实例
《云计算》第三版配套PPT课件
表Photo就是一个子表，因为它声明了 一个外键
《云计算》第三版配套PPT课件
主要 两类
局部 索引
定义在单个实体组中，作用域仅限于单个实 体组（ 如PhotosByTime ）
全局 索引
可以横跨多个实体组集进行数据读取操作 （ 如PhotosByTag ）
额外 索引
STORING子句
（STORING Clause）
可重复的索引
（Repeated Indexes）
User则是一个根表
一个Megastore实例中可以有若干个不 同的根表，表示不同类型的实体组集
三种不同属性设置，既有必须的（如 user_id），也有可选的（如 thumbnail_url）
云计算PPT课件

云计算PPT课件


虚拟信息 底层结构虚拟
服 务
安 全
资 源 管
理
虚拟存储 虚拟进程
- 15 -
虚拟化:
简单接入, 提高终端用户管理
& 使用最大化
自动化:
提高速度和预言性 & 减少劳动力
云计算对未来动态IT架构的支撑
商业流程
用户界面 & 接口
Cloud Applications
(“Software-as-a-Service”)
提高速度和预言性减少劳动力商业流程商业流程虚拟信息虚拟信息虚拟存储虚拟存储虚拟进程虚拟进程底层结构虚拟底层结构虚拟虚拟应用cloudapplicationssoftwareasaservice用户界面用户界面接口接口cloudplatformsplatformasaservice商业流程商业流程用户界面用户界面接口接口虚拟应用虚拟信息虚拟信息底层结构虚拟底层结构虚拟虚拟存储虚拟存储虚拟进程虚拟进程商业流程商业流程用户界面接口虚拟应用虚拟信息虚拟存储虚拟进程底层结构虚拟cloudcollaboration云计算对未来动态it架构的支撑商业流程商业流程用户界面接口虚拟应用虚拟信息虚拟存储cloudstoragecloudserversprocessing虚拟进程底层结构虚拟商业流程商业流程用户界面接口虚拟应用virtualizedinformation底层结构虚拟虚拟进程虚拟存储虚拟信息cloudsystemsinfrastructuresoftwaresoftwareasaservice云计算在中小企业的应用用户界面接口商业流程商业流程虚拟应用virtualizedinformation底层机构虚拟虚拟进程虚拟储存virtualizedinformation云计算和下一代it应用云计算还应包含onpremisesoftwareeg
Google与云计算精品PPT课件

Google与云计算精品PPT课件

• Shareability
– Make sharing as easy as creating and saving
• Freedom
– Users don’t want their data held hostage
• Simplicity
– Easy-to-learn, easy-to-use
• Essentially infinite amount of disk • Essentially infinite amount of computation • (Assuming they can be parallelized)
Google and Cloud Computing
Google与云e Internet: From Hardware to Community • The Innovation: A Computing Cloud • Breakthroughs for Cloud Computing • Google Apps for Cloud Computing • Google Infrastructure for Cloud Computing
• Data stored on the cloud • Software & services on the cloud - Access via web browser • Based on standards and protocols - Linux, AJAX, LAMP, etc. • Accessible from any device
1 User-Centric 2 Task-Centric 3 Powerful 4 Intelligent
5 Affordable 6 Programmable
3.《云计算(第三版)》配套PPT之三：第2章 Google云计算原理与应用(二)

3.《云计算(第三版)》配套PPT之三：第2章 Google云计算原理与应用(二)


4 of 56
2.3 分布式锁服务Chubby 系统的约束条件
《云计算》第三版配套PPT课件
p1：每个acceptor只接受它得到的第一个决议。
p2：一旦某个决议得到通过，之后通过的决议必须和该决议保持一致。
p2a：一旦某个决议v得到通过，之后任何acceptor再批准的决议必须是v。 p2b：一旦某个决议v得到通过，之后任何proposer再提出的决议必须是v。 p2c：如果一个编号为n的提案具有值v，那么存在一个“多数派”，要么它们中没有谁批 准过编号小于n的任何提案，要么它们进行的最近一次批准具有值v。
《云计算》第三版配套PPT课件
目 录
2.1 Google文件系统GFS 2.2 分布式数据处理MapReduce 2.3 分布式锁服务Chubby 2.4 分布式结构化数据表Bigtable 2.5 分布式存储系统Megastore 2 . 6 大规模分布式系统的监控基础架构Dapper 2.7 海量数据的交互式分析工具Dremel 2.8 内存大数据分析系统PowerDrill 2.9 Google应用程序引擎
为了保证决议的唯一性，acceptors也要满足一个约束条件：当且仅当 acceptors 没有收到编号大于n的请求时，acceptors 才批准编号为n的提案。
5 of 56
2.3 分布式锁服务Chubby 一个决议分为两个阶段
《云计算》第三版配套PPT课件
1
准备阶段
proposers选择一个提案并将它的编号设为n 将它发送给acceptors中的一个“多数派”
远程过程调用
客户端
Chubby
应用程序 程序率
客户端进程
主服务器
客户端
在客户这一端每个客户应用程序都有 一个Chubby程序库（Chubby Library），客户端的所有应用都是通 过调用这个库中的相关函数来完成的。
《云计算(第二版)》教材配套课件10—第四章_微软云计算Windows_Azure(2)

《云计算(第二版)》教材配套课件10—第四章_微软云计算Windows_Azure(2)

2．部门级应用
➢在一些大型的组织中，要求数据库服务器具有容错的功能保证服务 不中断 ➢解决上述问题最好办法：将控制逻辑移动到Windows Azure，这样数 据访问代码和数据本身都存放在同一个数据中心中
3．数据集应用
➢实例：保险公司数据集 应用 ➢SQL Azure时有三个任务 （图示）
（1）在SQL Azure中创建 一个数据库用来存储产品数 据和顾客数据 （2）在数据中心中创建一 个Sync Framework提供者 （3）为销售人员创建一个 二级的Sync Framework提供 者
2．创建云服务 安装完成后，启动Visual Studio 2010，在“开始页面”上选择“新建项 目”，出现一个“新建项目”的对话框
Visual Studio2010开发简单的云应用程序
对话框中选择“Cloud”，将项目名称修改为“My First Cloud Application”，单击“OK”按钮。然后会出现一个界面，提示需要安装 Windows Azure Tools，单击“Download Windows Azure Tools”后进入下 载界面
AppFabric概述
AppFabric目前主要提供服务
➢服务总线
通过云中应用公开的终端使公开应用服务变得简单
➢访问控制
用户可以通过很多种方法获得一个数字身份认证，包括Active Directory、 Windows Live ID、Google Account、Facebook等
➢高速缓存
在很多情况下，应用需要重复访问存取同一个数据。为了提升这类应用访 问速率，可缓存这些经常被访问的信息，从而减少应用查询数据库库的次数
向Windows Azure平台发布应用程序
2．向Windows Azure部署项目
云计算第二章2-3教学ppt

云计算第二章2-3教学ppt


特点
SaaS提供软件应用程序并通过Web 浏览器提供给用户使用，用户无需安 装和维护软件应用程序。
优点
用户可以随时随地使用软件应用程序， 无需安装和维护，同时获得软件提供 商的专业维护和技术支持。
缺点
用户可能受到软件提供商的限制，无 法完全定制和修改软件应用程序。
04 云计算的安全与隐私保护
数据安全与隐私保护
特点
PaaS提供应用程序开发和部署所需的平台和工具，用户可以通过 Web浏览器实现应用程序的开发、测试、部署和管理。
优点
用户可以快速开发和部署应用程序，同时获得平台提供的可扩展性和 可靠性。
ห้องสมุดไป่ตู้缺点
用户可能受到平台提供商的限制，无法完全控制应用程序的部署和管 理。
SaaS（软件即服务）
定义
SaaS提供软件应用程序并通过Web 浏览器提供给用户使用，用户无需安 装和维护软件应用程序。
谷歌云提供了灵活的付费模式，用户 可以根据实际需求进行资源选择和成 本控制。
概述
技术特点
应用场景
成本效益
谷歌云是全球领先的云服务提供商之 一，提供包括计算、存储、数据库、 分析等全面的云服务。
谷歌云广泛应用于企业级应用、大数 据分析、人工智能等领域。
THANKS FOR WATCHING
感谢您的观看
优势
分布式计算可以充分利用多台计算 机的计算能力，提高计算效率，降 低单点故障风险。
云存储技术
01
02
03
定义
云存储技术是一种将数据 存储在云端，通过网络进 行访问的技术。
应用
云存储技术可以实现数据 集中管理、存储空间灵活 分配、数据备份与恢复等 功能。
精选-《云计算(第三版)》配套PPT之四：第2章-Google云计算原理与应用(三)

精选-《云计算(第三版)》配套PPT之四：第2章-Google云计算原理与应用(三)

25
Megastore在Google中已经部 署和使用了若干年，有超过100 个产品使用Megastore作为其 存储系统
从图中可以看出，绝大多数产 品具有极高的可用性 （>99.999%）。这表明 Megastore系统的设计是非常 成功的，基本达到了预期目标
2.5 分布式存储系统Megastore
可扩展性
Google的服务增长速度是惊人的，设计出的系统至少在 未来几年里要能够满足Google服务和集群的需求。
31
2.6 大规模分布式系统的监控 基础架构Dapper
2.6.1 基本设计目标 2.6.2 Dapper监控系统简介 2.6.3 关键性技术 2.6.4 常用Dapper工具 2.6.5 Dapper使用经验
Dinner, Paris …
101,502
12:15:22
Betty, Paris
…
102
Mary
Bigtable的列名实际上是表名和属性名结合在一起得到，不同表中实体可 存储在同一个Bigtable行中
11
2.5 分布式存储系统Megastore
2.5.1 设计目标及方案选择 2.5.2 Megastore数据模型 2.5.3 Megastore中的事务及并发控制 2.5.4 Megastore基本架构 2.5.5 核心技术——复制 2.5.6 产品性能及控制措施
每个模式都由一系列的表（tables）构成，表 又包含有一系列的实体（entities），每实体 中包含一系列属性（properties）
属性是命名的且具有类型，这些类型包括字符 型（strings）、数字类型（numbers）或者 Google的Protocol Buffers。
8

《云计算(第二版)》—第二章 Google云计算原理与应用(2)

如果元数据表未分配，则首先需要将根子表（Root Tablet）加入未分配的子表中。 由于根子表保存了其他所有元数据子表的信息，确保了扫描能够发现所有未分配 （4）扫描元数据表，发现未分配的子表并将其分配到合适子表服务 的子表 器
分布式结构化数据表Bigtable
设计动机与目标 数据模型 系统架构
当一个新子表产生时，主服务器通过一个加载命令将其分配给一个空 间足够的子表服务器。创建新表、表合并以及较大子表的分裂都会产 生一个或多个新子表。对于前面两种，主服务器会自动检测到，而较 大子表的分裂是由子服务发起并完成的，所以主服务器并不能自动检 测到，因此在分割完成之后子服务器需要向主服务发出一个通知
主服务器
主服务器会定期向其询问独占锁的状态。如果子表服务器的锁丢失或 没有回应，则此时可能有两种情况 要么是Chubby出现了问题（虽然这种概率很小，但的确存在， Google自己也做过相关测试） 要么是子表服务器自身出现了问题。对此主服务器首先自己尝试获 取这个独占锁，如果失败说明Chubby服务出现问题，需等待恢复； 如果成功则说明Chubby服务良好而子表服务器本身出现了问题
用户表 1 … 其他元数据子表 根子表 （元数据表中第一条记录） C hubby 文 件 … …
· · ·
…
· · ·
…
用户表 N …
…
· · ·
…
为了减少访问开销，提高客户访问效率，Bigtable使用了缓存
（Cache）和预取（Prefetch）技术
子表的地址信息被缓存在客户端，客户在寻址时直接根据缓存信息进行查
子表实际组成
日志
Bigtable中的日志文件是一种共享日志，每 S S Tab le S S Tab le 个子表服务器上仅保存一个日志文件，某个子 64K B 64K B 64K B 64K B ... ... ... 块 块 块 块 表日志只是这个共享日志的一个片段。这样会 索引 索引 节省大量的空间，但在恢复时却有一定的难度 Google为了避免这种情况出现，对日志做了 一些改进。Bigtable规定将日志的内容按照键 每个子表都是由多个SSTable以 值进行排序，这样不同的子表服务器都可以连 续读取日志文件了 及日志（Log）文件构成
  1. 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。

分布式存储系统Megastore
设计目标及方案选择 Megastore数据模型 Megastore中的事务及并发控制
Megastore基本架构
核心技术——复制 产品性能及控制措施
Megastore中的事务及并发控制
Megastore三种方式的读，分别是current、snapshot
分布式存储系统Megastore
设计目标及方案选择 Megastore数据模型 Megastore中的事务及并发控制
Megastore基本架构
核心技术——复制 产品性能及控制措施
Megastore数据模型
传统的关系型数据库是通过连接（Join）来满足用户的需求 的，但是就Megastore而言，这种数据模型是不合适的，主要 有以下三个原因： （1）对于高负载的交互式应用来说，可预期的性能提升要比 使用一种代价高昂的查询语言所带来的好处多 （2）Megastore所面对的应用是读远多于写，因此好的选择 是将读操作所需要做的工作尽可能地转移到写操作上 （3）在Bigtable这样的键/值存储系统中存储和查询级联数 据（Hierarchical Data）是很方便的 Megastore数据模型怎么设计？
分布式锁服务Chubby 分布式结构化数据表Bigtable 分布式存储系统Megastore 大规模分布式系统的监控基础架构Dapper Google应用程序引擎
分布式存储系统Megastore
设计目标及方案选择 Megastore数据模型 Megastore中的事务及并发控制
属性是命名的且具有类型，这些类型包括字符型（strings）、 数字类型（numbers）或者Google的Protocol Buffers。这些属 性可以被设置成必须的（required）、可选的（optional）或者 可重复的（repeated，即允许单个属性上有多个值）
数据模型实例
图中表Photo就是一个子表，因为它 声明了一个外键； User则是一个根表。一个Megastore 实例中可以有若干个不同的根表，表 示不同类型的实体组集
和inconsistent
其中current读和snapshot读总是在单个实体组中完成
对于snapshot读，系统取出已知的最后一个完整提交的事务 的时间戳，接着从这个位置读数据
inconsistent读忽略日志的状态直接读取最新的值
Megastore中的事务及并发控制
Megastore事务中的写操作采用了预写式日志
可用性分布情况
产品延迟情况分布
应用程序的平均读取延迟 在万分之一毫秒之内，平 均写入延迟在100至400毫 秒之间
需要指出：Megastore已经是Google相对过时的存储技术。Google目 避免Megastore的性能下 前正在使用的存储系统是Spanner架构，Spanner的设计目标是能够 降，可采取以下三种应对 控制一百万到一千万台服务器，Spanner最强大之处在于能够在50毫 方法（可能结合使用）： 秒之内为数据传递提供通道 （1）重新选择路由使客户 端绕开出现问题的副本 （2）将出现问题副本上的 协调者禁用，确保问题的 平均延迟的分布 影响降至最小。 （3）禁用整个副本
Google设计了一种能够提供细粒度控制的数据模型和模式语言 同关系型数据库一样，Megastore的数据模型是在模式 （schema）中定义的且是强类型的（strongly typed）
每个模式都由一系列的表（tables）构成，表又包含有一系列 的实体（entities），每实体中包含一系列属性（properties）
协议使用了乐观并发（Optimistic
读：获取最后一次提交的事务的时间戳和日志位置
应用逻辑：从Bigtable读取且聚集数据到日志入口
完 整 事 务 周 期
提交：使用Paxos达到一致，将个入口追加到日志
生效：将数据更新到Bigtable中的实体和索引 清除：清理不再需要的数据
Megastore中的事务机制
电子工业出版社《云计算(第二版)》配套课件
第2章
Google云计算原理与应用
解放军理工大学 刘鹏 教授主编 华东交通大学 刘鹏 制作
《云计算（第二版）》购买网址： 当当网 京东商城
姊妹力作《实战Hadoop》购买网址： 当当网 京东商城
提 纲
Google文件系统GFS
分布式数据处理MapReduce
快速写 Megastore采用了一种在主/从式系统中常用的优化方法。 如果一次写成功，那么下一次写的时候就跳过准备过程，直 接进入接受阶段 Megastore没有使用专门的主服务器，而是使用leaders leader主要是来裁决哪个写入的值可以获取0号提议 优化：提交值最多的位置附近选择一副本作为leader 客户端、网络及Bigtable的故障都会导致一个写操作处于 不确定的状态
除了可用性问题，对于协调者的读写协议必须满足一系列的竞争条件
分布式存储系统Megastore
设计目标及方案选择 Megastore数据模型 Megastore中的事务及并发控制
Megastore基本架构
核心技术——复制 产品性能及控制措施
可用性分布情况
Megastore在Google中已 经部署和使用了若干年， 有超过100个产品使用 Megastore作为其存储系统 从图中可以看出，绝大多 数产品具有极高的可用性 （>99.999%）。这表明 Megastore系统的设计是非 常成功的，基本达到了预 期目标
Megastore基本架构
核心技术——复制 产品性能及控制措施
Megastore的基本架构
Megastore中三种 副本
完整副本：Bigtable 中存储完整的日志和数 据
见证者副本：在Paxos
算法执行过程中无法产 生一个决议时参与投票
只读副本：读取最近 过去某一个时间点一致 性数据
（Write-ahead Log）
一个写事务总是开始于一个current读以便确认下一个可
用的日志位置。提交操作将数据变更聚集到日志，接着分配 一个比之前任意一个都高的时间戳，然后使用Paxos将数据变 更加入到日志中 Concurrency）：尽管 可能有多个写操作同时试图写同一个日志位置，但只会有1个 成功
消息队列机制
消息能够横跨实体组 每个消息都有一个发 送和接收实体组 如果两个实体组是不 同的，则传输将是异步
特点
规模：声明一个队列
后可以在其他所有的实 体组上创建一个收件箱
支持两阶段提交 增加竞争风险，不鼓
Megastore中的事务机制
励使用
分布式存储系统Megastore
设计目标及方案选择 Megastore数据模型 Megastore中的事务及并发控制
图中实例还可以看到三种不同属性设 置，既有必须的（如user_id），也 有可选的（如thumbnail_url）；
值得注意的是Photo中的可重复类型 的tag属性，这也就意味着一个Photo 中允许同时出现多个tag属性
照片共享服务数据模型实例
索引（Index）
Megastore索引分成两大类：局部索引（local index）和全
分布式存储系统Megastore
设计目标及方案选择 Megastore数据模型 Megastore中的事务及并发控制
Megastore基本架构
核心技术——复制 产品性能及控制措施
复制的日志
当日志有不完整的前 缀时我们就称一个日志 副本有“缺失” （Holes）
图中0～99的日志位置
本地读取（Local Read）
多数派读取（Majority Read） 追赶 （Catchup） Paxos将会促使绝大多数副本达
成一个共识值
达到一种分布式一致状态
验证（Validate） 查询数据（Query Data）
数据读取
数据写入完整过程 :
（1）接受leader：请求leader接 受值作为0号提议（快速写方法）， 若成功，跳至步骤（3） （2）准备：将值替换成拥有最高 提议号的那个值 （3）接受：请求剩余的副本接受 该值，如果大多数副本拒绝这个 值，返回步骤（2） （4）失效：将不接受值的副本 上的协调者进行失效操作 （5）生效：将值的更新在尽可 能多的副本上生效。如果选择的 值和原来提议的有冲突，返回一 个冲突错误
设计目标及方案选择
可用性——实现了一个同步的、 容错的、适合远距离传输的复制 机制。引入Paxos算法并对其做 出一定的改进以满足远距离同步 复制的要求
设 计 目 标
一种介于传统的 关系型数据库和 NoSQL之间的存 储技术，尽可能 达到高可用性和 高可扩展性的统 一
可扩展性 ——借鉴了数据库中数 据分区的思想，将整个大的数据 分割成很多小的数据分区，每个 数据分区连同它自身的日志存放 在NoSQL数据库中，具体来说就是 存放在Bigtable中
Bigtable中数据存储情况
行键（Row Key） 101 101,500 101,502 102
:01 12:15:22
Photo.tag Dinner, Paris Betty, Paris … …
Photo._url
Mary
表中不难看出——Bigtable的列名实际上是表名和属性名结 合在一起得到，不同表中实体可存储在同一个Bigtable行中
已经被全部清除；100 的日志位置被部分清除； 101的日志位置被全部 副本接受；102的日志 位置被γ获得；103的 日志位置被副本A和C接 受，副本B则留下了一 个“缺失”；104的日 志位置则未达到一致性
预写式日志
数据读取
数据读取过程: 本地查询（Query Local）
发现位置（Find Position）
数据分区和复制
Megastore中，这些小的数据 分区被称为实体组集（Entit y Groups）。 每个实体组集包含若干实体 实体组集之间只具有比较松散的一致性。每个实体组都通过复制技术在数 组（Entity Group，相当于 据中心中保存若干数据副本，这些实体组及其副本都存储在NoSQL数据库 （Bigtable）中 分区中表的概念），而一个 实体组中又包含很多的实体 （Entity，相当于表中记录 的概念）。 从图中还可以看出单个实体 数据分区和复制 组支持ACID语义