搜索
目录2.1Google文件系统GFS2.2分布式数据处理MapReduce2.3分布式锁服务Chubby2.4分布式结构化数据表Bigtable2.5分布式存储系统Megastore2.6大规模分布式系统的监控基础架构Dapper2.7海量数据的交互式分析工具Dremel2.8内存大数据分析系统PowerDrill2.9Google应用程序引擎2.5分布式存储系统Megastore2.5.1设计目标及方案选择2.5.2Megastore数据模型2.5.3Megastore中的事务及并发控制2.5.4Megastore基本架构2.5.5核心技术——复制2.5.6产品性能及控制措施针对可用性的要求，实现了一个同步的、容错的、适合远距离传输的复制机制。针对可扩展性的要求，将整个大的数据分割成很多小的数据分区，每个数据分区连同它自身的日志存放在NoSQL数据库中，具体来说就是存放在Bigtable中。设计目标及方案选择2.5分布式存储系统Megastore设计一种介于传统的关系型数据库和NoSQL之间的存储技术，尽可能达到高可用性和高可扩展性的统一。方法一设计目标方法二3数据的分区和复制2.5分布式存储系统Megastore在Megastore中，这些小的数据分区被称为实体组集（EntityGroups）。每个实体组集包含若干的实体组（EntityGroup，相当于分区中表的概念）。一个实体组中包含很多的实体（Entity，相当于表中记录的概念）。42.5分布式存储系统Megastore2.5.1设计目标及方案选择2.5.2Megastore数据模型2.5.3Megastore中的事务及并发控制2.5.4Megastore基本架构2.5.5核心技术——复制2.5.6产品性能及控制措施62.5分布式存储系统Megastore传统的关系型数据库不合适的三个原因传统的关系型数据库是通过连接（Join）来满足用户的需求的，但是就Megastore而言，这种数据模型是不合适的，主要有以下三个原因：原因1对于高负载的交互式应用来说，可预期的性能提升要比使用一种代价高昂的查询语言所带来的好处多原因2Megastore所面对的应用是读远多于写，因此好的选择是将读操作所需要做的工作尽可能地转移到写操作上原因3在Bigtable这样的键/值存储系统中存储和查询级联数据（HierarchicalData）是很方便的Megastore数据模型怎么设计？82.5分布式存储系统Megastore细粒度控制的数据模型和模式语言同关系型数据库一样，Megastore的数据模型是在模式（schema）中定义的且是强类型的（stronglytyped）每个模式都由一系列的表（tables）构成，表又包含有一系列的实体（entities），每实体中包含一系列属性（properties）属性是命名的且具有类型，这些类型包括字符型（strings）、数字类型（numbers）或者Google的ProtocolBuffers。Google团队设计的Megastore数据模型92.5分布式存储系统Megastore照片共享服务数据模型实例表Photo就是一个子表，因为它声明了一个外键User则是一个根表一个Megastore实例中可以有若干个不同的根表，表示不同类型的实体组集三种不同属性设置，既有必须的（如user_id），也有可选的（如thumbnail_url）Photo中的可重复类型的tag属性102.5分布式存储系统MegastoreMegastore索引局部索引定义在单个实体组中，作用域仅限于单个实体组（如PhotosByTime）可以横跨多个实体组集进行数据读取操作（如PhotosByTag）全局索引主要两类额外索引STORING子句（STORINGClause）可重复的索引（RepeatedIndexes）内联索引（InlineIndexes）112.5分布式存储系统MegastoreBigtable中存储情况行键（RowKey）User.namePhoto.timePhoto.tagPhoto._url101John101,50012:30:01Dinner,Paris…101,50212:15:22Betty,Paris…102MaryBigtable的列名实际上是表名和属性名结合在一起得到，不同表中实体可存储在同一个Bigtable行中2.5分布式存储系统Megastore2.5.1设计目标及方案选择2.5.2Megastore数据模型2.5.3Megastore中的事务及并发控制2.5.4Megastore基本架构2.5.5核心技术——复制2.5.6产品性能及控制措施13Megastore提供的三种读currentsnapshotinconsistent总是在单个实体组中完成总是在单个实体组中完成系统取出已知的最后一个完整提交的事务的时间戳，接着从这个位置读数据忽略日志的状态直接读取最新的值2.5分布式存储系统Megastore14完整的事务周期读应用逻辑提交生效清除获取最后一次提交的事务的时间戳和日志位置从Bigtable读取且聚集数据到日志入口使用Paxos达到一致，将个入口追加到日志将数据更新到Bigtable中的实体和索引清理不再需要的数据2.5分布式存储系统Megastore152.5分布式存储系统MegastoreMegastore中的事务机制2.5分布式存储系统Megastore2.5.1设计目标及方案选择2.5.2Megastore数据模型2.5.3Megastore中的事务及并发控制2.5.4Megastore基本架构2.5.5核心技术——复制2.5.6产品性能及控制措施172.5分布式存储系统MegastoreMegastore基本架构完整副本（FullReplica）见证者副本（WitnessReplica）只读副本（Read-onlyReplica）在Megastore中共有三种副本182.5分布式存储系统Megastore快速读与快速写快速读快速写利用本地读取实现快速读，带来更好的用户体验及更低的延迟关键是保证选择的副本上数据是最新的协调者是一个服务，该服务分布在每个副本的数据中心里面。它的主要作用就是跟踪一个实体组集合协调者的状态是由写算法来保证如果一次写成功，那么下一次写的时候就跳过准备过程，直接进入接受阶段Megastore没有使用专门的主服务器，而是使用leadersleader主要是来裁决哪个写入的值可以获取0号提议客户端、网络及Bigtable的故障都会导致一个写操作处于不确定的状态2.5分布式存储系统Megastore2.5.1设计目标及方案选择2.5.2Megastore数据模型2.5.3Megastore中的事务及并发控制2.5.4Megastore基本架构2.5.5核心技术——复制2.5.6产品性能及控制措施202.5分布式存储系统Megastore复制的日志每个副本都存有记录所有更新的数据。Megastore允许副本不按顺序接受日志，这些日志将独立的存储在Bigtable中。预写式日志212.5分布式存储系统Megastore数据读取本地查询发现位置追赶验证查询数据222.5分布式存储系统Megastore数据写入接受leader准备接受失效生效232.5分布式存储系统Megastore协调者的可用性协调者在系统中是比较重要的——协调者的进程运行在每个数据中心。每次的写操作中都要涉及协调者，因此协调者的故障将会导致系统的不可用Megastore使用了Chubby锁服务，为了处理请求，一个协调者必须持有多数锁。一旦因为出现问题导致它丢失了大部分锁，协调者就会恢复到一个默认保守状态除了可用性问题，对于协调者的读写协议必须满足一系列的竞争条件2.5分布式存储系统Megastore2.5.1设计目标及方案选择2.5.2Megastore数据模型2.5.3Megastore中的事务及并发控制2.5.4Megastore基本架构2.5.5核心技术——复制2.5.6产品性能及控制措施252.5分布式存储系统Megastore可用性的分布情况Megastore在Google中已经部署和使用了若干年，有超过100个产品使用Megastore作为其存储系统从图中可以看出，绝大多数产品具有极高的可用性（99.999%）。这表明Megastore系统的设计是非常成功的，基本达到了预期目标26产品延迟情况的分布2.5分布式存储系统Megastore应用程序的平均读取延迟在万分之一毫秒之内，平均写入延迟在100至400毫秒之间避免Megastore的性能下降，可采取以下三种应对方法：（1）重新选择路由使客户端绕开出现问题的副本（2）将出现问题副本上的协调者禁用，确保问题的影响降至最小。（3）禁用整个副本目录2.1Google文件系统GFS2.2分布式数据处理MapReduce2.3分布式锁服务Chubby2.4分布式结构化数据表Bigtable2.5分布式存储系统Megastore2.6大规模分布式系统的监控基础架构Dapper2.7海量数据的交互式分析工具Dremel2.8内存大数据分析系统PowerDrill2.9Google应用程序引擎2.6大规模分布式系统的监控基础架构Dapper2.6.1基本设计目标2.6.2Dapper监控系统简介2.6.3关键性技术2.6.4常用Dapper工具2.6.5Dapper使用经验在我们看来很简单的一次搜索实际上涉及了众多Google后台子系统，这些子系统的运行状态都需要进行监控用户的平均每一次前台搜索会导致Google的后台发生1011次的处理302.6大规模分布式系统的监控基础架构Dapper两个基本要求设计出的监控系统应当能够对尽可能多的Google服务进行监控Google的服务是全天候的，如果不能对Google的后台同样进行全天候的监控很可能会错过某些无法再现的关键性故障监控系统设计两个基本要求1.广泛可部署性（UbiquitousDeployment）2.不间断的监控312.6大规模分布式系统的监控基础架构Dapper三个基本设计目标低开销这个是广泛可部署性的必然要求。监控系统的开销越低，对于原系统的影响就越小，系统的开发人员也就越愿意接受这个监控系统。对应用层透明监控系统对程序员应当是不可见的。如果监控系统的使用需要程序开发人员对其底层的一些细节进行调整才能正常工作的话，这个监控系统肯定不是一个完善的监控系统。可扩展性Google的服务增长速度是惊人的，设计出的系统至少在未来几年里要能够满足Google服务和集群的需求。2.6大规模分布式系统的监控基础架构Dapper2.6.1基本设计目标2.6.2Dapper监控系统简介2.6.3关键性技术2.6.4常用Dapper工具2.6.5Dapper使用经验332.6大规模分布式系统的监控基础架构DapperDapper监控系统的基本概念典型分布式系统的请求及应答过程用户ABCDE请求X应答XRPC1中间层RPC2前端后台RPC4RPC3在监控系统中记录下所有这些消息不难，如何将这些消息记录同特定的请求（本例中的X）关联起来才是分布式监控系统设计中需要解决的关键性问题之一。342.6大规模分布式系统的监控基础架构DapperDapper监控系统的三个基本概念监控树（TraceTree）区间（Span）注释（Annotation）一个同特定事件相关的所有消息区间实际上就是一条记录注释主要用来辅助推断区间关系，也可以包含一些自定义的内容352.6大规模分布式系统的监控基础架构Dapper区间Helper.Call的详细信息区间包含了来自客户端的注释信息：“Start”、“ClientSend”、“ClientRecv”和“End”，也包含了来自服务器端的注释信息：“ServerRecv”、“foo”和“ServerSend”362.6大规模分布式系统的监控基础架构Dapper监控信息的汇总（1）将区间的数据写入到本地的