《云计算(第三版)》第2章_Google云计算原理与应用(三).pptx

电子工业出版社《云计算(第三版)》配套课件第 2 章Google云计算原理与应用（三）目录 2.1 Google文件系统GFS2.2 分布式数据处理MapReduce2.3 分布式锁服务Chubby2.4 分布式结构化数据表Bigtable2.5 分布式存储系统Megastore2.6 大规模分布式系统的监控基础架构Dapper2.7 海量数据的交互式分析工具Dremel2.8 内存大数据分析系统PowerDrill2.9 Google应用程序引擎2.5 分布式存储系统Megastore2.5.1 设计目标及方案选择2.5.2 Megastore数据模型2.5.3 Megastore中的事务及并发控制2.5.4 Megastore基本架构2.5.5 核心技术——复制2.5.6 产品性能及控制措施?在互联网的应用中，为了达到好的可扩展性，常常会采用NoSQL存储方式。但是从应用程序的构建方面来看，传统的关系型数据库又有着NoSQL所不具备的优势。? Google设计和构建了用于互联网中交互式服务的分布式存储系统Megastore，该系统成功的将关系型数据库和NoSQL的特点与优势进行了融合 2.5 分布式存储系统Megastore设计目标及方案选择 设计目标设计一种介于传统的关系型数据库和NoSQL之间的存储技术，尽可能达到高可用性和高可扩展性的统一。方法一方法二针对可用性的要求，实现了一个同步的、容错的、适合远距离传输的复制机制。针对可扩展性的要求，将整个大的数据分割成很多小的数据分区，每个数据分区连同它自身的日志存放在NoSQL数据库中，具体来说就是存放在Bigtable中。数据分区和复制 ?Megastore中，这些小的数据分区被称为实体组集（Entity Groups）。?每个实体组集包含若干实体组（Entity Group，相当于分区中表的概念），而一个实体组中又包含很多的实体（Entity，相当于表中记录的概念）。?从图中还可以看出单个实体组支持ACID语义实体组集之间只具有比较松散的一致性。每个实体组都通过复制技术在数据中心中保存若干数据副本，这些实体组及其副本都存储在NoSQL数据库（Bigtable）中 数据分区和复制 2.5 分布式存储系统Megastore2.5.1 设计目标及方案选择2.5.2 Megastore数据模型2.5.3 Megastore中的事务及并发控制2.5.4 Megastore基本架构2.5.5 核心技术——复制2.5.6 产品性能及控制措施2.5 分布式存储系统Megastore传统的关系型数据库不合适的三个原因传统的关系型数据库是通过连接（Join）来满足用户的需求的，但是就Megastore而言，这种数据模型是不合适的，主要有以下三个原因：原因 1对于高负载的交互式应用来说，可预期的性能提升要比使用一种代价高昂的查询语言所带来的好处多原因 2Megastore所面对的应用是读远多于写，因此好的选择是将读操作所需要做的工作尽可能地转移到写操作上原因 3在Bigtable这样的键/值存储系统中存储和查询级联数据（Hierarchical Data）是很方便的 Megastore数据模型怎么设计？2.5 分布式存储系统Megastore细粒度控制的数据模型和模式语言同关系型数据库一样，Megastore的数据模型是在模式（schema）中定义的且是强类型的（strongly typed）Google团队设计的Megastore数据模型每个模式都由一系列的表（tables）构成，表又包含有一系列的实体（entities），每实体中包含一系列属性（properties）属性是命名的且具有类型，这些类型包括字符型（strings）、数字类型（numbers）或者Google的Protocol Buffers。2.5 分布式存储系统Megastore照片共享服务数据模型实例 表Photo就是一个子表，因为它声明了一个外键User则是一个根表一个Megastore实例中可以有若干个不同的根表，表示不同类型的实体组集 三种不同属性设置，既有必须的（如user_id），也有可选的（如thumbnail_url）Photo中的可重复类型的tag属性2.5 分布式存储系统MegastoreMegastore索引定义在单个实体组中，作用域仅限于单个实体组（ 如PhotosByTime ）局部索引主要两类全局索引可以横跨多个实体组集进行数据读取操作（ 如PhotosByTag ）额外索引内联索引（Inline Indexes）STORING子句（STORING Clause）可重复的索引（Repeated Indexes）2.5 分布式存储系统MegastoreBigtable中存储