《Google背后的分布式计算架构策略 .doc》由会员分享，可在线阅读，更多相关《Google背后的分布式计算架构策略 .doc（17页珍藏版）》请在三一办公上搜索。
1、Google是与众不同的。它的独特不仅仅表现于革新的思维和充满创意的应用(比如那个大堂里的地球模型)，更在于其有别常规的IT策略加利福尼亚州山景城(MountainView)Google公司(Google，下称Google)总部有一个43号大楼，该建筑的中央大屏幕上显示着一个与Google地球(GoogleEarth)相仿的世界地图，一个转动的地球上不停地闪动着五颜六色的光点，恍如罗马宫廷的千万烛灯，每一次闪动标志着地球的这个角落一名Google用户发起了一次新的搜索。这同时意味着Google又一次满足了人们对未知信息的好奇与渴望。Google是与众不同的。它的独特不仅仅表现于革新的思维和充满
2、创意的应用(比如那个大堂里的地球模型)，更在于其有别常规的IT策略。从人们的常理来看，简单的硬件商品和免费软件是无法构建出一个帝国的，但是Google做到了。在性能调整后，Google把它们变成一个无可比拟的分布式计算平台，该平台能够支持大规模的搜索和不断涌现的新兴应用。我们原本认为这些应用都是个人消费级别的，但是Google改变了这一切。现在商业世界也在使用它们，这就令这家搜索公司显得那么与众不同。GoogleWeb服务背后的IT架构对无数使用搜索引擎的用户来说也许并不是非常重要，但它是Google几百位致力于把全球信息组织起来，实现“随处可达，随时可用”目标的工程师们的最核心工作。这就需要
3、一个在覆盖范围和野心上都与Google的商业愿景完全相符的IT蓝图作为支撑。Google的经理们一直对公司的IT策略话题保持沉默，他们厌恶谈及特定的厂商或者产品，当被问到他们的服务器和数据中心时，他们总是闭口不谈。但与几位Google的IT领导一起呆了一天后，我们最终得以揭示该公司的IT是如何运作的，那可不仅仅是一个运行在无数服务器集群上的、表面看来非常简单的搜索引擎。在其简单的外表下，蕴涵着许多内部研发软件、定制硬件、人工智能，以及对性能的执着追求和打破常规的人力管理模式。IT理念方面，Google对同行有一条建议：尽量避免那些人人都在使用的系统和软件，以自己的方式做事会更有独特的竞争优势。
4、“企业文化决定了你的做事方式。”道格拉斯美林(DouglasMerrill)，这位Google工程副总裁和事实上的首席信息官(CIO)指出，“到了我们这样的发展阶段，企业观念和文化非常与众不同，这也反过来鞭策我们必须要采用与众不同的方式来运行那些他人看来很常规的系统。”Google最大的IT优势在于它能建造出既富于性价比(并非廉价)又能承受极高负载的高性能系统。因此IT顾问史蒂芬阿诺德(StephenArnold)指出，Google与竞争对手，如亚马逊网站(Amazon)、电子港湾公司(eBay)、微软公司(Microsoft，下称微软)和雅虎公司(Yahoo，下称雅虎)等公司相比，具有更大的
5、成本优势。Google程序员的效率比其他Web公司同行们高出50%100%，原因是Google已经开发出了一整套专用于支持大规模并行系统编程的定制软件库。据他估算，其他竞争公司可能要花上四倍的时间才能获得同等的效果。打造服务器Google究竟是怎样做到这点的呢?其中一个手段，美林认为，“是因为我们自己动手打造硬件。”Google并不制造计算机系统，但它根据自己的参数定制硬件，然后像MTV的节目“靓车打造”(PimpMyRide)那样自己安装和调整硬件系统。开源程序经理克里斯迪博纳(ChrisDiBona)评论道：“我们很善于购买商业服务器，并且改造他们为我们所用，最后把性能压榨和发挥到极致，以
6、致有时候他们热得像要融化了似的。”这种亲手打造的方式，来源于Google从车库诞生时与生俱来的节俭风格，更与Google那超大型的系统规模息息相关，良好的习惯一直延续至今。据说Google在65个数据中心拥有20万45万台服务器这个数目会有偏差(取决于你如何定义服务器和由谁来做这项统计)。但是，不变的是持续上升的趋势。Google不会去讨论这些资产，因为它认为保密也是一种竞争优势。事实上，Google之所以喜欢开源软件也是因为它的私密性。“如果我们购买了软件许可或代码许可，人们只要对号入座，就可以猜出Google的IT基础架构。”迪博纳分析说，“使用开源软件，就使我们多了一条把握自己命运的途径
7、。”Google喜欢规模化的服务器运行方式。当有成百上千台机器时，定制服务器的优势也会成倍增加，效果也会更趋明显。Google正在俄勒冈州哥伦比亚河边的达勒斯市建造一个占地30亩的数据中心，在那儿它可以获得运算和降温需要的低价水力电力能源(参见边栏Google数据中心自有一套)。Google以“单元”(Cell)的形式组织这些运行Linux操作系统的服务器，迪博纳把这种形式比喻成互联网服务的“磁盘驱动器”(但别和一直谣传的Google存储服务Gdrive混淆了，“并没有Gdrive这回事。”一位Google女发言人明确表示。)，公司的软件程序都驻扎在这些并不昂贵的电脑机箱里，由程序员决定它们的
8、冗余工作量。这种由很多单元组成的文件系统代替了商业存储设备;迪博纳表示Google这些单元设备更易于建造和维护，他还暗示他们能处理更大规模的数据。Google不会漏过对任何技术细节的关注。多年来，公司的工程师就在研究微处理器的内部工作机制，随着Google规模的持续壮大，必然会用到特别定制和调节过的芯片。知名工程师路易斯巴罗索(LuizBarroso)去年在一篇发表在工业杂志上的论文中证实，近年来Google的主要负荷都由单核设计的系统承担着。但许多服务器端的应用，如Google搜索索引服务，所需的并行计算在单核芯片的指令级别上执行得并不好。曾在数据设备公司(DigitalEquipment)
9、和康柏公司(Compaq)当过芯片设计师的巴罗索认为，随着AMD公司、英特尔公司(Intel)、太阳计算机系统公司(Sun)开始制造多核芯片，必将会出现越来越多芯片级别的并行计算。Google也曾考虑过自己制造计算机芯片，但从业界潮流来看，这个冒险的举动似乎不是很必要。“微处理器的设计非常复杂而且成本昂贵，”运营高级副总裁乌尔斯霍尔茨勒(UrsHolzle)表示。Google宁愿与芯片制造商合作，让他们去理解自己的应用并设计适合的芯片。这是一种客户建议式的设计，其关注点在于总体吞吐量、效能，以及耗电比，而不是看单线程的峰值性能。霍尔茨勒表示，“这也是最近多核CPU的设计潮流与未来方向。”裁缝般
10、地定制软件为了能尽量压榨硬件性能，Google开发了相当数量的定制软件。创新产品主要包括用于简化处理和创建大规模数据集的编程模型MapReduce;用于存储和管理大规模数据的系统BigTable;分析分布式运算环境中大规模数据集的解释编程语言Sawzall;用于数据密集型应用的分布式文件系统的“Google文件系统”(GoogleFileSystem);还有为处理分布式系统队列分组和任务调度的“Google工作队列”(GoogleWorkqueue)。正是从Sawzall这些工具里体现出Google对计算效率的执著关注。并不是每家公司都能从底层去解决效率问题，但是对Google来说，为常规关系
11、型数据库无法容纳的大规模数据集专门设计一种编程语言是完全合理的。即使其他编程工具可以解决问题，Google的工程师们仍然会为了追求效率而另外开发一套定制方案。Google工程师认为，Sawzall能与C+中的MapReduce相媲美，而且它更容易编写一些。Google对效率的关注使它不可能对标准Linux内核感到满意;Google会根据自己的需要运行修改过的内核版本。通过调整Linux的底层性能，Google工程师们在提高了整体系统可靠性的基础上，还一并解决了数据损坏和数据瓶颈等一系列棘手问题。对内核的修改也使Google的计算机集群系统因为通信效率的提高而运行得更快。当然，Google偶尔也
12、会出现系统故障，情况一旦发生，无数的用户就会受到影响了。三年前一次持续30分钟的系统故障使20%的搜索流量受到影响。Google开发了自己的网站服务器却没有使用开源的Apache服务器，尽管它在网站服务器的市场占有率超过60%。迪博纳认为，Google的网站服务器可以运行在更多数量的主机上，对Google站点上内容庞大又彼此互相依赖的应用程序来说，这种服务器的负载均衡能力远比Apache的能力更高。同时，在用标准公共网关接口(CGI)访问数据库动态网页方面，Google服务器的编程难度要比Apache更高，但是最终运行速度却更快。“如果我们能够压榨出10%20%的性能，我们就可以节省出更多系统
13、资源、电量和人力了。”迪博纳在总结中指出。Google还设计了自己的客户关系管理(CRM)系统用于支持自己基于竞价和点击的互联网广告收费业务。但对是否需要设计自己的工具，Google的态度也不是一成不变的。比如在财会软件上，它就使用了甲骨文公司(Oracle)的Financials软件。美林拿着一只叉子举例说明现成的产品也可以带来价值。但在有些场合现成的软件产品就不一定适用了。“我们的文化在各个层面对我们的运作都有深远影响，”他表示，“所以我们不想让购买所得的工具改变我们的工作方式和文化层面。”GooglesBigTable原理（翻译）题记：google的成功除了一个个出色的创意外，还因为有J
14、effDean这样的软件架构天才。-编者官方的GoogleReaderblog中有对BigTable的解释。这是Google内部开发的一个用来处理大数据量的系统。这种系统适合处理半结构化的数据比如RSS数据源。以下发言是AndrewHitchcock在2005年10月18号基于：Google的工程师JeffDean在华盛顿大学的一次谈话(CreativeCommonsLicense).首先，BigTable从2004年初就开始研发了，到现在为止已经用了将近8个月。（2005年2月）目前大概有100个左右的服务使用BigTable，比如：Print,SearchHistory,Maps和orku
15、t。根据Google的一贯做法，内部开发的BigTable是为跑在廉价的PC机上设计的。BigTable让Google在提供新服务时的运行成本降低，最大限度地利用了计算能力。BigTable是建立在GFS，Scheduler，LockService和MapReduce之上的。每个Table都是一个多维的稀疏图sparsemap。Table由行和列组成，并且每个存储单元cell都有一个时间戳。在不同的时间对同一个存储单元cell有多份拷贝，这样就可以记录数据的变动情况。在他的例子中，行是URLs，列可以定义一个名字，比如：contents。Contents字段就可以存储文件的数据。或者列名是：”
16、language”，可以存储一个“EN”的语言代码字符串。为了管理巨大的Table，把Table根据行分割，这些分割后的数据统称为：Tablets。每个Tablets大概有100-200MB，每个机器存储100个左右的Tablets。底层的架构是：GFS。由于GFS是一种分布式的文件系统，采用Tablets的机制后，可以获得很好的负载均衡。比如：可以把经常响应的表移动到其他空闲机器上，然后快速重建。Tablets在系统中的存储方式是不可修改的immutable的SSTables，一台机器一个日志文件。当系统的内存满后，系统会压缩一些Tablets。由于Jeff在论述这点的时候说的很快，所以我没
17、有时间把听到的都记录下来，因此下面是一个大概的说明：压缩分为：主要和次要的两部分。次要的压缩仅仅包括几个Tablets，而主要的压缩时关于整个系统的压缩。主压缩有回收硬盘空间的功能。Tablets的位置实际上是存储在几个特殊的BigTable的存储单元cell中。看起来这是一个三层的系统。客户端有一个指向METAO的Tablets的指针。如果METAO的Tablets被频繁使用，那个这台机器就会放弃其他的tablets专门支持METAO这个Tablets。METAOtablets保持着所有的META1的tablets的记录。这些tablets中包含着查找tablets的实际位置。（老实说翻译到
18、这里，我也不太明白。）在这个系统中不存在大的瓶颈，因为被频繁调用的数据已经被提前获得并进行了缓存。现在我们返回到对列的说明：列是类似下面的形式：family:optional_qualifier。在他的例子中，行：www.search-也许有列：”contents:其中包含html页面的代码。“anchor:中包含着相对应的url，”anchor:www.search-包含着链接的文字部分。列中包含着类型信息。(翻译到这里我要插一句，以前我看过一个关于万能数据库的文章，当时很激动，就联系了作者，现在回想起来，或许google的bigtable才是更好的方案，切不说分布式的特性，就是这种建华的表
19、结构就很有用处。)注意这里说的是列信息，而不是列类型。列的信息是如下信息，一般是：属性/规则。比如：保存n份数据的拷贝或者保存数据n天长等等。当tablets重新建立的时候，就运用上面的规则，剔出不符合条件的记录。由于设计上的原因，列本身的创建是很容易的，但是跟列相关的功能确实非常复杂的，比如上文提到的类型和规则信息等。为了优化读取速度，列的功能被分割然后以组的方式存储在所建索引的机器上。这些被分割后的组作用于列,然后被分割成不同的SSTables。这种方式可以提高系统的性能，因为小的，频繁读取的列可以被单独存储，和那些大的不经常访问的列隔离开来。在一台机器上的所有的tablets共享一个lo
20、g，在一个包含1亿的tablets的集群中，这将会导致非常多的文件被打开和写操作。新的log块经常被创建，一般是64M大小，这个GFS的块大小相等。当一个机器down掉后，控制机器就会重新发布他的log块到其他机器上继续进行处理。这台机器重建tablets然后询问控制机器处理结构的存储位置，然后直接对重建后的数据进行处理。这个系统中有很多冗余数据，因此在系统中大量使用了压缩技术。Dean对压缩的部分说的很快，我没有完全记下来，所以我还是说个大概吧：压缩前先寻找相似的行，列，和时间数据。他们使用不同版本的：BMDiff和Zippy技术。BMDiff提供给他们非常快的写速度：100MB/s1000
21、MB/s。Zippy是和LZW类似的。Zippy并不像LZW或者gzip那样压缩比高，但是他处理速度非常快。Dean还给了一个关于压缩web蜘蛛数据的例子。这个例子的蜘蛛包含2.1B的页面，行按照以下的方式命名：“n.www/index.html:http”.在未压缩前的webpage页面大小是：45.1TB，压缩后的大小是：4.2TB，只是原来的9.2%。Links数据压缩到原来的13.9%,链接文本数据压缩到原来的12.7%。Google还有很多没有添加但是已经考虑的功能。1.数据操作表达式，这样可以把脚本发送到客户端来提供修改数据的功能。2.多行数据的事物支持。3.提高大数据存储单元的效
22、率。4.BigTable作为服务运行。好像：每个服务比如：maps和searchhistory历史搜索记录都有他们自己的集群运行BigTable。他们还考虑运行一个全局的BigTable系统，但这需要比较公平的分割资源和计算时间。大表(Bigtable):结构化数据的分布存储系统中是译者评论,程序除外本文的翻译可能有不准确的地方,详细资料请参考原文.摘要bigtable是设计来分布存储大规模结构化数据的，从设计上它可以扩展到上50字节，分布存储在几千个普通服务器上google的很多项目使用bt来存储数据，包括网页查询，googleearth和google金融这些应用程序对bt的要求各不相同：数
23、据大小（从URL到网页到卫星图象）不同，反应速度不同（从后端的大批处理到实时数据服务）对于不同的要求，bt都成功的提供了灵活高效的服务在本文中，我们将描述bt的数据模型这个数据模型让用户动态的控制数据的分布和结构我们还将描述BT的设计和实现介绍在过去两年半里，我们设计，实现并部署了BTBT是用来分布存储和管理结构化数据的BT的设计使它能够管理250bytes(petabytes)数据，并可以部署到上千台机器上BT完成了以下目标：应用广泛，可扩展，高性能和高可用性（highavailability）.包括googleanalytics,googlefinance,orkut,personaliz
24、edsearch,writely和googleearth在内的60多个项目都使用BT.这些应用对BT的要求各不相同，有的需要高吞吐量的批处理，有的需要快速反应给用户数据它们使用的BT集群也各不相同，有的只有几台机器，有的有上千台，能够存储240字节(terabytes)数据BT在很多地方和数据库很类似：它使用了很多数据库的实现策略并行数据库14和内存数据库13有可扩展性和高性能，但是BT的界面不同BT不支持完全的关系数据模型；而是为客户提供了简单的数据模型，让客户来动态控制数据的分布和格式就是只存储字串，格式由客户来解释，并允许客户推断底层存储数据的局部性以提高访问速度数据下标是行和列的名字，
25、数据本身可以是任何字串BT的数据是字串，没有解释类型等客户会在把各种结构或者半结构化的数据串行化比如说日期串到数据中通过仔细选择数据表示，客户可以控制数据的局部化最后，可以使用BT模式来控制数据是放在内存里还是在硬盘上就是说用模式，你可以把数据放在离应用最近的地方毕竟程序在一个时间只用到一块数据在体系结构里，就是：locality,locality,locality第二节描述数据模型细节第三节关于客户API概述第四节简介BT依赖的google框架第五节描述BT的实现关键部分第6节叙述提高BT性能的一些调整第7节提供BT性能的数据在第8节，我们提供BT的几个使用例子，第9节是经验教训在第10节，
26、我们列出相关研究最后是我们的结论数据模型BT是一个稀疏的，长期存储的存在硬盘上，多维度的，排序的映射表这张表的索引是行关键字，列关键字和时间戳每个值是一个不解释的字符数组数据都是字符串，没类型，客户要解释就自力更生吧(row:string,column:string,time:int64)-string能编程序的都能读懂，不翻译了我们仔细查看过好些类似bigtable的系统之后定下了这个数据模型。举一个具体例子（它促使我们做出某些设计决定），比如我们想要存储大量网页及相关信息，以用于很多不同的项目；我们姑且叫它Webtable。在Webtable里，我们将用URL作为行关键字，用网页的某些属性
27、作为列名，把网页内容存在contents:列中并用获取该网页的时间戳作为标识，如图一所示。图一：一个存储Web网页的范例列表片断。行名是一个反向URL即n.www。contents列族原文用family，译为族，详见列族存放网页内容，anchor列族存放引用该网页的锚链接文本。CNN的主页被SportsIllustrater即所谓SI，CNN的王牌体育节目和MY-look的主页引用，因此该行包含了名叫“anchor:”和“anchhor:my.look.ca”的列。每个锚链接只有一个版本由时间戳标识，如t9，t8；而contents列则有三个版本，分别由时间戳t3，t5，和t6标识。行表中的行
28、关键字可以是任意字符串（目前支持最多64KB，多数情况下10100字节足够了）。在一个行关键字下的每一个读写操作都是原子操作（不管读写这一行里多少个不同列），这是一个设计决定，这样在对同一行进行并发操作时，用户对于系统行为更容易理解和掌控。Bigtable通过行关键字的字典序来维护数据。一张表可以动态划分成多个连续行。连续行在这里叫做“子表”tablet，是数据分布和负载均衡的单位。这样一来，读较少的连续行就比较有效率，通常只需要较少机器之间的通信即可。用户可以利用这个属性来选择行关键字，从而达到较好数据访问地域性locality。举例来说，在Webtable里，通过反转URL中主机名的方式，
29、可以把同一个域名下的网页组织成连续行。具体来说，可以把近的域名来存放网页可以让基于主机和基于域名的分析更加有效。列族一组列关键字组成了“列族”，这是访问控制的基本单位。同一列族下存放的所有数据通常都是同一类型（同一列族下的数据可压缩在一起）。列族必须先创建，然后在能在其中的列关键字下存放数据；列族创建后，族中任何一个列关键字均可使用。我们希望，一张表中的不同列族不能太多（最多几百个），并且列族在运作中绝少改变。作为对比，一张表可以有无限列。列关键字用如下语法命名：列族：限定词。列族名必须是看得懂printable的字串，而限定词可以是任意字符串。比如，Webtable可以有个列族叫langua
30、ge，存放撰写网页的语言。我们在language列族中只用一个列关键字，用来存放每个网页的语言标识符。该表的另一个有用的列族是anchor；给列族的每一个列关键字代表一个锚链接，如图一所示。而这里的限定词则是引用该网页的站点名；表中一个表项存放的是链接文本。访问控制，磁盘使用统计，内存使用统计，均可在列族这个层面进行。在Webtable举例中，我们可以用这些控制来管理不同应用：有的应用添加新的基本数据，有的读取基本数据并创建引申的列族，有的则只能浏览数据（甚至可能因为隐私权原因不能浏览所有数据）。时间戳Bigtable表中每一个表项都可以包含同一数据的多个版本，由时间戳来索引。Bigtable
31、的时间戳是64位整型。可以由Bigtable来赋值，表示准确到毫秒的“实时”；或者由用户应用程序来赋值。需要避免冲突的应用程序必须自己产生具有唯一性的时间戳。不同版本的表项内容按时间戳倒序排列，即最新的排在前面。为了简化对于不同数据版本的数据的管理，我们对每一个列族支持两个设定，以便于Bigtable对表项的版本自动进行垃圾清除。用户可以指明只保留表项的最后n个版本，或者只保留足够新的版本（比如，只保留最近7天的内容）。在Webtable举例中，我们在contents:列中存放确切爬行一个网页的时间戳。如上所述的垃圾清除机制可以让我们只保留每个网页的最近三个版本。3.APIBT的API提供了建
32、立和删除表和列族的函数还提供了函数来修改集群，表和列族的元数据，比如说访问权限/OpenthetableTable*T=OpenOrDie(”/bigtable/web/webtable”);/WriteanewanchoranddeleteanoldanchorRowMutationr1(T,“n.www”);r1.Set(”anchor:www.c-span.org”,“CNN”);r1.Delete(”anchor:”);Operationop;Apply(&op,&r1);图2:写入Bigtable.在BT中，客户应用可以写或者删除值，从每个行中找值，或者遍历一个表中的数据子集图2的c
33、+代码是使用RowMutation抽象表示来进行一系列的更新（为保证代码精简，没有包括无关的细节）调用Apply函数，就对ebtable进行了一个原子修改：它为Scannerscanner(T);ScanStream*stream;stream=scanner.FetchColumnFamily(”anchor”);stream-SetReturnAllVersions();scanner.Lookup(”n.www”);for(;!stream-Done();stream-Next()printf(”%s%s%lld%sn”,scanner.RowName(),stream-ColumnNa
34、me(),stream-MicroTimestamp(),stream-Value();图3:从Bigtable读数据.图3的C+代码是使用Scanner抽象来遍历一个行内的所有锚点客户可以遍历多个列族有很多方法可以限制一次扫描中产生的行，列和时间戳例如，我们可以限制上面的扫描，让它只找到那些匹配正则表达式*的锚点，或者那些时间戳在当前时间前10天的锚点BT还支持其他一些更复杂的处理数据的功能首先，BT支持单行处理这个功能可以用来对存储在一个行关键字下的数据进行原子的读-修改-写操作BT目前不支持跨行关键字的处理，但是它有一个界面，可以用来让客户进行批量的跨行关键字处理操作其次，BT允许把每个
35、表项用做整数记数器最后，BT支持在服务器的地址空间内执行客户端提供的脚本程序脚本程序的语言是google开发的Sawzall28数据处理语言目前，我们基于的Sawzall的API还不允许客户脚本程序向BT内写数据，但是它允许多种形式的数据变换，基于任何表达式的过滤和通过多种操作符的摘要BT可以和MapReduce12一起使用MapReduce是google开发的大规模并行计算框架我们为编写了一套外层程序，使BT可以作为MapReduce处理的数据源头和输出结果4.建立BT的基本单元BT是建立在其他数个google框架单元上的BT使用google分布式文件系统(GFS)17来存储日志和数据文件y
36、eah,right,whatelsecanituse,FAT32?一个BT集群通常在一个共享的机器池中工作，池中的机器还运行其他的分布式应用虽然机器便宜的跟白菜似的，可是一样要运行多个程序，命苦的象小白菜，BT和其他程序共享机器BT的瓶颈是/内存，可以和CPU要求高的程序并存BT依赖集群管理系统来安排工作，在共享的机器上管理资源，处理失效机器并监视机器状态典型的serverfarm结构，BT是上面的应用之一BT内部存储数据的格式是googleSSTable格式一个SSTable提供一个从关键字到值的映射，关键字和值都可以是任意字符串映射是排序的，存储的不会因为掉电而丢失，不可改写的可以进行以下
37、操作：查询和一个关键字相关的值；或者根据给出的关键字范围遍历所有的关键字和值在内部，每个SSTable包含一列数据块（通常每个块的大小是64KB,但是大小是可以配置的索引大小是16bits，应该是比较好的一个数）块索引（存储在SSTable的最后）用来定位数据块；当打开SSTable的时候，索引被读入内存性能每次查找都可以用一个硬盘搜索完成根据索引算出数据在哪个道上，一个块应该不会跨两个道，没必要省那么点空间：首先在内存中的索引里进行二分查找找到数据块的位置，然后再从硬盘读去数据块最佳情况是：整个SSTable可以被放在内存里，这样一来就不必访问硬盘了想的美，前面是谁口口声声说要跟别人共享机器
38、来着？你把内存占满了别人上哪睡去？BT还依赖一个高度可用的，存储的分布式数据锁服务Chubby8看你怎么把这个highperformance给说圆喽一个Chubby服务由5个活的备份机器构成，其中一个被这些备份选成主备份，并且处理请求这个服务只有在大多数备份都活着并且互相通信的时候才是活的绕口令？去看原文吧，是在有出错的前提下的冗余算法当有机器失效的时候，Chubby使用Paxos算法9,23来保证备份的一致性这个问题还是比较复杂的，建议去看引文了解一下问题本身Chubby提供了一个名字空间，里面包括了目录和小文件万变不离其宗每个目录或者文件可以当成一个锁来用，读写文件操作都是原子化的Chub
39、by客户端的程序库提供了对Chubby文件的一致性缓存究竟是提高性能还是降低性能？如果访问是分布的，就是提高性能每个Chubby客户维护一个和Chubby服务的会话如果一个客户不能在一定时间内更新它的会话，这个会话就过期失效了还是针对大serverfarm里机器失效的频率设计的当一个会话失效时，其拥有的锁和打开的文件句柄都失效根本设计原则：失效时回到安全状态Chubby客户可以在文件和目录上登记回调函数，以获得改变或者会话过期的通知翻到这里，有没有人闻到java的味道了？BT使用Chubby来做以下几个任务：保证任何时间最多只有一个活跃的主备份；来存储BT数据的启动位置（参考5.1节）；发现小
40、表（tablet）服务器，并完成tablet服务器消亡的善后（5.2节）；存储BT数据的模式信息（每张表的列信息）；以及存储访问权限列表如果有相当长的时间Chubby不能访问，BT就也不能访问了任何系统都有其弱点最近我们在使用11个Chubby服务实例的14个BT集群中度量了这个效果，由于Chubby不能访问而导致BT中部分数据不能访问的平均百分比是0.0047%,这里Chubby不能访问的原因是Chubby本身失效或者网络问题单个集群里，受影响最大的百分比是0.0326%基于文件系统的Chubby还是很稳定的.GFS是一个可扩展的分布式文件系统，用于大型的、分布式的、对大量数据进行访问的应用
41、。它运行于廉价的普通硬件上，但可以提供容错功能。它可以给大量的用户提供总体性能较高的服务。出处：1、设计概览（1）设计想定GFS与过去的分布式文件系统有很多相同的目标，但GFS的设计受到了当前及预期的应用方面的工作量及技术环境的驱动，这反映了它与早期的文件系统明显不同的设想。这就需要对传统的选择进行重新检验并进行完全不同的设计观点的探索。GFS与以往的文件系统的不同的观点如下：1、部件错误不再被当作异常，而是将其作为常见的情况加以处理。因为文件系统由成百上千个用于存储的机器构成，而这些机器是由廉价的普通部件组成并被大量的客户机访问。部件的数量和质量使得一些机器随时都有可能无法工作并且有一部分还
42、可能无法恢复。所以实时地监控、错误检测、容错、自动恢复对系统来说必不可少。2、按照传统的标准，文件都非常大。长度达几个GB的文件是很平常的。每个文件通常包含很多应用对象。当经常要处理快速增长的、包含数以万计的对象、长度达TB的数据集时，我们很难管理成千上万的KB规模的文件块，即使底层文件系统提供支持。因此，设计中操作的参数、块的大小必须要重新考虑。对大型的文件的管理一定要能做到高效，对小型的文件也必须支持，但不必优化。3、大部分文件的更新是通过添加新数据完成的，而不是改变已存在的数据。在一个文件中随机的操作在实践中几乎不存在。一旦写完，文件就只可读，很多数据都有这些特性。一些数据可能组成一个大
43、仓库以供数据分析程序扫描。有些是运行中的程序连续产生的数据流。有些是档案性质的数据，有些是在某个机器上产生、在另外一个机器上处理的中间数据。由于这些对大型文件的访问方式，添加操作成为性能优化和原子性保证的焦点。而在客户机中缓存数据块则失去了吸引力。4、工作量主要由两种读操作构成：对大量数据的流方式的读操作和对少量数据的随机方式的读操作。在前一种读操作中，可能要读几百KB，通常达1MB和更多。来自同一个客户的连续操作通常会读文件的一个连续的区域。随机的读操作通常在一个随机的偏移处读几个KB。性能敏感的应用程序通常将对少量数据的读操作进行分类并进行批处理以使得读操作稳定地向前推进，而不要让它来来回
44、回的读。5、工作量还包含许多对大量数据进行的、连续的、向文件添加数据的写操作。所写的数据的规模和读相似。一旦写完，文件很少改动。在随机位置对少量数据的写操作也支持，但不必非常高效。6、系统必须高效地实现定义完好的大量客户同时向同一个文件的添加操作的语义。（2）系统接口GFS提供了一个相似地文件系统界面，虽然它没有向POSIX那样实现标准的API。文件在目录中按层次组织起来并由路径名标识。（3）体系结构：一个GFS集群由一个master和大量的chunkserver构成，并被许多客户（Client）访问。如图1所示。Master和chunkserver通常是运行用户层服务进程的Linux机器。只
45、要资源和可靠性允许，chunkserver和client可以运行在同一个机器上。文件被分成固定大小的块。每个块由一个不变的、全局唯一的64位的chunkhandle标识，chunkhandle是在块创建时由master分配的。ChunkServer将块当作Linux文件存储在本地磁盘并可以读和写由chunkhandle和位区间指定的数据。出于可靠性考虑，每一个块被复制到多个chunkserver上。默认情况下，保存3个副本，但这可以由用户指定。Master维护文件系统所以的元数据（metadata），包括名字空间、访问控制信息、从文件到块的映射以及块的当前位置。它也控制系统范围的活动，如块租约（lease）管理，孤儿块的垃圾收集，chunkserver间的块迁移。Master定期通过HeartBeat消息与每一个chunkserver通信，给chunkserver传递指令并收集它的状态。与每个应用相联的GFS客户代码实现了文件系统的API并与master和chunkserver通信以代表应用程序读和写数据。客户与master的交换只限于对元数据（metadata）的操作，所有数据方面的通信都直接和chunkserver联系。客户和chunkserver都不缓存文件数据。因为用户缓存的益处微乎其微，这是由于数据太多或工作集
