谷歌三大核心技术
转自：http://blog.csdn.net/hguisu/article/details/7244798javascript
转自：http://blog.csdn.net/hguisu/article/details/7244981php
转自：http://blog.csdn.net/hguisu/article/details/7244991html
本文转载了Google的三大核心技术，做为学习的记录须要的时候及时翻看。java
The Google File System中文版
摘要
分类和主题描述
经常使用术语
关键词
1. 简介
2.设计概述
2.1设计预期
在设计知足咱们需求的文件系统时候，咱们的设计目标既有机会、又有挑战。以前咱们已经提到了一些须要关注的关键点，这里咱们将设计的预期目标的细节展开讨论。node
- 系统由许多廉价的普通组件组成，组件失效是一种常态。系统必须持续监控自身的状态，它必须将组件失效做为一种常态，可以迅速地侦测、冗余并恢复失效的组件。
- 系统存储必定数量的大文件。咱们预期会有几百万文件，文件的大小一般在100MB或者以上。数个GB大小的文件也是广泛存在，而且要可以被有效的管理。系统也必须支持小文件，可是不须要针对小文件作专门的优化。
- 系统的工做负载主要由两种读操做组成：大规模的流式读取和小规模的随机读取。大规模的流式读取一般一次读取数百KB的数据，更常见的是一次读取1MB甚至更多的数据。来自同一个客户机的连续操做一般是读取同一个文件中连续的一个区域。小规模的随机读取一般是在文件某个随机的位置读取几个KB数据。若是应用程序对性能很是关注，一般的作法是把小规模的随机读取操做合并并排序，以后按顺序批量读取，这样就避免了在文件中先后来回的移动读取位置。
- 系统的工做负载还包括许多大规模的、顺序的、数据追加方式的写操做。通常状况下，每次写入的数据的大小和大规模读相似。数据一旦被写入后，文件就不多会被修改了。系统支持小规模的随机位置写入操做，可是可能效率不彰。
- 系统必须高效的、行为定义明确的（alex注：well-defined）实现多客户端并行追加数据到同一个文件里的语意。咱们的文件一般被用于”生产者-消费者“队列，或者其它多路文件合并操做。一般会有数百个生产者，每一个生产者进程运行在一台机器上，同时对一个文件进行追加操做。使用最小的同步开销来实现的原子的多路追加数据操做是必不可少的。文件能够在稍后读取，或者是消费者在追加的操做的同时读取文件。
- 高性能的稳定网络带宽远比低延迟重要。咱们的目标程序绝大部分要求可以高速率的、大批量的处理数据，极少有程序对单一的读写操做有严格的响应时间要求。
2.2 接口
2.3 架构
2.4 单一Master节点
2.5 Chunk尺寸
2.6 元数据
2.6.1 内存中的数据结构
2.6.2 Chunk位置信息
Master服务器并不保存持久化保存哪一个Chunk服务器存有指定Chunk的副本的信息。Master服务器只是在启动的时候轮询Chunk服务器以获取这些信息。Master服务器可以保证它持有的信息始终是最新的，由于它控制了全部的Chunk位置的分配，并且经过周期性的心跳信息监控Chunk服务器的状态。mysql
最初设计时，咱们试图把Chunk的位置信息持久的保存在Master服务器上，可是后来咱们发如今启动的时候轮询Chunk服务器，以后按期轮询更新的方式更简单。这种设计简化了在有Chunk服务器加入集群、离开集群、改名、失效、以及重启的时候，Master服务器和Chunk服务器数据同步的问题。在一个拥有数百台服务器的集群中，这类事件会频繁的发生。linux
能够从另一个角度去理解这个设计决策：只有Chunk服务器才能最终肯定一个Chunk是否在它的硬盘上。咱们从没有考虑过在Master服务器上维护一个这些信息的全局视图，由于Chunk服务器的错误可能会致使Chunk自动消失(好比，硬盘损坏了或者没法访问了)，亦或者操做人员可能会重命名一个Chunk服务器。程序员
2.6.3 操做日志
操做日志包含了关键的元数据变动历史记录。这对GFS很是重要。这不只仅是由于操做日志是元数据惟一的持久化存储记录，它也做为判断同步操做顺序的逻辑时间基线（alex注：也就是经过逻辑日志的序号做为操做发生的逻辑时间，相似于事务系统中的LSN）。文件和Chunk，连同它们的版本(参考4.5节)，都由它们建立的逻辑时间惟一的、永久的标识。web
操做日志很是重要，咱们必须确保日志文件的完整，确保只有在元数据的变化被持久化后，日志才对客户端是可见的。不然，即便Chunk自己没有出现任何问题，咱们仍有可能丢失整个文件系统，或者丢失客户端最近的操做。因此，咱们会把日志复制到多台远程机器，而且只有把相应的日志记录写入到本地以及远程机器的硬盘后，才会响应客户端的操做请求。Master服务器会收集多个日志记录后批量处理，以减小写入磁盘和复制对系统总体性能的影响。正则表达式
因为建立一个Checkpoint文件须要必定的时间，因此Master服务器的内部状态被组织为一种格式，这种格式要确保在Checkpoint过程当中不会阻塞正在进行的修改操做。Master服务器使用独立的线程切换到新的日志文件和建立新的Checkpoint文件。新的Checkpoint文件包括切换前全部的修改。对于一个包含数百万个文件的集群，建立一个Checkpoint文件须要1分钟左右的时间。建立完成后，Checkpoint文件会被写入在本地和远程的硬盘里。
Master服务器恢复只须要最新的Checkpoint文件和后续的日志文件。旧的Checkpoint文件和日志文件能够被删除，可是为了应对灾难性的故障（alex注：catastrophes，数据备份相关文档中常常会遇到这个词，表示一种超出预期范围的灾难性事件），咱们一般会多保存一些历史文件。Checkpoint失败不会对正确性产生任何影响，由于恢复功能的代码能够检测并跳过没有完成的Checkpoint文件。
2.7 一致性模型
GFS支持一个宽松的一致性模型，这个模型可以很好的支撑咱们的高度分布的应用，同时还保持了相对简单且容易实现的优势。本节咱们讨论GFS的一致性的保障机制，以及对应用程序的意义。咱们也着重描述了GFS如何管理这些一致性保障机制，可是实现的细节将在本论文的其它部分讨论。
2.7.1 GFS一致性保障机制
文件命名空间的修改（例如，文件建立）是原子性的。它们仅由Master节点的控制：命名空间锁提供了原子性和正确性（4.1章）的保障；Master节点的操做日志定义了这些操做在全局的顺序（2.6.3章）。
数据修改后文件region（alex注：region这个词用中文很是难以表达，我认为应该是修改操做所涉及的文件中的某个范围）的状态取决于操做的类型、成功与否、以及是否同步修改。表1总结了各类操做的结果。若是全部客户端，不管从哪一个副本读取，读到的数据都同样，那么咱们认为文件region是“一致的”；若是对文件的数据修改以后，region是一致的，而且客户端可以看到写入操做所有的内容，那么这个region是“已定义的”。当一个数据修改操做成功执行，而且没有受到同时执行的其它写入操做的干扰，那么影响的region就是已定义的（隐含了一致性）：全部的客户端均可以看到写入的内容。并行修改操做成功完成以后，region处于一致的、未定义的状态：全部的客户端看到一样的数据，可是没法读到任何一次写入操做写入的数据。一般状况下，文件region内包含了来自多个修改操做的、混杂的数据片断。失败的修改操做致使一个region处于不一致状态（同时也是未定义的）：不一样的客户在不一样的时间会看到不一样的数据。后面咱们将描述应用如何区分已定义和未定义的region。应用程序没有必要再去细分未定义region的不一样类型。
通过了一系列的成功的修改操做以后，GFS确保被修改的文件region是已定义的，而且包含最后一次修改操做写入的数据。GFS经过如下措施确保上述行为：（a） 对Chunk的全部副本的修改操做顺序一致（3.1章），（b）使用Chunk的版本号来检测副本是否由于它所在的Chunk服务器宕机（4.5章）而错过了修改操做而致使其失效。失效的副本不会再进行任何修改操做，Master服务器也再也不返回这个Chunk副本的位置信息给客户端。它们会被垃圾收集系统尽快回收。
2.7.2 程序的实现
3. 系统交互
3.1 租约（lease）和变动顺序
（alex注：lease是数据库中的一个术语）
变动是一个会改变Chunk内容或者元数据的操做，好比写入操做或者记录追加操做。变动操做会在Chunk的全部副本上执行。咱们使用租约（lease）机制来保持多个副本间变动顺序的一致性。Master节点为Chunk的一个副本创建一个租约，咱们把这个副本叫作主Chunk。主Chunk对Chunk的全部更改操做进行序列化。全部的副本都听从这个序列进行修改操做。所以，修改操做全局的顺序首先由Master节点选择的租约的顺序决定，而后由租约中主Chunk分配的序列号决定。
在图2中，咱们依据步骤编号，展示写入操做的控制流程。
- 客户机向Master节点询问哪个Chunk服务器持有当前的租约，以及其它副本的位置。若是没有一个Chunk持有租约，Master节点就选择其中一个副本创建一个租约（这个步骤在图上没有显示）。
- Master节点将主Chunk的标识符以及其它副本（又称为secondary副本、二级副本）的位置返回给客户机。客户机缓存这些数据以便后续的操做。只有在主Chunk不可用，或者主Chunk回复信息代表它已再也不持有租约的时候，客户机才须要从新跟Master节点联系。
- 客户机把数据推送到全部的副本上。客户机能够以任意的顺序推送数据。Chunk服务器接收到数据并保存在它的内部LRU缓存中，一直到数据被使用或者过时交换出去。因为数据流的网络传输负载很是高，经过分离数据流和控制流，咱们能够基于网络拓扑状况对数据流进行规划，提升系统性能，而不用去理会哪一个Chunk服务器保存了主Chunk。3.2章节会进一步讨论这点。
- 当全部的副本都确认接收到了数据，客户机发送写请求到主Chunk服务器。这个请求标识了早前推送到全部副本的数据。主Chunk为接收到的全部操做分配连续的序列号，这些操做可能来自不一样的客户机，序列号保证了操做顺序执行。它以序列号的顺序把操做应用到它本身的本地状态中（alex注：也就是在本地执行这些操做，这句话按字面翻译有点费解，也许应该翻译为“它顺序执行这些操做，并更新本身的状态”）。
- 主Chunk把写请求传递到全部的二级副本。每一个二级副本依照主Chunk分配的序列号以相同的顺序执行这些操做。
- 全部的二级副本回复主Chunk，它们已经完成了操做。
- 主Chunk服务器（alex注：即主Chunk所在的Chunk服务器）回复客户机。任何副本产生的任何错误都会返回给客户机。在出现错误的状况下，写入操做可能在主Chunk和一些二级副本执行成功。（若是操做在主Chunk上失败了，操做就不会被分配序列号，也不会被传递。）客户端的请求被确认为失败，被修改的region处于不一致的状态。咱们的客户机代码经过重复执行失败的操做来处理这样的错误。在从头开始重复执行以前，客户机会先从步骤（3）到步骤（7）作几回尝试。
3.2 数据流
3.3 原子的记录追加
3.4 快照
4. Master节点的操做
4.1 名称空间管理和锁
由于名称空间可能有不少节点，读写锁采用惰性分配策略，在再也不使用的时候马上被删除。一样，锁的获取也要依据一个全局一致的顺序来避免死锁：首先按名称空间的层次排序，在同一个层次内按字典顺序排序。
4.2 副本的位置
4.3 建立，从新复制，从新负载均衡
4.4 垃圾回收
4.4.1 机制
4.4.2 讨论
4.5 过时失效的副本检测
5. 容错和诊断
5.1 高可用性
5.1.1 快速恢复
5.1.2 Chunk复制
正如以前讨论的，每一个Chunk都被复制到不一样机架上的不一样的Chunk服务器上。用户能够为文件命名空间的不一样部分设定不一样的复制级别。缺省是3。当有Chunk服务器离线了，或者经过Chksum校验（参考5.2节）发现了已经损坏的数据，Master节点经过克隆已有的副本保证每一个Chunk都被完整复制（alex注：即每一个Chunk都有复制因子制定的个数个副本，缺省是3）。虽然Chunk复制策略对咱们很是有效，可是咱们也在寻找其它形式的跨服务器的冗余解决方案，好比使用奇偶校验、或者Erasure codes（alex注：Erasure codes用来解决连接层中不相关的错误，以及网络拥塞和buffer限制形成的丢包错误）来解决咱们日益增加的只读存储需求。咱们的系统主要的工做负载是追加方式的写入和读取操做，不多有随机的写入操做，所以，咱们认为在咱们这个高度解耦合的系统架构下实现这些复杂的冗余方案颇有挑战性，但并不是不可实现。
5.1.3 Master服务器的复制
此外，GFS中还有些“影子”Master服务器，这些“影子”服务器在“主”Master服务器宕机的时候提供文件系统的只读访问。它们是影子，而不是镜像，因此它们的数据可能比“主”Master服务器更新要慢，一般是不到1秒。对于那些不常常改变的文件、或者那些容许获取的数据有少许过时的应用程序，“影子”Master服务器可以提升读取的效率。事实上，由于文件内容是从Chunk服务器上读取的，所以，应用程序不会发现过时的文件内容。在这个短暂的时间窗内，过时的多是文件的元数据，好比目录的内容或者访问控制信息。
“影子”Master服务器为了保持自身状态是最新的，它会读取一份当前正在进行的操做的日志副本，而且依照和主Master服务器彻底相同的顺序来更改内部的数据结构。和主Master服务器同样，“影子”Master服务器在启动的时候也会从Chunk服务器轮询数据（以后按期拉数据），数据中包括了Chunk副本的位置信息；“影子”Master服务器也会按期和Chunk服务器“握手”来肯定它们的状态。在主Master服务器因建立和删除副本致使副本位置信息更新时，“影子”Master服务器才和主Master服务器通讯来更新自身状态。
5.2 数据完整性
每一个Chunk服务器都使用Checksum来检查保存的数据是否损坏。考虑到一个GFS集群一般都有好几百台机器、几千块硬盘，磁盘损坏致使数据在读写过程当中损坏或者丢失是很是常见的（第7节讲了一个缘由）。咱们能够经过别的Chunk副原本解决数据损坏问题，可是跨越Chunk服务器比较副原本检查数据是否损坏很不实际。另外，GFS容许有歧义的副本存在：GFS修改操做的语义，特别是早先讨论过的原子纪录追加的操做，并不保证副本彻底相同(alex注：副本不是byte-wise彻底一致的)。所以，每一个Chunk服务器必须独立维护Checksum来校验本身的副本的完整性。
咱们把每一个Chunk都分红64KB大小的块。每一个块都对应一个32位的Checksum。和其它元数据同样，Checksum与其它的用户数据是分开的，而且保存在内存和硬盘上，同时也记录操做日志。
对于读操做来讲，在把数据返回给客户端或者其它的Chunk服务器以前，Chunk服务器会校验读取操做涉及的范围内的块的Checksum。所以Chunk服务器不会把错误数据传递到其它的机器上。若是发生某个块的Checksum不正确，Chunk服务器返回给请求者一个错误信息，而且通知Master服务器这个错误。做为回应，请求者应当从其它副本读取数据，Master服务器也会从其它副本克隆数据进行恢复。当一个新的副本就绪后，Master服务器通知副本错误的Chunk服务器删掉错误的副本。
Checksum对读操做的性能影响很小，能够基于几个缘由来分析一下。由于大部分的读操做都至少要读取几个块，而咱们只须要读取一小部分额外的相关数据进行校验。GFS客户端代码经过每次把读取操做都对齐在Checksum block的边界上，进一步减小了这些额外的读取操做的负面影响。另外，在Chunk服务器上，Chunksum的查找和比较不须要I/O操做，Checksum的计算能够和I/O操做同时进行。
Checksum的计算针对在Chunk尾部的追加写入操做做了高度优化（与之对应的是覆盖现有数据的写入操做），由于这类操做在咱们的工做中占了很大比例。咱们只增量更新最后一个不完整的块的Checksum，而且用全部的追加来的新Checksum块来计算新的Checksum。即便是最后一个不完整的Checksum块已经损坏了，并且咱们不可以立刻检查出来，因为新的Checksum和已有数据不吻合，在下次对这个块进行读取操做的时候，会检查出数据已经损坏了。
相比之下，若是写操做覆盖已经存在的一个范围内的Chunk，咱们必须读取和校验被覆盖的第一个和最后一个块，而后再执行写操做；操做完成以后再从新计算和写入新的Checksum。若是咱们不校验第一个和最后一个被写的块，那么新的Checksum可能会隐藏没有被覆盖区域内的数据错误。
在Chunk服务器空闲的时候，它会扫描和校验每一个不活动的Chunk的内容。这使得咱们可以发现不多被读取的Chunk是否完整。一旦发现有Chunk的数据损坏，Master能够建立一个新的、正确的副本，而后把损坏的副本删除掉。这个机制也避免了非活动的、已损坏的Chunk欺骗Master节点，使Master节点认为它们已经有了足够多的副本了。
5.3 诊断工具
详尽的、深刻细节的诊断日志，在问题隔离、调试、以及性能分析等方面给咱们带来没法估量的帮助，同时也只须要很小的开销。没有日志的帮助，咱们很难理解短暂的、不重复的机器之间的消息交互。GFS的服务器会产生大量的日志，记录了大量关键的事件（好比，Chunk服务器启动和关闭）以及全部的RPC的请求和回复。这些诊断日志能够随意删除，对系统的正确运行不形成任何影响。然而，咱们在存储空间容许的状况下会尽可能的保存这些日志。
RPC日志包含了网络上发生的全部请求和响应的详细记录，可是不包括读写的文件数据。经过匹配请求与回应，以及收集不一样机器上的RPC日志记录，咱们能够重演全部的消息交互来诊断问题。日志还用来跟踪负载测试和性能分析。
日志对性能的影响很小（远小于它带来的好处），由于这些日志的写入方式是顺序的、异步的。最近发生的事件日志保存在内存中，可用于持续不断的在线监控。
6. 度量
6.1 小规模基准测试
6.1.1 读取
6.1.2 写入
6.1.3 记录追加
图3（c）显示了记录追加操做的性能。N个客户机同时追加数据到一个文件。记录追加操做的性能受限于保存文件最后一个Chunk的Chunk服务器的带宽，而与客户机的数量无关。记录追加的速度由一个客户机的6.0MB/s开始，降低到16个客户机的4.8MB/s为止，速度的降低主要是因为不一样客户端的网络拥塞以及网络传输速度的不一样而致使的。
咱们的程序倾向于同时处理多个这样的文件。换句话说，即N个客户机同时追加数据到M个共享文件中，这里N和M都是数十或者数百以上。因此，在咱们的实际应用中，Chunk服务器的网络拥塞并无成为一个严重问题，若是Chunk服务器的某个文件正在写入，客户机会去写另一个文件。
6.2 实际应用中的集群
6.2.1 存储
如上表前五行所描述的，两个集群都由上百台Chunk服务器组成，支持数TB的硬盘空间；两个集群虽然都存储了大量的数据，可是还有剩余的空间。“已用空间”包含了全部的Chunk副本。实际上全部的文件都复制了三份。所以，集群实际上各存储了18TB和52TB的文件数据。
两个集群存储的文件数量都差很少，可是集群B上有大量的死文件。所谓“死文件”是指文件被删除了或者是被新版本的文件替换了，可是存储空间尚未来得及被回收。因为集群B存储的文件较大，所以它的Chunk数量也比较多。
6.2.2 元数据
Chunk服务器总共保存了十几GB的元数据，大多数是来自用户数据的、64KB大小的块的Checksum。保存在Chunk服务器上其它的元数据是Chunk的版本号信息，咱们在4.5节描述过。
在Master服务器上保存的元数据就小的多了，大约只有数十MB，或者说平均每一个文件100字节的元数据。这和咱们设想的是同样的，Master服务器的内存大小在实际应用中并不会成为GFS系统容量的瓶颈。大多数文件的元数据都是之前缀压缩模式存放的文件名。Master服务器上存放的其它元数据包括了文件的全部者和权限、文件到Chunk的映射关系，以及每个Chunk的当前版本号。此外，针对每个Chunk，咱们都保存了当前的副本位置以及对它的引用计数，这个引用计数用于实现写时拷贝（alex注：即COW，copy-on-write）。
对于每个单独的服务器，不管是Chunk服务器仍是Master服务器，都只保存了50MB到100MB的元数据。所以，恢复服务器是很是快速的：在服务器响应客户请求以前，只须要花几秒钟时间从磁盘上读取这些数据就能够了。不过，Master服务器会持续颠簸一段时间–一般是30到60秒–直到它完成轮询全部的Chunk服务器，并获取到全部Chunk的位置信息。
6.2.3 读写速率
6.2.4 Master服务器的负载
6.2.5 恢复时间
6.3 工做负荷分析(Workload Breakdown)
6.3.1 方法论和注意事项
6.3.2 Chunk服务器工做负荷
表4显示了操做按涉及的数据量大小的分布状况。读取操做按操做涉及的数据量大小呈现了双峰分布。小的读取操做（小于64KB）通常是由查找操做的客户端发起的，目的在于从巨大的文件中查找小块的数据。大的读取操做（大于512KB）通常是从头至尾顺序的读取整个文件。
在集群Y上，有至关数量的读操做没有返回任何的数据。在咱们的应用中，尤为是在生产系统中，常用文件做为生产者-消费者队列。生产者并行的向文件中追加数据，同时，消费者从文件的尾部读取数据。某些状况下，消费者读取的速度超过了生产者写入的速度，这就会致使没有读到任何数据的状况。集群X一般用于短暂的数据分析任务，而不是长时间运行的分布式应用，所以，集群X不多出现这种状况。
写操做按数据量大小也一样呈现为双峰分布。大的写操做（超过256KB）一般是因为Writer使用了缓存机制致使的。Writer缓存较小的数据，经过频繁的Checkpoint或者同步操做，或者只是简单的统计小的写入（小于64KB）的数据量(alex注：即聚集屡次小的写入操做，当数据量达到一个阈值，一次写入)，以后批量写入。
再来观察一下记录追加操做。咱们能够看到集群Y中大的记录追加操做所占比例比集群X多的多，这是由于集群Y用于咱们的生产系统，针对GFS作了更全面的调优。
6.3.3 记录追加 vs. 写操做
如同咱们所预期的，咱们的数据修改操做主要是记录追加操做而不是覆盖方式的写操做。咱们测量了第一个副本的数据覆盖写的状况。这近似于一个客户机故意覆盖刚刚写入的数据，而不是增长新的数据。对于集群X，覆盖写操做在写操做所占据字节上的比例小于0.0001%，在所占据操做数量上的比例小于0.0003%。对于集群Y，这两个比率都是0.05%。虽然这只是某一片段的状况，可是仍然高于咱们的预期。这是因为这些覆盖写的操做，大部分是因为客户端在发生错误或者超时之后重试的状况。这在本质上应该不算做工做负荷的一部分，而是重试机制产生的结果。
6.3.4 Master的工做负荷
7. 经验
8. 相关工做
9. 结束语
致谢
Kramer worked on performance enhancements. Fay Chang, Urs Hoelzle, Max Ibel, Sharon Perl, Rob Pike, and Debby Wallach commented on earlier drafts of the paper. Many of our colleagues at Google bravely trusted their data to a new file system and gave us useful feedback. Yoshka helped with early testing.
参考
[4] Garth A. Gibson, David F. Nagle, Khalil Amiri, Jeff Butler, Fay W. Chang, Howard Gobioff, Charles Hardin, ErikR iedel, David Rochberg, and Jim Zelenka. A cost-effective, high-bandwidth storage architecture. In Proceedings of the 8th Architectural Support for Programming Languages and Operating Systems, pages 92–103, San Jose, California, October 1998.
Google MapReduce中文版
摘要
一、介绍
二、编程模型
2.一、例子
map(String key, String value):
// key: document name
// value: document contents
for each word w in value:
EmitIntermediate(w, “1″);
reduce(String key, Iterator values):
// key: a word
// values: a list of counts
int result = 0;
for each v in values:
result += ParseInt(v);
Emit(AsString(result));
2.二、类型
map(k1,v1) ->list(k2,v2)
reduce(k2,list(v2)) ->list(v2)
好比，输入的key和value值与输出的key和value值在类型上推导的域不一样。此外，中间key和value值与输出key和value值在类型上推导的域相同。
（alex注：原文中这个domain的含义不是很清楚，我参考Hadoop、KFS等实现，map和reduce都使用了泛型，所以，我把domain翻译成类型推导的域）。
咱们的C++中使用字符串类型做为用户自定义函数的输入输出，用户在本身的代码中对字符串进行适当的类型转换。
2.三、更多的例子
- 分布式的Grep：Map函数输出匹配某个模式的一行，Reduce函数是一个恒等函数，即把中间数据复制到输出。
- 计算URL访问频率：Map函数处理日志中web页面请求的记录，而后输出(URL,1)。Reduce函数把相同URL的value值都累加起来，产生(URL,记录总数)结果。
- 倒转网络连接图：Map函数在源页面（source）中搜索全部的连接目标（target）并输出为(target,source)。Reduce函数把给定连接目标（target）的连接组合成一个列表，输出(target,list(source))。
- 每一个主机的检索词向量：检索词向量用一个(词,频率)列表来概述出如今文档或文档集中的最重要的一些词。Map函数为每个输入文档输出(主机名,检索词向量)，其中主机名来自文档的URL。Reduce函数接收给定主机的全部文档的检索词向量，并把这些检索词向量加在一块儿，丢弃掉低频的检索词，输出一个最终的(主机名,检索词向量)。
- 倒排索引：Map函数分析每一个文档输出一个(词,文档号)的列表，Reduce函数的输入是一个给定词的全部（词，文档号），排序全部的文档号，输出(词,list（文档号）)。全部的输出集合造成一个简单的倒排索引，它以一种简单的算法跟踪词在文档中的位置。
- 分布式排序：Map函数从每一个记录提取key，输出(key,record)。Reduce函数不改变任何的值。这个运算依赖分区机制(在4.1描述)和排序属性(在4.2描述)。
三、实现
1.x86架构、运行Linux操做系统、双处理器、2-4GB内存的机器。
2.普通的网络硬件设备，每一个机器的带宽为百兆或者千兆，可是远小于网络的平均带宽的一半。 （alex注：这里须要网络专家解释一下了）
3.集群中包含成百上千的机器，所以，机器故障是常态。
4.存储为廉价的内置IDE硬盘。一个内部分布式文件系统用来管理存储在这些磁盘上的数据。文件系统经过数据复制来在不可靠的硬件上保证数据的可靠性和有效性。
5.用户提交工做（job）给调度系统。每一个工做（job）都包含一系列的任务（task），调度系统将这些任务调度到集群中多台可用的机器上。
3.一、执行归纳
1.用户程序首先调用的MapReduce库将输入文件分红M个数据片度，每一个数据片断的大小通常从 16MB到64MB(能够经过可选的参数来控制每一个数据片断的大小)。而后用户程序在机群中建立大量的程序副本。 （alex：copies of the program还真难翻译）
2.这些程序副本中的有一个特殊的程序–master。副本中其它的程序都是worker程序，由master分配任务。有M个Map任务和R个Reduce任务将被分配，master将一个Map任务或Reduce任务分配给一个空闲的worker。
3.被分配了map任务的worker程序读取相关的输入数据片断，从输入的数据片断中解析出key/value pair，而后把key/value pair传递给用户自定义的Map函数，由Map函数生成并输出的中间key/value pair，并缓存在内存中。
4.缓存中的key/value pair经过分区函数分红R个区域，以后周期性的写入到本地磁盘上。缓存的key/value pair在本地磁盘上的存储位置将被回传给master，由master负责把这些存储位置再传送给Reduce worker。
5.当Reduce worker程序接收到master程序发来的数据存储位置信息后，使用RPC从Map worker所在主机的磁盘上读取这些缓存数据。当Reduce worker读取了全部的中间数据后，经过对key进行排序后使得具备相同key值的数据聚合在一块儿。因为许多不一样的key值会映射到相同的Reduce任务上，所以必须进行排序。若是中间数据太大没法在内存中完成排序，那么就要在外部进行排序。
6.Reduce worker程序遍历排序后的中间数据，对于每个惟一的中间key值，Reduce worker程序将这个key值和它相关的中间value值的集合传递给用户自定义的Reduce函数。Reduce函数的输出被追加到所属分区的输出文件。
7.当全部的Map和Reduce任务都完成以后，master唤醒用户程序。在这个时候，在用户程序里的对MapReduce调用才返回。
在成功完成任务以后，MapReduce的输出存放在R个输出文件中（对应每一个Reduce任务产生一个输出文件，文件名由用户指定）。通常状况下，用户不须要将这R个输出文件合并成一个文件–他们常常把这些文件做为另一个MapReduce的输入，或者在另一个能够处理多个分割文件的分布式应用中使用。
3.二、Master数据结构
3.三、容错
master周期性的ping每一个worker。若是在一个约定的时间范围内没有收到worker返回的信息，master将把这个worker标记为失效。全部由这个失效的worker完成的Map任务被重设为初始的空闲状态，以后这些任务就能够被安排给其余的worker。一样的，worker失效时正在运行的Map或Reduce任务也将被从新置为空闲状态，等待从新调度。
当worker故障时，因为已经完成的Map任务的输出存储在这台机器上，Map任务的输出已不可访问了，所以必须从新执行。而已经完成的Reduce任务的输出存储在全局文件系统上，所以不须要再次执行。
一个简单的解决办法是让master周期性的将上面描述的数据结构 （alex注：指3.2节）的写入磁盘，即检查点（checkpoint）。若是这个master任务失效了，能够从最后一个检查点（checkpoint）开始启动另外一个master进程。然而，因为只有一个master进程，master失效后再恢复是比较麻烦的，所以咱们如今的实现是若是master失效，就停止MapReduce运算。客户能够检查到这个状态，而且能够根据须要从新执行MapReduce操做。
（alex注：原文为”semantics in the presence of failures”）
当用户提供的Map和Reduce操做是输入肯定性函数（即相同的输入产生相同的输出）时，咱们的分布式实如今任何状况下的输出都和全部程序没有出现任何错误、顺序的执行产生的输出是同样的。
使用MapReduce模型的程序员能够很容易的理解他们程序的行为，由于咱们绝大多数的Map和Reduce操做是肯定性的，并且存在这样的一个事实：咱们的失效处理机制等价于一个顺序的执行的操做。当Map或/和Reduce操做是不肯定性的时候，咱们提供虽然较弱可是依然合理的处理机制。当使用非肯定操做的时候，一个Reduce任务R1的输出等价于一个非肯定性程序顺序执行产生时的输出。可是，另外一个Reduce任务R2的输出也许符合一个不一样的非肯定顺序程序执行产生的R2的输出。
3.四、存储位置
3.五、任务粒度
可是实际上，在咱们的具体实现中对M和R的取值都有必定的客观限制，由于master必须执行O(M+R)次调度，而且在内存中保存O(M*R)个状态（对影响内存使用的因素仍是比较小的：O(M*R)块状态，大概每对Map任务/Reduce任务1个字节就能够了）。
3.六、备用任务
四、技巧
虽然简单的Map和Reduce函数提供的基本功能已经可以知足大部分的计算须要，咱们仍是发掘出了一些有价值的扩展功能。本节将描述这些扩展功能。
4.一、分区函数
4.二、顺序保证
4.三、Combiner函数
部分的合并中间结果能够显著的提升一些MapReduce操做的速度。附录A包含一个使用combiner函数的例子。
4.四、输入和输出的类型
Reader并不是必定要从文件中读取数据，好比，咱们能够很容易的实现一个从数据库里读记录的Reader，或者从内存中的数据结构读取数据的Reader。
相似的，咱们提供了一些预约义的输出数据的类型，经过这些预约义类型可以产生不一样格式的数据。用户采用相似添加新的输入数据类型的方式增长新的输出类型。
4.五、反作用
若是一个任务产生了多个输出文件，咱们没有提供相似两阶段提交的原子操做支持这种状况。所以，对于会产生多个输出文件、而且对于跨文件有一致性要求的任务，都必须是肯定性的任务。可是在实际应用过程当中，这个限制尚未给咱们带来过麻烦。
4.六、跳过损坏的记录
每一个worker进程都设置了信号处理函数捕获内存段异常（segmentation violation）和总线错误（bus error）。在执行Map或者Reduce操做以前，MapReduce库经过全局变量保存记录序号。若是用户程序触发了一个系统信号，消息处理函数将用“最后一口气”经过UDP包向master发送处理的最后一条记录的序号。当master看到在处理某条特定记录不止失败一次时，master就标志着条记录须要被跳过，而且在下次从新执行相关的Map或者Reduce任务的时候跳过这条记录。
4.七、本地执行
4.八、状态信息
另外，处于最顶层的状态页面显示了哪些worker失效了，以及他们失效的时候正在运行的Map和Reduce任务。这些信息对于调试用户代码中的bug颇有帮助。
4.九、计数器
Counter* uppercase;
uppercase = GetCounter(“uppercase”);
map(String name, String contents):
for each word w in contents:
if (IsCapitalized(w)):
uppercase->Increment();
EmitIntermediate(w, “1″);
计数器机制对于MapReduce操做的完整性检查很是有用。好比，在某些MapReduce操做中，用户须要确保输出的key value pair精确的等于输入的key value pair，或者处理的German文档数量在处理的整个文档数量中属于合理范围。
五、性能
5.一、集群配置
在4GB内存里，大概有1-1.5G用于运行在集群上的其余任务。测试程序在周末下午开始执行，这时主机的CPU、磁盘和网络基本上处于空闲状态。
5.二、GREP
图2显示了这个运算随时间的处理过程。其中Y轴表示输入数据的处理速度。处理速度随着参与MapReduce计算的机器数量的增长而增长，当1764台worker参与计算的时，处理速度达到了30GB/s。当Map任务结束的时候，即在计算开始后80秒，输入的处理速度降到0。整个计算过程从开始到结束一共花了大概150秒。这包括了大约一分钟的初始启动阶段。初始启动阶段消耗的时间包括了是把这个程序传送到各个worker机器上的时间、等待GFS文件系统打开1000个输入文件集合的时间、获取相关的文件本地位置优化信息的时间。
5.三、排序
在这个benchmark测试中，咱们使用的分区函数知道key的分区状况。一般对于排序程序来讲，咱们会增长一个预处理的MapReduce操做用于采样key值的分布状况，经过采样的数据来计算对最终排序处理的分区点。
还有一些值得注意的现象：输入数据的读取速度比排序速度和输出数据写入磁盘速度要高很多，这是由于咱们的输入数据本地化优化策略起了做用 — 绝大部分数据都是从本地硬盘读取的，从而节省了网络带宽。排序速度比输出数据写入到磁盘的速度快，这是由于输出数据写了两份（咱们使用了2路的GFS文件系统，写入复制节点的缘由是为了保证数据可靠性和可用性）。咱们把输出数据写入到两个复制节点的缘由是由于这是底层文件系统的保证数据可靠性和可用性的实现机制。若是底层文件系统使用相似容错编码[14](erasure coding)的方式而不是复制的方式保证数据的可靠性和可用性，那么在输出数据写入磁盘的时候，就能够下降网络带宽的使用。
5.四、高效的backup任务
5.五、失效的机器
六、经验
- 大规模机器学习问题
- Google News和Froogle产品的集群问题
- 从公众查询产品（好比Google的Zeitgeist）的报告中抽取数据。
- 从大量的新应用和新产品的网页中提取有用信息（好比，从大量的位置搜索网页中抽取地理位置信息）。
- 大规模的图形计算。
在每一个任务结束的时候，MapReduce库统计计算资源的使用情况。在表1，咱们列出了2004年8月份MapReduce运行的任务所占用的相关资源。
6.一、大规模索引
- 实现索引部分的代码简单、小巧、容易理解，由于对于容错、分布式以及并行计算的处理都是MapReduce库提供的。好比，使用MapReduce库，计算的代码行数从原来的3800行C++代码减小到大概700行代码。
- MapReduce库的性能已经足够好了，所以咱们能够把在概念上不相关的计算步骤分开处理，而不是混在一块儿以期减小数据传递的额外消耗。概念上不相关的计算步骤的隔离也使得咱们能够很容易改变索引处理方式。好比，对以前的索引系统的一个小更改可能要耗费好几个月的时间，可是在使用MapReduce的新系统上，这样的更改只须要花几天时间就能够了。
- 索引系统的操做管理更容易了。由于由机器失效、机器处理速度缓慢、以及网络的瞬间阻塞等引发的绝大部分问题都已经由MapReduce库解决了，再也不须要操做人员的介入了。另外，咱们能够经过在索引系统集群中增长机器的简单方法提升总体处理性能。
七、相关工做
TACC[7]是一个用于简化构造高可用性网络服务的系统。和MapReduce同样，它也依靠从新执行机制来实现的容错处理。
八、结束语
咱们也从MapReduce开发过程当中学到了很多东西。首先，约束编程模式使得并行和分布式计算很是容易，也易于构造容错的计算环境；其次，网络带宽是稀有资源。大量的系统优化是针对减小网络传输量为目的的：本地优化策略使大量的数据从本地磁盘读取，中间文件写入本地磁盘、而且只写一份中间文件也节约了网络带宽；第三，屡次执行相同的任务能够减小性能缓慢的机器带来的负面影响（alex注：即硬件配置的不平衡），同时解决了因为机器失效致使的数据丢失问题。
九、感谢
十、参考资料
[2] Remzi H. Arpaci-Dusseau, Eric Anderson, NoahTreuhaft, David E. Culler, Joseph M. Hellerstein, David Patterson, and Kathy Yelick. Cluster I/O with River:Making the fast case common. In Proceedings of the Sixth Workshop on Input/Output in Parallel and Distributed Systems (IOPADS ’99), pages 10.22, Atlanta, Georgia, May 1999.
[3] Arash Baratloo, Mehmet Karaul, Zvi Kedem, and Peter Wyckoff. Charlotte: Metacomputing on the web. In Proceedings of the 9th International Conference on Parallel and Distributed Computing Systems, 1996. [4] Luiz A. Barroso, Jeffrey Dean, and Urs H¨olzle. Web search for a planet: The Google cluster architecture. IEEE Micro, 23(2):22.28, April 2003.
[5] John Bent, Douglas Thain, Andrea C.Arpaci-Dusseau, Remzi H. Arpaci-Dusseau, and Miron Livny. Explicit control in a batch-aware distributed file system. In Proceedings of the 1st USENIX Symposium on Networked Systems Design and Implementation NSDI, March 2004.
[6] Guy E. Blelloch. Scans as primitive parallel operations.IEEE Transactions on Computers, C-38(11), November 1989.
[7] Armando Fox, Steven D. Gribble, Yatin Chawathe, Eric A. Brewer, and Paul Gauthier. Cluster-based scalable network services. In Proceedings of the 16th ACM Symposium on Operating System Principles, pages 78. 91, Saint-Malo, France, 1997.
[8] Sanjay Ghemawat, Howard Gobioff, and Shun-Tak Leung. The Google file system. In 19th Symposium on Operating Systems Principles, pages 29.43, Lake George, New York, 2003. To appear in OSDI 2004 12
[9] S. Gorlatch. Systematic efficient parallelization of scan and other list homomorphisms. In L. Bouge, P. Fraigniaud, A. Mignotte, and Y. Robert, editors, Euro-Par’96. Parallel Processing, Lecture Notes in Computer Science 1124, pages 401.408. Springer-Verlag, 1996.
[10] Jim Gray. Sort benchmark home page. http://research.microsoft.com/barc/SortBenchmark/.
[11] William Gropp, Ewing Lusk, and Anthony Skjellum. Using MPI: Portable Parallel Programming with the Message-Passing Interface. MIT Press, Cambridge, MA, 1999.
[12] L. Huston, R. Sukthankar, R.Wickremesinghe, M. Satyanarayanan, G. R. Ganger, E. Riedel, and A. Ailamaki. Diamond: A storage architecture for early discard in interactive search. In Proceedings of the 2004 USENIX File and Storage Technologies FAST Conference, April 2004.
[13] Richard E. Ladner and Michael J. Fischer. Parallel prefix computation. Journal of the ACM, 27(4):831.838, 1980.
[14] Michael O. Rabin. Efficient dispersal of information for security, load balancing and fault tolerance. Journal of the ACM, 36(2):335.348, 1989.
[15] Erik Riedel, Christos Faloutsos, Garth A. Gibson, and David Nagle. Active disks for large-scale data processing. IEEE Computer, pages 68.74, June 2001.
[16] Douglas Thain, Todd Tannenbaum, and Miron Livny. Distributed computing in practice: The Condor experience. Concurrency and Computation: Practice and Experience, 2004.
[17] L. G. Valiant. A bridging model for parallel computation. Communications of the ACM, 33(8):103.111, 1997.
[18] Jim Wyllie. Spsort: How to sort a terabyte quickly. http://alme1.almaden.ibm.com/cs/spsort.pdf.
附录A、单词频率统计
#include “mapreduce/mapreduce.h”
// User’s map function
class WordCounter : public Mapper {
public:
virtual void Map(const MapInput& input) {
const string& text = input.value();
const int n = text.size();
for (int i = 0; i < n; ) {
// Skip past leading whitespace
while ((i < n) && isspace(text[i]))
i++;
// Find word end
int start = i;
while ((i < n) && !isspace(text[i]))
i++;
if (start < i)
Emit(text.substr(start,i-start),”1″);
}
}
};
REGISTER_MAPPER(WordCounter);
// User’s reduce function
class Adder : public Reducer {
virtual void Reduce(ReduceInput* input) {
// Iterate over all entries with the
// same key and add the values
int64 value = 0;
while (!input->done()) {
value += StringToInt(input->value());
input->NextValue();
}
// Emit sum for input->key()
Emit(IntToString(value));
}
};
REGISTER_REDUCER(Adder);
int main(int argc, char** argv) {
ParseCommandLineFlags(argc, argv);
MapReduceSpecification spec;
// Store list of input files into “spec”
for (int i = 1; i < argc; i++) {
MapReduceInput* input = spec.add_input();
input->set_format(“text”);
input->set_filepattern(argv[i]);
input->set_mapper_class(“WordCounter”);
}
// Specify the output files:
// /gfs/test/freq-00000-of-00100
// /gfs/test/freq-00001-of-00100
// …
MapReduceOutput* out = spec.output();
out->set_filebase(“/gfs/test/freq”);
out->set_num_tasks(100);
out->set_format(“text”);
out->set_reducer_class(“Adder”);
// Optional: do partial sums within map
// tasks to save network bandwidth
out->set_combiner_class(“Adder”);
// Tuning parameters: use at most 2000
// machines and 100 MB of memory per task
spec.set_machines(2000);
spec.set_map_megabytes(100);
spec.set_reduce_megabytes(100);
// Now run it
MapReduceResult result;
if (!MapReduce(spec, &result)) abort();
// Done: ‘result’ structure contains info
// about counters, time taken, number of
// machines used, etc.
return 0;
}
摘要
Bigtable是一个分布式的结构化数据存储系统，它被设计用来处理海量数据：一般是分布在数千台普通服务器上的PB级的数据。Google的不少项目使用Bigtable存储数据，包括Web索引、Google Earth、Google Finance。这些应用对Bigtable提出的要求差别很是大，不管是在数据量上（从URL到网页到卫星图像）仍是在响应速度上（从后端的批量处理到实时数据服务）。尽管应用需求差别很大，可是，针对Google的这些产品，Bigtable仍是成功的提供了一个灵活的、高性能的解决方案。本论文描述了Bigtable提供的简单的数据模型，利用这个模型，用户能够动态的控制数据的分布和格式；咱们还将描述Bigtable的设计和实现。
1 介绍
在过去两年半时间里，咱们设计、实现并部署了一个分布式的结构化数据存储系统 — 在Google，咱们称之为Bigtable。Bigtable的设计目的是可靠的处理PB级别的数据，而且可以部署到上千台机器上。Bigtable已经实现了下面的几个目标：适用性普遍、可扩展、高性能和高可用性。Bigtable已经在超过60个Google的产品和项目上获得了应用，包括Google Analytics、Google Finance、Orkut、PersonalizedSearch、Writely和Google Earth。这些产品对Bigtable提出了迥异的需求，有的须要高吞吐量的批处理，有的则须要及时响应，快速返回数据给最终用户。它们使用的Bigtable集群的配置也有很大的差别，有的集群只有几台服务器，而有的则须要上千台服务器、存储几百TB的数据。
在不少方面，Bigtable和数据库很相似：它使用了不少数据库的实现策略。并行数据库【14】和内存数据库【13】已经具有可扩展性和高性能，可是Bigtable提供了一个和这些系统彻底不一样的接口。Bigtable不支持完整的关系数据模型；与之相反，Bigtable为客户提供了简单的数据模型，利用这个模型，客户能够动态控制数据的分布和格式（alex注：也就是对BigTable而言，数据是没有格式的，用数据库领域的术语说，就是数据没有Schema，用户本身去定义Schema），用户也能够本身推测(alex注：reasonabout)底层存储数据的位置相关性(alex注：位置相关性能够这样理解，好比树状结构，具备相同前缀的数据的存放位置接近。在读取的时候，能够把这些数据一次读取出来)。数据的下标是行和列的名字，名字能够是任意的字符串。Bigtable将存储的数据都视为字符串，可是Bigtable自己不去解析这些字符串，客户程序一般会在把各类结构化或者半结构化的数据串行化到这些字符串里。经过仔细选择数据的模式，客户能够控制数据的位置相关性。最后，能够经过BigTable的模式参数来控制数据是存放在内存中、仍是硬盘上。
第二节描述关于数据模型更多细节方面的东西；第三节概要介绍了客户端API；第四节简要介绍了BigTable底层使用的Google的基础框架；第五节描述了BigTable实现的关键部分；第6节描述了咱们为了提升BigTable的性能采用的一些精细的调优方法；第7节提供了BigTable的性能数据；第8节讲述了几个Google内部使用BigTable的例子；第9节是咱们在设计和后期支持过程当中获得一些经验和教训；最后，在第10节列出咱们的相关研究工做，第11节是咱们的结论。
2 数据模型
Bigtable是一个稀疏的、分布式的、持久化存储的多维度排序Map（alex注：对于程序员来讲，Map应该不用翻译了吧。Map由key和value组成，后面咱们直接使用key和value，再也不另外翻译了）。Map的索引是行关键字、列关键字以及时间戳；Map中的每一个value都是一个未经解析的byte数组。
(row:string,column:string,time:int64)->string
咱们在仔细分析了一个相似Bigtable的系统的种种潜在用途以后，决定使用这个数据模型。咱们先举个具体的例子，这个例子促使咱们作了不少设计决策；假设咱们想要存储海量的网页及相关信息，这些数据能够用于不少不一样的项目，咱们姑且称这个特殊的表为Webtable。在Webtable里，咱们使用URL做为行关键字，使用网页的某些属性做为列名，网页的内容存在“contents:”列中，并用获取该网页的时间戳做为标识(alex注：即按照获取时间不一样，存储了多个版本的网页数据)，如图一所示。
图一：一个存储Web网页的例子的表的片段。行名是一个反向URL。contents列族存放的是网页的内容，anchor列族存放引用该网页的锚连接文本（alex注：若是不知道HTML的Anchor，请Google一把）。CNN的主页被Sports Illustrater和MY-look的主页引用，所以该行包含了名为“anchor:cnnsi.com”和 “anchhor:my.look.ca”的列。每一个锚连接只有一个版本（alex注：注意时间戳标识了列的版本，t9和t8分别标识了两个锚连接的版本）；而contents列则有三个版本，分别由时间戳t3，t5，和t6标识。
行
表中的行关键字能够是任意的字符串（目前支持最大64KB的字符串，可是对大多数用户，10-100个字节就足够了）。对同一个行关键字的读或者写操做都是原子的（无论读或者写这一行里多少个不一样列），这个设计决策可以使用户很容易的理解程序在对同一个行进行并发更新操做时的行为。
Bigtable经过行关键字的字典顺序来组织数据。表中的每一个行均可以动态分区。每一个分区叫作一个”Tablet”，Tablet是数据分布和负载均衡调整的最小单位。这样作的结果是，当操做只读取行中不多几列的数据时效率很高，一般只须要不多几回机器间的通讯便可完成。用户能够经过选择合适的行关键字，在数据访问时有效利用数据的位置相关性，从而更好的利用这个特性。举例来讲，在Webtable里，经过反转URL中主机名的方式，能够把同一个域名下的网页汇集起来组织成连续的行。具体来讲，咱们能够把maps.google.com/index.html的数据存放在关键字com.google.maps/index.html下。把相同的域中的网页存储在连续的区域可让基于主机和域名的分析更加有效。
列族
列关键字组成的集合叫作“列族“，列族是访问控制的基本单位。存放在同一列族下的全部数据一般都属于同一个类型（咱们能够把同一个列族下的数据压缩在一块儿）。列族在使用以前必须先建立，而后才能在列族中任何的列关键字下存放数据；列族建立后，其中的任何一个列关键字下均可以存放数据。根据咱们的设计意图，一张表中的列族不能太多（最多几百个），而且列族在运行期间不多改变。与之相对应的，一张表能够有无限多个列。
列关键字的命名语法以下：列族：限定词。列族的名字必须是可打印的字符串，而限定词的名字能够是任意的字符串。好比，Webtable有个列族language，language列族用来存放撰写网页的语言。咱们在language列族中只使用一个列关键字，用来存放每一个网页的语言标识ID。Webtable中另外一个有用的列族是anchor；这个列族的每个列关键字表明一个锚连接，如图一所示。Anchor列族的限定词是引用该网页的站点名；Anchor列族每列的数据项存放的是连接文本。
访问控制、磁盘和内存的使用统计都是在列族层面进行的。在咱们的Webtable的例子中，上述的控制权限能帮助咱们管理不一样类型的应用：咱们容许一些应用能够添加新的基本数据、一些应用能够读取基本数据并建立继承的列族、一些应用则只容许浏览数据（甚至可能由于隐私的缘由不能浏览全部数据）。
时间戳
在Bigtable中，表的每个数据项均可以包含同一份数据的不一样版本；不一样版本的数据经过时间戳来索引。Bigtable时间戳的类型是64位整型。Bigtable能够给时间戳赋值，用来表示精确到毫秒的“实时”时间；用户程序也能够给时间戳赋值。若是应用程序须要避免数据版本冲突，那么它必须本身生成具备惟一性的时间戳。数据项中，不一样版本的数据按照时间戳倒序排序，即最新的数据排在最前面。
为了减轻多个版本数据的管理负担，咱们对每个列族配有两个设置参数，Bigtable经过这两个参数能够对废弃版本的数据自动进行垃圾收集。用户能够指定只保存最后n个版本的数据，或者只保存“足够新”的版本的数据（好比，只保存最近7天的内容写入的数据）。
在Webtable的举例里，contents:列存储的时间戳信息是网络爬虫抓取一个页面的时间。上面说起的垃圾收集机制可让咱们只保留最近三个版本的网页数据。
3 API
Bigtable提供了创建和删除表以及列族的API函数。Bigtable还提供了修改集群、表和列族的元数据的API，好比修改访问权限。
| // Open the table Table *T = OpenOrDie(“/bigtable/web/webtable”); // Write a new anchor and delete an old anchor RowMutation r1(T, “com.cnn.www”); r1.Set(“anchor:www.c-span.org”, “CNN”); r1.Delete(“anchor:www.abc.com”); Operation op; Apply(&op, &r1) |
Figure 2: Writing to Bigtable.
客户程序能够对Bigtable进行以下的操做：写入或者删除Bigtable中的值、从每一个行中查找值、或者遍历表中的一个数据子集。图2中的Ｃ++代码使用RowMutation抽象对象进行了一系列的更新操做。（为了保持示例代码的简洁，咱们忽略了一些细节相关代码）。调用Apply函数对Ｗebtable进行了一个原子修改操做：它为www.cnn.com增长了一个锚点，同时删除了另一个锚点。
| Scanner scanner(T); ScanStream *stream; stream = scanner.FetchColumnFamily(“anchor”); stream->SetReturnAllVersions(); scanner.Lookup(“com.cnn.www”); for (; !stream->Done(); stream->Next()) { printf(“%s %s %lld %s\n”, scanner.RowName(), stream->ColumnName(), stream->MicroTimestamp(), stream->Value()); } |
Figure3: Reading from Bigtable.
图3中的C++代码使用Scanner抽象对象遍历一个行内的全部锚点。客户程序能够遍历多个列族，有几种方法能够对扫描输出的行、列和时间戳进行限制。例如，咱们能够限制上面的扫描，让它只输出那些匹配正则表达式*.cnn.com的锚点，或者那些时间戳在当前时间前10天的锚点。
Bigtable还支持一些其它的特性，利用这些特性，用户能够对数据进行更复杂的处理。首先，Bigtable支持单行上的事务处理，利用这个功能，用户能够对存储在一个行关键字下的数据进行原子性的读-更新-写操做。虽然Bigtable提供了一个容许用户跨行批量写入数据的接口，可是，Bigtable目前还不支持通用的跨行事务处理。其次，Bigtable容许把数据项用作整数计数器。最后，Bigtable容许用户在服务器的地址空间内执行脚本程序。脚本程序使用Google开发的Sawzall【28】数据处理语言。虽然目前咱们基于的Sawzall语言的API函数还不容许客户的脚本程序写入数据到Bigtable，可是它容许多种形式的数据转换、基于任意表达式的数据过滤、以及使用多种操做符的进行数据汇总。
Bigtable能够和MapReduce【12】一块儿使用，MapReduce是Google开发的大规模并行计算框架。咱们已经开发了一些Wrapper类，经过使用这些Wrapper类，Bigtable能够做为MapReduce框架的输入和输出。
4 BigTable构件
Bigtable是创建在其它的几个Google基础构件上的。BigTable使用Google的分布式文件系统(GFS)【17】存储日志文件和数据文件。BigTable集群一般运行在一个共享的机器池中，池中的机器还会运行其它的各类各样的分布式应用程序，BigTable的进程常常要和其它应用的进程共享机器。BigTable依赖集群管理系统来调度任务、管理共享的机器上的资源、处理机器的故障、以及监视机器的状态。
BigTable内部存储数据的文件是GoogleSSTable格式的。SSTable是一个持久化的、排序的、不可更改的Map结构，而Map是一个key-value映射的数据结构，key和value的值都是任意的Byte串。能够对SSTable进行以下的操做：查询与一个key值相关的value，或者遍历某个key值范围内的全部的key-value对。从内部看，SSTable是一系列的数据块（一般每一个块的大小是64KB，这个大小是能够配置的）。SSTable使用块索引（一般存储在SSTable的最后）来定位数据块；在打开SSTable的时候，索引被加载到内存。每次查找均可以经过一次磁盘搜索完成：首先使用二分查找法在内存中的索引里找到数据块的位置，而后再从硬盘读取相应的数据块。也能够选择把整个SSTable都放在内存中，这样就没必要访问硬盘了。
BigTable还依赖一个高可用的、序列化的分布式锁服务组件，叫作Chubby【8】。一个Chubby服务包括了5个活动的副本，其中的一个副本被选为Master，而且处理请求。只有在大多数副本都是正常运行的，而且彼此之间可以互相通讯的状况下，Chubby服务才是可用的。当有副本失效的时候，Chubby使用Paxos算法【9,23】来保证副本的一致性。Chubby提供了一个名字空间，里面包括了目录和小文件。每一个目录或者文件能够当成一个锁，读写文件的操做都是原子的。Chubby客户程序库提供对Chubby文件的一致性缓存。每一个Chubby客户程序都维护一个与Chubby服务的会话。若是客户程序不能在租约到期的时间内从新签定会话的租约，这个会话就过时失效了(alex注：又用到了lease。原文是：Aclient’s session expires if it is unable to renew its session lease within the leaseexpiration time.)。当一个会话失效时，它拥有的锁和打开的文件句柄都失效了。Chubby客户程序能够在文件和目录上注册回调函数，当文件或目录改变、或者会话过时时，回调函数会通知客户程序。
Bigtable使用Chubby完成如下的几个任务：确保在任何给定的时间内最多只有一个活动的Master副本；存储BigTable数据的自引导指令的位置（参考5.1节）；查找Tablet服务器，以及在Tablet服务器失效时进行善后（5.2节）；存储BigTable的模式信息（每张表的列族信息）；以及存储访问控制列表。若是Chubby长时间没法访问，BigTable就会失效。最近咱们在使用11个Chubby服务实例的14个BigTable集群上测量了这个影响。因为Chubby不可用而致使BigTable中的部分数据不能访问的平均比率是0.0047%（Chubby不能访问的缘由多是Chubby自己失效或者网络问题）。单个集群里，受Chubby失效影响最大的百分比是0.0326%（alex注：有点莫名其妙，原文是： The percentage for the single cluster that was most affected byChubby unavailability was 0.0326%.）。
5 介绍
Bigtable包括了三个主要的组件：连接到客户程序中的库、一个Master服务器和多个Tablet服务器。针对系统工做负载的变化状况，BigTable能够动态的向集群中添加（或者删除）Tablet服务器。
Master服务器主要负责如下工做：为Tablet服务器分配Tablets、检测新加入的或者过时失效的Table服务器、对Tablet服务器进行负载均衡、以及对保存在GFS上的文件进行垃圾收集。除此以外，它还处理对模式的相关修改操做，例如创建表和列族。
每一个Tablet服务器都管理一个Tablet的集合（一般每一个服务器有大约数十个至上千个Tablet）。每一个Tablet服务器负责处理它所加载的Tablet的读写操做，以及在Tablets过大时，对其进行分割。
和不少Single-Master类型的分布式存储系统【17.21】相似，客户端读取的数据都不通过Master服务器：客户程序直接和Tablet服务器通讯进行读写操做。因为BigTable的客户程序没必要经过Master服务器来获取Tablet的位置信息，所以，大多数客户程序甚至彻底不须要和Master服务器通讯。在实际应用中，Master服务器的负载是很轻的。
一个BigTable集群存储了不少表，每一个表包含了一个Tablet的集合，而每一个Tablet包含了某个范围内的行的全部相关数据。初始状态下，一个表只有一个Tablet。随着表中数据的增加，它被自动分割成多个Tablet，缺省状况下，每一个Tablet的尺寸大约是100MB到200MB。
5.1Tablet的位置
咱们使用一个三层的、相似Ｂ+树[10]的结构存储Tablet的位置信息(如图4)。
第一层是一个存储在Chubby中的文件，它包含了Root Tablet的位置信息。Root Tablet包含了一个特殊的METADATA表里全部的Tablet的位置信息。METADATA表的每一个Tablet包含了一个用户Tablet的集合。RootTablet其实是METADATA表的第一个Tablet，只不过对它的处理比较特殊 — Root Tablet永远不会被分割 — 这就保证了Tablet的位置信息存储结构不会超过三层。
在METADATA表里面，每一个Tablet的位置信息都存放在一个行关键字下面，而这个行关键字是由Tablet所在的表的标识符和Tablet的最后一行编码而成的。METADATA的每一行都存储了大约1KB的内存数据。在一个大小适中的、容量限制为128MB的METADATA Tablet中，采用这种三层结构的存储模式，能够标识2^34个Tablet的地址（若是每一个Tablet存储128MB数据，那么一共能够存储2^61字节数据）。
客户程序使用的库会缓存Tablet的位置信息。若是客户程序没有缓存某个Tablet的地址信息，或者发现它缓存的地址信息不正确，客户程序就在树状的存储结构中递归的查询Tablet位置信息；若是客户端缓存是空的，那么寻址算法须要经过三次网络来回通讯寻址，这其中包括了一次Chubby读操做；若是客户端缓存的地址信息过时了，那么寻址算法可能须要最多６次网络来回通讯才能更新数据，由于只有在缓存中没有查到数据的时候才能发现数据过时（alex注：其中的三次通讯发现缓存过时，另外三次更新缓存数据）(假设METADATA的Tablet没有被频繁的移动）。尽管Tablet的地址信息是存放在内存里的，对它的操做没必要访问GFS文件系统，可是，一般咱们会经过预取Tablet地址来进一步的减小访问的开销：每次须要从METADATA表中读取一个Tablet的元数据的时候，它都会多读取几个Tablet的元数据。
在METADATA表中还存储了次级信息(alex注：secondary information)，包括每一个Tablet的事件日志（例如，何时一个服务器开始为该Tablet提供服务）。这些信息有助于排查错误和性能分析。
5.2Tablet分配
在任何一个时刻，一个Tablet只能分配给一个Tablet服务器。Master服务器记录了当前有哪些活跃的Tablet服务器、哪些Tablet分配给了哪些Tablet服务器、哪些Tablet尚未被分配。当一个Tablet尚未被分配、而且恰好有一个Tablet服务器有足够的空闲空间装载该Tablet时，Master服务器会给这个Tablet服务器发送一个装载请求，把Tablet分配给这个服务器。
BigTable使用Chubby跟踪记录Tablet服务器的状态。当一个Tablet服务器启动时，它在Chubby的一个指定目录下创建一个有惟一性名字的文件，而且获取该文件的独占锁。Master服务器实时监控着这个目录（服务器目录），所以Master服务器可以知道有新的Tablet服务器加入了。若是Tablet服务器丢失了Chubby上的独占锁 — 好比因为网络断开致使Tablet服务器和Chubby的会话丢失 — 它就中止对Tablet提供服务。（Chubby提供了一种高效的机制，利用这种机制，Tablet服务器可以在不增长网络负担的状况下知道它是否还持有锁）。只要文件还存在，Tablet服务器就会试图从新得到对该文件的独占锁；若是文件不存在了，那么Tablet服务器就不能再提供服务了，它会自行退出（alex注：so it killsitself）。当Tablet服务器终止时（好比，集群的管理系统将运行该Tablet服务器的主机从集群中移除），它会尝试释放它持有的文件锁，这样一来，Master服务器就能尽快把Tablet分配到其它的Tablet服务器。
Master服务器负责检查一个Tablet服务器是否已经再也不为它的Tablet提供服务了，而且要尽快从新分配它加载的Tablet。Master服务器经过轮询Tablet服务器文件锁的状态来检测什么时候Tablet服务器再也不为Tablet提供服务。若是一个Tablet服务器报告它丢失了文件锁，或者Master服务器最近几回尝试和它通讯都没有获得响应，Master服务器就会尝试获取该Tablet服务器文件的独占锁；若是Master服务器成功获取了独占锁，那么就说明Chubby是正常运行的，而Tablet服务器要么是宕机了、要么是不能和Chubby通讯了，所以，Master服务器就删除该Tablet服务器在Chubby上的服务器文件以确保它再也不给Tablet提供服务。一旦Tablet服务器在Chubby上的服务器文件被删除了，Master服务器就把以前分配给它的全部的Tablet放入未分配的Tablet集合中。为了确保Bigtable集群在Master服务器和Chubby之间网络出现故障的时候仍然能够使用，Master服务器在它的Chubby会话过时后主动退出。可是无论怎样，如同咱们前面所描述的，Master服务器的故障不会改变现有Tablet在Tablet服务器上的分配状态。
当集群管理系统启动了一个Master服务器以后，Master服务器首先要了解当前Tablet的分配状态，以后才可以修改分配状态。Master服务器在启动的时候执行如下步骤：（1）Master服务器从Chubby获取一个惟一的Master锁，用来阻止建立其它的Master服务器实例；（2）Master服务器扫描Chubby的服务器文件锁存储目录，获取当前正在运行的服务器列表；（3）Master服务器和全部的正在运行的Tablet表服务器通讯，获取每一个Tablet服务器上Tablet的分配信息；（4）Master服务器扫描METADATA表获取全部的Tablet的集合。在扫描的过程当中，当Master服务器发现了一个尚未分配的Tablet，Master服务器就将这个Tablet加入未分配的Tablet集合等待合适的时机分配。
可能会遇到一种复杂的状况：在METADATA表的Tablet尚未被分配以前是不可以扫描它的。所以，在开始扫描以前（步骤4），若是在第三步的扫描过程当中发现Root Tablet尚未分配，Master服务器就把Root Tablet加入到未分配的Tablet集合。这个附加操做确保了Root Tablet会被分配。因为Root Tablet包括了全部METADATA的Tablet的名字，所以Master服务器扫描完Root Tablet之后，就获得了全部的METADATA表的Tablet的名字了。
保存现有Tablet的集合只有在如下事件发生时才会改变：创建了一个新表或者删除了一个旧表、两个Tablet被合并了、或者一个Tablet被分割成两个小的Tablet。Master服务器能够跟踪记录全部这些事件，由于除了最后一个事件外的两个事件都是由它启动的。Tablet分割事件须要特殊处理，由于它是由Tablet服务器启动。在分割操做完成以后，Tablet服务器经过在METADATA表中记录新的Tablet的信息来提交这个操做；当分割操做提交以后，Tablet服务器会通知Master服务器。若是分割操做已提交的信息没有通知到Master服务器（可能两个服务器中有一个宕机了），Master服务器在要求Tablet服务器装载已经被分割的子表的时候会发现一个新的Tablet。经过对比METADATA表中Tablet的信息，Tablet服务器会发现Master服务器要求其装载的Tablet并不完整，所以，Tablet服务器会从新向Master服务器发送通知信息。
5.3Tablet服务
如图5所示，Tablet的持久化状态信息保存在GFS上。更新操做提交到REDO日志中（alex注：Updates are committed to a commit log that stores redo records）。在这些更新操做中，最近提交的那些存放在一个排序的缓存中，咱们称这个缓存为memtable；较早的更新存放在一系列SSTable中。为了恢复一个Tablet，Tablet服务器首先从METADATA表中读取它的元数据。Tablet的元数据包含了组成这个Tablet的SSTable的列表，以及一系列的Redo Point（alex注：a set of redo points），这些Redo Point指向可能含有该Tablet数据的已提交的日志记录。Tablet服务器把SSTable的索引读进内存，以后经过重复Redo Point以后提交的更新来重建memtable。
当对Tablet服务器进行写操做时，Tablet服务器首先要检查这个操做格式是否正确、操做发起者是否有执行这个操做的权限。权限验证的方法是经过从一个Chubby文件里读取出来的具备写权限的操做者列表来进行验证（这个文件几乎必定会存放在Chubby客户缓存里）。成功的修改操做会记录在提交日志里。能够采用批量提交方式（alex注：group commit）来提升包含大量小的修改操做的应用程序的吞吐量【13，16】。当一个写操做提交后，写的内容插入到memtable里面。
当对Tablet服务器进行读操做时，Tablet服务器会做相似的完整性和权限检查。一个有效的读操做在一个由一系列SSTable和memtable合并的视图里执行。因为SSTable和memtable是按字典排序的数据结构，所以能够高效生成合并视图。
当进行Tablet的合并和分割时，正在进行的读写操做可以继续进行。
5.4Compactions
(alex注：这个词挺简单，可是在这节里面挺难翻译的。应该是空间缩减的意思，可是彷佛又不能彻底归纳它在上下文中的意思，干脆，不翻译了)
随着写操做的执行，memtable的大小不断增长。当memtable的尺寸到达一个门限值的时候，这个memtable就会被冻结，而后建立一个新的memtable；被冻结住memtable会被转换成SSTable，而后写入GFS（alex注：咱们称这种Compaction行为为Minor Compaction）。MinorCompaction过程有两个目的：shrink(alex注：shrink是数据库用语，表示空间收缩)Tablet服务器使用的内存，以及在服务器灾难恢复过程当中，减小必须从提交日志里读取的数据量。在Compaction过程当中，正在进行的读写操做仍能继续。
每一次Minor Compaction都会建立一个新的SSTable。若是Minor Compaction过程不停滞的持续进行下去，读操做可能须要合并来自多个SSTable的更新；不然，咱们经过按期在后台执行Merging Compaction过程合并文件，限制这类文件的数量。Merging Compaction过程读取一些SSTable和memtable的内容，合并成一个新的SSTable。只要Merging Compaction过程完成了，输入的这些SSTable和memtable就能够删除了。
合并全部的SSTable并生成一个新的SSTable的Merging Compaction过程叫做Major Compaction。由非Major Compaction产生的SSTable可能含有特殊的删除条目，这些删除条目可以隐藏在旧的、可是依然有效的SSTable中已经删除的数据（alex注：使人费解啊，原文是SSTables produced by non-major compactions can contain specialdeletion entries that suppress deleted data in older SSTables that are stilllive）。而MajorCompaction过程生成的SSTable不包含已经删除的信息或数据。Bigtable循环扫描它全部的Tablet，而且按期对它们执行Major Compaction。Major Compaction机制容许Bigtable回收已经删除的数据占有的资源，而且确保BigTable能及时清除已经删除的数据（alex注：实际是回收资源。数据删除后，它占有的空间并不能立刻重复利用；只有空间回收后才能重复使用），这对存放敏感数据的服务是很是重要。
6 优化
上一章咱们描述了Bigtable的实现，咱们还须要不少优化工做才能使Bigtable到达用户要求的高性能、高可用性和高可靠性。本章描述了Bigtable实现的其它部分，为了更好的强调这些优化工做，咱们将深刻细节。
局部性群组
客户程序能够将多个列族组合成一个局部性群族。对Tablet中的每一个局部性群组都会生成一个单独的SSTable。将一般不会一块儿访问的列族分割成不一样的局部性群组能够提升读取操做的效率。例如，在Webtable表中，网页的元数据（好比语言和Checksum）能够在一个局部性群组中，网页的内容能够在另一个群组：当一个应用程序要读取网页的元数据的时候，它没有必要去读取全部的页面内容。
此外，能够以局部性群组为单位设定一些有用的调试参数。好比，能够把一个局部性群组设定为所有存储在内存中。Tablet服务器依照惰性加载的策略将设定为放入内存的局部性群组的SSTable装载进内存。加载完成以后，访问属于该局部性群组的列族的时候就没必要读取硬盘了。这个特性对于须要频繁访问的小块数据特别有用：在Bigtable内部，咱们利用这个特性提升METADATA表中具备位置相关性的列族的访问速度。
压缩
客户程序能够控制一个局部性群组的SSTable是否须要压缩；若是须要压缩，那么以什么格式来压缩。每一个SSTable的块（块的大小由局部性群组的优化参数指定）都使用用户指定的压缩格式来压缩。虽然分块压缩浪费了少许空间（alex注：相比于对整个SSTable进行压缩，分块压缩压缩率较低），可是，咱们在只读取SSTable的一小部分数据的时候就没必要解压整个文件了。不少客户程序使用了“两遍”的、可定制的压缩方式。第一遍采用Bentleyand McIlroy’s方式[6]，这种方式在一个很大的扫描窗口里对常见的长字符串进行压缩；第二遍是采用快速压缩算法，即在一个16KB的小扫描窗口中寻找重复数据。两个压缩的算法都很快，在如今的机器上，压缩的速率达到100-200MB/s，解压的速率达到400-1000MB/s。
虽然咱们在选择压缩算法的时候重点考虑的是速度而不是压缩的空间，可是这种两遍的压缩方式在空间压缩率上的表现也是使人惊叹。好比，在Webtable的例子里，咱们使用这种压缩方式来存储网页内容。在一次测试中，咱们在一个压缩的局部性群组中存储了大量的网页。针对实验的目的，咱们没有存储每一个文档全部版本的数据，咱们仅仅存储了一个版本的数据。该模式的空间压缩比达到了10:1。这比传统的Gzip在压缩HTML页面时3:1或者4:1的空间压缩比好的多；“两遍”的压缩模式如此高效的缘由是因为Webtable的行的存放方式：从同一个主机获取的页面都存在临近的地方。利用这个特性，Bentley-McIlroy算法能够历来自同一个主机的页面里找到大量的重复内容。不只仅是Webtable，其它的不少应用程序也经过选择合适的行名来将类似的数据聚簇在一块儿，以获取较高的压缩率。当咱们在Bigtable中存储同一份数据的多个版本的时候，压缩效率会更高。
经过缓存提升读操做的性能
为了提升读操做的性能，Tablet服务器使用二级缓存的策略。扫描缓存是第一级缓存，主要缓存Tablet服务器经过SSTable接口获取的Key-Value对；Block缓存是二级缓存，缓存的是从GFS读取的SSTable的Block。对于常常要重复读取相同数据的应用程序来讲，扫描缓存很是有效；对于常常要读取刚刚读过的数据附近的数据的应用程序来讲，Block缓存更有用（例如，顺序读，或者在一个热点的行的局部性群组中随机读取不一样的列)。
Bloom过滤器
(alex注：Bloom，又叫布隆过滤器，什么意思？请参考Google黑板报http://googlechinablog.com/2007/07/bloom-filter.html请务必先认真阅读)
如5.3节所述，一个读操做必须读取构成Tablet状态的全部SSTable的数据。若是这些SSTable不在内存中，那么就须要屡次访问硬盘。咱们经过容许客户程序对特定局部性群组的SSTable指定Bloom过滤器【7】，来减小硬盘访问的次数。咱们能够使用Bloom过滤器查询一个SSTable是否包含了特定行和列的数据。对于某些特定应用程序，咱们只付出了少许的、用于存储Bloom过滤器的内存的代价，就换来了读操做显著减小的磁盘访问的次数。使用Bloom过滤器也隐式的达到了当应用程序访问不存在的行或列时，大多数时候咱们都不须要访问硬盘的目的。
Commit日志的实现
若是咱们把对每一个Tablet的操做的Commit日志都存在一个单独的文件的话，那么就会产生大量的文件，而且这些文件会并行的写入GFS。根据GFS服务器底层文件系统实现的方案，要把这些文件写入不一样的磁盘日志文件时(alex注：differentphysicallog files)，会有大量的磁盘Seek操做。另外，因为批量提交(alex注：groupcommit)中操做的数目通常比较少，所以，对每一个Tablet设置单独的日志文件也会给批量提交本应具备的优化效果带来很大的负面影响。为了不这些问题，咱们设置每一个Tablet服务器一个Commit日志文件，把修改操做的日志以追加方式写入同一个日志文件，所以一个实际的日志文件中混合了对多个Tablet修改的日志记录。
使用单个日志显著提升了普通操做的性能，可是将恢复的工做复杂化了。当一个Tablet服务器宕机时，它加载的Tablet将会被移到不少其它的Tablet服务器上：每一个Tablet服务器都装载不多的几个原来的服务器的Tablet。当恢复一个Tablet的状态的时候，新的Tablet服务器要从原来的Tablet服务器写的日志中提取修改操做的信息，并从新执行。然而，这些Tablet修改操做的日志记录都混合在同一个日志文件中的。一种方法新的Tablet服务器读取完整的Commit日志文件，而后只重复执行它须要恢复的Tablet的相关修改操做。使用这种方法，假若有100台Tablet服务器，每台都加载了失效的Tablet服务器上的一个Tablet，那么，这个日志文件就要被读取100次（每一个服务器读取一次）。
为了不屡次读取日志文件，咱们首先把日志按照关键字（table，row name，log sequence number）排序。排序以后，对同一个Tablet的修改操做的日志记录就连续存放在了一块儿，所以，咱们只要一次磁盘Seek操做、以后顺序读取就能够了。为了并行排序，咱们先将日志分割成64MB的段，以后在不一样的Tablet服务器对段进行并行排序。这个排序工做由Master服务器来协同处理，而且在一个Tablet服务器代表本身须要从Commit日志文件恢复Tablet时开始执行。
在向GFS中写Commit日志的时候可能会引发系统颠簸，缘由是多种多样的（好比，写操做正在进行的时候，一个GFS服务器宕机了；或者链接三个GFS副本所在的服务器的网络拥塞或者过载了）。为了确保在GFS负载高峰时修改操做还能顺利进行，每一个Tablet服务器实际上有两个日志写入线程，每一个线程都写本身的日志文件，而且在任什么时候刻，只有一个线程是工做的。若是一个线程的在写入的时候效率很低，Tablet服务器就切换到另一个线程，修改操做的日志记录就写入到这个线程对应的日志文件中。每一个日志记录都有一个序列号，所以，在恢复的时候，Tablet服务器可以检测出并忽略掉那些因为线程切换而致使的重复的记录。
Tablet恢复提速
当Master服务器将一个Tablet从一个Tablet服务器移到另一个Tablet服务器时，源Tablet服务器会对这个Tablet作一次Minor Compaction。这个Compaction操做减小了Tablet服务器的日志文件中没有归并的记录，从而减小了恢复的时间。Compaction完成以后，该服务器就中止为该Tablet提供服务。在卸载Tablet以前，源Tablet服务器还会再作一次（一般会很快）Minor Compaction，以消除前面在一次压缩过程当中又产生的未归并的记录。第二次Minor Compaction完成之后，Tablet就能够被装载到新的Tablet服务器上了，而且不须要从日志中进行恢复。
利用不变性
咱们在使用Bigtable时，除了SSTable缓存以外的其它部分产生的SSTable都是不变的，咱们能够利用这一点对系统进行简化。例如，当从SSTable读取数据的时候，咱们没必要对文件系统访问操做进行同步。这样一来，就能够很是高效的实现对行的并行操做。memtable是惟一一个能被读和写操做同时访问的可变数据结构。为了减小在读操做时的竞争，咱们对内存表采用COW(Copy-on-write)机制，这样就容许读写操做并行执行。
由于SSTable是不变的，所以，咱们能够把永久删除被标记为“删除”的数据的问题，转换成对废弃的SSTable进行垃圾收集的问题了。每一个Tablet的SSTable都在METADATA表中注册了。Master服务器采用“标记-删除”的垃圾回收方式删除SSTable集合中废弃的SSTable【25】，METADATA表则保存了Root SSTable的集合。
最后，SSTable的不变性使得分割Tablet的操做很是快捷。咱们没必要为每一个分割出来的Tablet创建新的SSTable集合，而是共享原来的Tablet的SSTable集合。
7 性能评估
为了测试Bigtable的性能和可扩展性，咱们创建了一个包括N台Tablet服务器的Bigtable集群，这里N是可变的。每台Tablet服务器配置了1GB的内存，数据写入到一个包括1786台机器、每台机器有2个IDE硬盘的GFS集群上。咱们使用N台客户机生成工做负载测试Bigtable。（咱们使用和Tablet服务器相同数目的客户机以确保客户机不会成为瓶颈。）每台客户机配置2GZ双核Opteron处理器，配置了足以容纳全部进程工做数据集的物理内存，以及一张Gigabit的以太网卡。这些机器都连入一个两层的、树状的交换网络里，在根节点上的带宽加起来有大约100-200Gbps。全部的机器采用相同的设备，所以，任何两台机器间网络来回一次的时间都小于1ms。
Tablet服务器、Master服务器、测试机、以及GFS服务器都运行在同一组机器上。每台机器都运行一个GFS的服务器。其它的机器要么运行Tablet服务器、要么运行客户程序、要么运行在测试过程当中，使用这组机器的其它的任务启动的进程。
R是测试过程当中，Bigtable包含的不一样的列关键字的数量。咱们精心选择R的值，保证每次基准测试对每台Tablet服务器读/写的数据量都在1GB左右。
在序列写的基准测试中，咱们使用的列关键字的范围是0到R-1。这个范围又被划分为10N个大小相同的区间。核心调度程序把这些区间分配给N个客户端，分配方式是：只要客户程序处理完上一个区间的数据，调度程序就把后续的、还没有处理的区间分配给它。这种动态分配的方式有助于减小客户机上同时运行的其它进程对性能的影响。咱们在每一个列关键字下写入一个单独的字符串。每一个字符串都是随机生成的、所以也没有被压缩（alex注：参考第6节的压缩小节）。另外，不一样列关键字下的字符串也是不一样的，所以也就不存在跨行的压缩。随机写入基准测试采用相似的方法，除了行关键字在写入前先作Hash，Hash采用按R取模的方式，这样就保证了在整个基准测试持续的时间内，写入的工做负载均匀的分布在列存储空间内。
序列读的基准测试生成列关键字的方式与序列写相同，不一样于序列写在列关键字下写入字符串的是，序列读是读取列关键字下的字符串（这些字符串由以前序列写基准测试程序写入）。一样的，随机读的基准测试和随机写是相似的。
扫描基准测试和序列读相似，可是使用的是BigTable提供的、从一个列范围内扫描全部的value值的API。因为一次RPC调用就从一个Tablet服务器取回了大量的Value值，所以，使用扫描方式的基准测试程序能够减小RPC调用的次数。
随机读（内存）基准测试和随机读相似，除了包含基准测试数据的局部性群组被设置为“in-memory”，所以，读操做直接从Tablet服务器的内存中读取数据，不须要从GFS读取数据。针对这个测试，咱们把每台Tablet服务器存储的数据从1GB减小到100MB，这样就能够把数据所有加载到Tablet服务器的内存中了。
图6中有两个视图，显示了咱们的基准测试的性能；图中的数据和曲线是读/写 1000-byte value值时取得的。图中的表格显示了每一个Tablet服务器每秒钟进行的操做的次数；图中的曲线显示了每秒种全部的Tablet服务器上操做次数的总和。
单个Tablet服务器的性能
咱们首先分析下单个Tablet服务器的性能。随机读的性能比其它操做慢一个数量级或以上（alex注：by the order of magnitude or more） 。 每一个随机读操做都要经过网络从GFS传输64KB的SSTable到Tablet服务器，而咱们只使用其中大小是1000 byte的一个value值。Tablet服务器每秒大约执行1200次读操做，也就是每秒大约从GFS读取75MB的数据。这个传输带宽足以占满Tablet服务器的CPU时间，由于其中包括了网络协议栈的消耗、SSTable解析、以及BigTable代码执行；这个带宽也足以占满咱们系统中网络的连接带宽。大多数采用这种访问模式BigTable应用程序会减少Block的大小，一般会减到8KB。
内存中的随机读操做速度快不少，缘由是，全部1000-byte的读操做都是从Tablet服务器的本地内存中读取数据，不须要从GFS读取64KB的Block。
随机和序列写操做的性能比随机读要好些，缘由是每一个Tablet服务器直接把写入操做的内容追加到一个Commit日志文件的尾部，而且采用批量提交的方式，经过把数据以流的方式写入到GFS来提升性能。随机写和序列写在性能上没有太大的差别，这两种方式的写操做实际上都是把操做内容记录到同一个Tablet服务器的Commit日志文件中。
序列读的性能好于随机读，由于每取出64KB的SSTable的Block后，这些数据会缓存到Block缓存中，后续的64次读操做直接从缓存读取数据。
扫描的性能更高，这是因为客户程序每一次RPC调用都会返回大量的value的数据，因此，RPC调用的消耗基本抵消了。
性能提高
随着咱们将系统中的Tablet服务器从1台增长到500台，系统的总体吞吐量有了梦幻般的增加，增加的倍率超过了100。好比，随着Tablet服务器的数量增长了500倍，内存中的随机读操做的性能增长了300倍。之因此会有这样的性能提高，主要是由于这个基准测试的瓶颈是单台Tablet服务器的CPU。
尽管如此，性能的提高还不是线性的。在大多数的基准测试中咱们看到，当Tablet服务器的数量从1台增长到50台时，每台服务器的吞吐量会有一个明显的降低。这是因为多台服务器间的负载不均衡形成的，大多数状况下是因为其它的程序抢占了CPU。咱们负载均衡的算法会尽可能避免这种不均衡，可是基于两个主要缘由，这个算法并不能完美的工做：一个是尽可能减小Tablet的移动致使从新负载均衡能力受限（若是Tablet被移动了，那么在短期内 — 通常是1秒内 — 这个Tablet是不可用的），另外一个是咱们的基准测试程序产生的负载会有波动（alex注：the load generated by our benchmarks shifts around as the benchmarkprogresses）。
随机读基准测试的测试结果显示，随机读的性能随Tablet服务器数量增长的提高幅度最小（总体吞吐量只提高了100倍，而服务器的数量却增长了500倍）。这是由于每一个1000-byte的读操做都会致使一个64KB大的Block在网络上传输。这样的网络传输量消耗了咱们网络中各类共享的1GB的链路，结果致使随着咱们增长服务器的数量，每台服务器上的吞吐量急剧降低。
8 实际应用
截止到2006年8月，Google内部一共有388个非测试用的Bigtable集群运行在各类各样的服务器集群上，合计大约有24500个Tablet服务器。表1显示了每一个集群上Tablet服务器的大体分布状况。这些集群中，许多用于开发目的，所以会有一段时期比较空闲。经过观察一个由14个集群、8069个Tablet服务器组成的集群组，咱们看到总体的吞吐量超过了每秒1200000次请求，发送到系统的RPC请求致使的网络负载达到了741MB/s，系统发出的RPC请求网络负载大约是16GB/s。
表2提供了一些目前正在使用的表的相关数据。一些表存储的是用户相关的数据，另一些存储的则是用于批处理的数据；这些表在总的大小、每一个数据项的平均大小、从内存中读取的数据的比例、表的Schema的复杂程度上都有很大的差异。本节的其他部分，咱们将主要描述三个产品研发团队如何使用Bigtable的。
8.1Google Analytics
Google Analytics是用来帮助Web站点的管理员分析他们网站的流量模式的服务。它提供了总体情况的统计数据，好比天天的独立访问的用户数量、天天每一个URL的浏览次数；它还提供了用户使用网站的行为报告，好比根据用户以前访问的某些页面，统计出几成的用户购买了商品。
为了使用这个服务，Web站点的管理员只须要在他们的Web页面中嵌入一小段JavaScript脚本就能够了。这个Javascript程序在页面被访问的时候调用。它记录了各类Google Analytics须要使用的信息，好比用户的标识、获取的网页的相关信息。Google Analytics汇总这些数据，以后提供给Web站点的管理员。
咱们粗略的描述一下Google Analytics使用的两个表。Row Click表（大约有200TB数据）的每一行存放了一个最终用户的会话。行的名字是一个包含Web站点名字以及用户会话建立时间的元组。这种模式保证了对同一个Web站点的访问会话是顺序的，会话按时间顺序存储。这个表能够压缩到原来尺寸的14%。
Summary表（大约有20TB的数据）包含了关于每一个Web站点的、各类类型的预约义汇总信息。一个周期性运行的MapReduce任务根据Raw Click表的数据生成Summary表的数据。每一个MapReduce工做进程都从Raw Click表中提取最新的会话数据。系统的总体吞吐量受限于GFS的吞吐量。这个表的可以压缩到原有尺寸的29%。
8.2Google Earth
Google经过一组服务为用户提供了高分辨率的地球表面卫星图像，访问的方式能够使经过基于Web的Google Maps访问接口（maps.google.com），也能够经过Google Earth定制的客户端软件访问。这些软件产品容许用户浏览地球表面的图像：用户能够在不一样的分辨率下平移、查看和注释这些卫星图像。这个系统使用一个表存储预处理数据，使用另一组表存储用户数据。
数据预处理流水线使用一个表存储原始图像。在预处理过程当中，图像被清除，图像数据合并到最终的服务数据中。这个表包含了大约70TB的数据，因此须要从磁盘读取数据。图像已经被高效压缩过了，所以存储在Bigtable后不须要再压缩了。
Imagery表的每一行都表明了一个单独的地理区域。行都有名称，以确保毗邻的区域存储在了一块儿。Imagery表中有一个列族用来记录每一个区域的数据源。这个列族包含了大量的列：基本上市每一个列对应一个原始图片的数据。因为每一个地理区域都是由不多的几张图片构成的，所以这个列族是很是稀疏的。
数据预处理流水线高度依赖运行在Bigtable上的MapReduce任务传输数据。在运行某些MapReduce任务的时候，整个系统中每台Tablet服务器的数据处理速度是1MB/s。
这个服务系统使用一个表来索引GFS中的数据。这个表相对较小（大约是500GB），可是这个表必须在保证较低的响应延时的前提下，针对每一个数据中心，每秒处理几万个查询请求。所以，这个表必须在上百个Tablet服务器上存储数据，而且使用in-memory的列族。
8.3 个性化查询
个性化查询（www.google.com/psearch）是一个双向服务；这个服务记录用户的查询和点击，涉及到各类Google的服务，好比Web查询、图像和新闻。用户能够浏览他们查询的历史，重复他们以前的查询和点击；用户也能够定制基于Google历史使用习惯模式的个性化查询结果。
个性化查询使用Bigtable存储每一个用户的数据。每一个用户都有一个惟一的用户id，每一个用户id和一个列名绑定。一个单独的列族被用来存储各类类型的行为（好比，有个列族多是用来存储全部的Web查询的）。每一个数据项都被用做Bigtable的时间戳，记录了相应的用户行为发生的时间。个性化查询使用以Bigtable为存储的MapReduce任务生成用户的数据图表。这些用户数据图表用来个性化当前的查询结果。
个性化查询的数据会复制到几个Bigtable的集群上，这样就加强了数据可用性，同时减小了由客户端和Bigtable集群间的“距离”形成的延时。个性化查询的开发团队最初创建了一个基于Bigtable的、“客户侧”的复制机制为全部的复制节点提供一致性保障。如今的系统则使用了内建的复制子系统。
个性化查询存储系统的设计容许其它的团队在它们本身的列中加入新的用户数据，所以，不少Google服务使用个性化查询存储系统保存用户级的配置参数和设置。在多个团队之间分享数据的结果是产生了大量的列族。为了更好的支持数据共享，咱们加入了一个简单的配额机制(alex注：quota，参考AIX的配额机制)限制用户在共享表中使用的空间；配额也为使用个性化查询系统存储用户级信息的产品团体提供了隔离机制。
9 经验教训
在设计、实现、维护和支持Bigtable的过程当中，咱们获得了不少有用的经验和一些有趣的教训。
一个教训是，咱们发现，不少类型的错误都会致使大型分布式系统受损，这些错误不只仅是一般的网络中断、或者不少分布式协议中设想的fail-stop类型的错误（alex注：fail-stop failture，指一旦系统fail就stop，不输出任何数据；fail-fastfailture，指fail不立刻stop，在短期内return错误信息，而后再stop）。好比，咱们遇到过下面这些类型的错误致使的问题：内存数据损坏、网络中断、时钟误差、机器挂起、扩展的和非对称的网络分区（alex注：extended and asymmetric network partitions，不明白什么意思。partition也有中断的意思，可是我不知道如何用在这里）、咱们使用的其它系统的Bug（好比Chubby）、GFS配额溢出、计划内和计划外的硬件维护。咱们在解决这些问题的过程当中学到了不少经验，咱们经过修改协议来解决这些问题。好比，咱们在咱们的RPC机制中加入了Checksum。咱们在设计系统的部分功能时，不对其它部分功能作任何的假设，这样的作法解决了其它的一些问题。好比，咱们再也不假设一个特定的Chubby操做只返回错误码集合中的一个值。
另一个教训是，咱们明白了在完全了解一个新特性会被如何使用以后，再决定是否添加这个新特性是很是重要的。好比，咱们开始计划在咱们的API中支持一般方式的事务处理。可是因为咱们还不会立刻用到这个功能，所以，咱们并无去实现它。如今，Bigtable上已经有了不少的实际应用，咱们能够检查它们真实的需求；咱们发现，大可能是应用程序都只是须要单个行上的事务功能。有些应用须要分布式的事务功能，分布式事务大多数状况下用于维护二级索引，所以咱们增长了一个特殊的机制去知足这个需求。新的机制在通用性上比分布式事务差不少，可是它更有效（特别是在更新操做的涉及上百行数据的时候），并且很是符合咱们的“跨数据中心”复制方案的优化策略。
还有一个具备实践意义的经验：咱们发现系统级的监控对Bigtable很是重要（好比，监控Bigtable自身以及使用Bigtable的客户程序）。好比，咱们扩展了咱们的RPC系统，所以对于一个RPC调用的例子，它能够详细记录表明了RPC调用的不少重要操做。这个特性容许咱们检测和修正不少的问题，好比Tablet数据结构上的锁的内容、在修改操做提交时对GFS的写入很是慢的问题、以及在METADATA表的Tablet不可用时，对METADATA表的访问挂起的问题。关于监控的用途的另一个例子是，每一个Bigtable集群都在Chubby中注册了。这能够帮助咱们跟踪全部的集群状态、监控它们的大小、检查集群运行的咱们软件的版本、监控集群流入数据的流量，以及检查是否有引起集群高延时的潜在因素。
对咱们来讲，最宝贵的经验是简单设计的价值。考虑到咱们系统的代码量（大约100000行生产代码（alex注：non-test code）），以及随着时间的推移，新的代码以各类难以预料的方式加入系统，咱们发现简洁的设计和编码给维护和调试带来的巨大好处。这方面的一个例子是咱们的Tablet服务器成员协议。咱们初版的协议很简单：Master服务器周期性的和Tablet服务器签定租约，Tablet服务器在租约过时的时候Kill掉本身的进程。不幸的是，这个协议在遇到网络问题时会大大下降系统的可用性，也会大大增长Master服务器恢复的时间。咱们屡次从新设计这个协议，直到它可以很好的处理上述问题。可是，更不幸的是，最终的协议过于复杂了，而且依赖一些Chubby不多被用到的特性。咱们发现咱们浪费了大量的时间在调试一些古怪的问题(alex注：obscure corner cases)，有些是Bigtable代码的问题，有些事Chubby代码的问题。最后，咱们只好废弃了这个协议，从新制订了一个新的、更简单、只使用Chubby最普遍使用的特性的协议。
10 相关工做
Boxwood【24】项目的有些组件在某些方面和Chubby、GFS以及Bigtable相似，由于它也提供了诸如分布式协议、锁、分布式Chunk存储以及分布式B-tree存储。Boxwood与Google的某些组件尽管功能相似，可是Boxwood的组件提供更底层的服务。Boxwood项目的目的是提供建立相似文件系统、数据库等高级服务的基础构件，而Bigtable的目的是直接为客户程序的数据存储需求提供支持。
如今有很多项目已经攻克了不少难题，实现了在广域网上的分布式数据存储或者高级服务，一般是“Internet规模”的。这其中包括了分布式的Hash表，这项工做由一些相似CAN【29】、Chord【32】、Tapestry【37】和Pastry【30】的项目率先发起。这些系统的主要关注点和Bigtable不一样，好比应对各类不一样的传输带宽、不可信的协做者、频繁的更改配置等；另外，去中心化和Byzantine灾难冗余(alex注：Byzantine，即拜占庭式的风格，也就是一种复杂诡秘的风格。Byzantine Fault表示：对于处理来讲，当发错误时处理器并不中止接收输出，也不中止输出，错就错了，只管算，对于这种错误来讲，这样可真是够麻烦了，由于用户根本不知道错误发生了，也就根本谈不上处理错误了。在多处理器的状况下，这种错误可能致使运算正确结果的处理器也产生错误的结果，这样事情就更麻烦了，因此必定要避免处理器产生这种错误。)也不是Bigtable的目的。
就提供给应用程序开发者的分布式数据存储模型而言，咱们相信，分布式B-Tree或者分布式Hash表提供的Key-value pair方式的模型有很大的局限性。Key-value pair模型是颇有用的组件，可是它们不该该是提供给开发者惟一的组件。咱们选择的模型提供的组件比简单的Key-value pair丰富的多，它支持稀疏的、半结构化的数据。另外，它也足够简单，可以高效的处理平面文件；它也是透明的（经过局部性群组），容许咱们的使用者对系统的重要行为进行调整。
有些数据库厂商已经开发出了并行的数据库系统，可以存储海量的数据。Oracle的RAC【27】使用共享磁盘存储数据（Bigtable使用GFS），而且有一个分布式的锁管理系统（Bigtable使用Chubby）。IBM并行版本的DB2【4】基于一种相似于Bigtable的、不共享任何东西的架构（a shared-nothing architecture）【33】。每一个DB2的服务器都负责处理存储在一个关系型数据库中的表中的行的一个子集。这些产品都提供了一个带有事务功能的完整的关系模型。
Bigtable的局部性群组提供了相似于基于列的存储方案在压缩和磁盘读取方面具备的性能；这些以列而不是行的方式组织数据的方案包括C-Store【1，34】、商业产品Sybase IQ【15，36】、SenSage【31】、KDB+【22】，以及MonetDB/X100【38】的ColumnDM存储层。另一种在平面文件中提供垂直和水平数据分区、而且提供很好的数据压缩率的系统是AT&T的Daytona数据库【19】。局部性群组不支持Ailamaki系统中描述的CPU缓存级别的优化【2】。
Bigtable采用memtable和SSTable存储对表的更新的方法与Log-StructuredMerge Tree【26】存储索引数据更新的方法相似。这两个系统中，排序的数据在写入到磁盘前都先存放在内存中，读取操做必须从内存和磁盘中合并数据产生最终的结果集。
C-Store和Bigtable有不少类似点：两个系统都采用Shared-nothing架构，都有两种不一样的数据结构，一种用于当前的写操做，另一种存放“长时间使用”的数据，而且提供一种机制在两个存储结构间搬运数据。两个系统在API接口函数上有很大的不一样：C-Store操做更像关系型数据库，而Bigtable提供了低层次的读写操做接口，而且设计的目标是可以支持每台服务器每秒数千次操做。C-Store同时也是个“读性能优化的关系型数据库”，而Bigtable对读和写密集型应用都提供了很好的性能。
Bigtable也必须解决全部的Shared-nothing数据库须要面对的、类型类似的一些负载和内存均衡方面的难题（好比，【11，35】）。咱们的问题在某种程度上简单一些：（1）咱们不须要考虑同一份数据可能有多个拷贝的问题，同一份数据可能因为视图或索引的缘由以不一样的形式表现出来；（2）咱们让用户决定哪些数据应该放在内存里、哪些放在磁盘上，而不是由系统动态的判断；（3）咱们的系统中没有复杂的查询执行或优化工做。
11 结论
咱们已经讲述完了Bigtable，Google的一个分布式的结构化数据存储系统。Bigtable的集群从2005年4月开始已经投入使用了，在此以前，咱们花了大约7人年设计和实现这个系统。截止到2006年4月，已经有超过60个项目使用Bigtable了。咱们的用户对Bigtable提供的高性能和高可用性很满意，随着时间的推移，他们能够根据本身的系统对资源的需求增长状况，经过简单的增长机器，扩展系统的承载能力。
因为Bigtable提供的编程接口并不常见，一个有趣的问题是：咱们的用户适应新的接口有多难？新的使用者有时不太肯定使用Bigtable接口的最佳方法，特别是在他们已经习惯于使用支持通用事务的关系型数据库的接口的状况下。可是，Google内部不少产品都成功的使用了Bigtable的事实证实了，咱们的设计在实践中行之有效。
咱们如今正在对Bigtable加入一些新的特性，好比支持二级索引，以及支持多Master节点的、跨数据中心复制的Bigtable的基础构件。咱们如今已经开始将Bigtable部署为服务供其它的产品团队使用，这样不一样的产品团队就不须要维护他们本身的Bigtable集群了。随着服务集群的扩展，咱们须要在Bigtable系统内部处理更多的关于资源共享的问题了【3，5】。
最后，咱们发现，建设Google本身的存储解决方案带来了不少优点。经过为Bigtable设计咱们本身的数据模型，是咱们的系统极具灵活性。另外，因为咱们全面控制着Bigtable的实现过程，以及Bigtable使用到的其它的Google的基础构件，这就意味着咱们在系统出现瓶颈或效率低下的状况时，可以快速的解决这些问题。
Acknowledgements
We thank the anonymous reviewers, DavidNagle, and our shepherd Brad Calder, for their feedback on this paper.TheBigtable system has benefited greatly from the feedback of our many userswithin Google. In addition,we thank the following people for theircontributions to Bigtable: Dan Aguayo, Sameer Ajmani, Zhifeng Chen,BillCoughran, Mike Epstein, Healfdene Goguen, Robert Griesemer, Jeremy Hylton, JoshHyman, Alex Khesin,
Joanna Kulik, Alberto Lerner, SherryListgarten, Mike Maloney, Eduardo Pinheiro, Kathy Polizzi, Frank Yellin,andArthur Zwiegincew.
References
[1] ABADI, D. J., MADDEN, S. R., ANDFERREIRA, M. C. Integrating compression and execution in columnorienteddatabase systems. Proc. of SIGMOD (2006).
[2] AILAMAKI, A., DEWITT, D. J., HILL, M.D., AND SKOUNAKIS, M. Weaving relations for cache performance.In The VLDBJournal (2001), pp. 169-180.
[3] BANGA, G., DRUSCHEL, P., AND MOGUL, J.C. Resource containers: A new facility for resource management in serversystems. In Proc. of the 3rd OSDI (Feb. 1999), pp. 45-58.
[4] BARU, C. K., FECTEAU, G., GOYAL, A.,HSIAO, H., JHINGRAN, A., PADMANABHAN, S., COPELAND,G. P., AND WILSON, W. G. DB2parallel edition. IBM Systems Journal 34, 2 (1995), 292-322.
[5] BAVIER, A., BOWMAN, M., CHUN, B.,CULLER, D., KARLIN, S., PETERSON, L., ROSCOE, T., SPALINK, T., AND WAWRZONIAK,M. Operating system support for planetary-scale network services. In Proc. ofthe 1st NSDI(Mar. 2004), pp. 253-266.
[6] BENTLEY, J. L., AND MCILROY, M. D. Datacompression using long common strings. In Data Compression Conference (1999),pp. 287-295.
[7] BLOOM, B. H. Space/time trade-offs inhash coding with allowable errors. CACM 13, 7 (1970), 422-426.
[8] BURROWS, M. The Chubby lock service forlooselycoupled distributed systems. In Proc. of the 7th OSDI (Nov. 2006).
[9] CHANDRA, T., GRIESEMER, R., ANDREDSTONE, J.Paxos made live ? An engineering perspective. In Proc. of PODC(2007).
[10] COMER, D. Ubiquitous B-tree. ComputingSurveys 11, 2 (June 1979), 121-137.
[11] COPELAND, G. P., ALEXANDER, W.,BOUGHTER, E. E., AND KELLER, T. W. Data placement in Bubba. In Proc. of SIGMOD(1988), pp. 99-108.
[12] DEAN, J., AND GHEMAWAT, S. MapReduce:Simplified data processing on large clusters. In Proc. of the 6th OSDI (Dec.2004), pp. 137-150.
[13] DEWITT, D., KATZ, R., OLKEN, F.,SHAPIRO, L., STONEBRAKER, M., AND WOOD, D. Implementation techniques for mainmemory database systems. In Proc. of SIGMOD (June 1984), pp. 1-8.
[14] DEWITT, D. J., AND GRAY, J. Paralleldatabase systems: The future of high performance database systems. CACM 35, 6(June 1992), 85-98.
[15] FRENCH, C. D. One size ts all databasearchitectures do not work for DSS. In Proc. of SIGMOD (May 1995), pp. 449-450.
[16] GAWLICK, D., AND KINKADE, D. Varietiesof concurrency control in IMS/VS fast path. Database Engineering Bulletin 8, 2(1985), 3-10.
[17] GHEMAWAT, S., GOBIOFF, H., AND LEUNG,S.-T. The Google file system. In Proc. of the 19th ACM SOSP (Dec.2003), pp.29-43.
[18] GRAY, J. Notes on database operatingsystems. In Operating Systems ? An Advanced Course, vol. 60 of Lecture Notes inComputer Science. Springer-Verlag, 1978.
[19] GREER, R. Daytona and thefourth-generation language Cymbal. In Proc. of SIGMOD (1999), pp. 525-526.
[20] HAGMANN, R. Reimplementing the Cedarfile system using logging and group commit. In Proc. of the 11th SOSP (Dec.1987), pp. 155-162.
[21] HARTMAN, J. H., AND OUSTERHOUT, J. K.The Zebra striped network file system. In Proc. of the 14th SOSP(Asheville, NC,1993), pp. 29-43.
[22] KX.COM. kx.com/products/database.PHP.Product page.
[23] LAMPORT, L. The part-time parliament.ACM TOCS 16,2 (1998), 133-169.
[24] MACCORMICK, J., MURPHY, N., NAJORK,M., THEKKATH, C. A., AND ZHOU, L. Boxwood: Abstractions as the foundation forstorage infrastructure. In Proc. of the 6th OSDI (Dec. 2004), pp. 105-120.
[25] MCCARTHY, J. Recursive functions ofsymbolic expressions and their computation by machine. CACM 3, 4 (Apr. 1960),184-195.
[26] O’NEIL, P., CHENG, E., GAWLICK, D.,AND O’NEIL, E. The log-structured merge-tree (LSM-tree). Acta Inf. 33, 4(1996), 351-385.
[27] ORACLE.COM. www.oracle.com/technology/products/database/clustering/index.html.Product page.
[28] PIKE, R., DORWARD, S., GRIESEMER, R.,AND QUINLAN, S. Interpreting the data: Parallel analysis with Sawzall.Scientific Programming Journal 13, 4 (2005), 227-298.
[29] RATNASAMY, S., FRANCIS, P., HANDLEY,M., KARP, R., AND SHENKER, S. A scalable content-addressable network. In Proc.of SIGCOMM (Aug. 2001), pp. 161-172.
[30] ROWSTRON, A., AND DRUSCHEL, P. Pastry:Scalable, distributed object location and routing for largescale peer-to-peersystems. In Proc. of Middleware 2001(Nov. 2001), pp. 329-350.
[31] SENSAGE.COM.sensage.com/products-sensage.htm. Product page.
[32] STOICA, I., MORRIS, R., KARGER, D.,KAASHOEK, M. F., AND BALAKRISHNAN, H. Chord: A scalable peer-to-peer lookupservice for Internet applications. In Proc. of SIGCOMM (Aug. 2001), pp.149-160.
[33] STONEBRAKER, M. The case for sharednothing. Database Engineering Bulletin 9, 1 (Mar. 1986), 4-9.
[34] STONEBRAKER,M., ABADI, D. J., BATKIN,A., CHEN, X., CHERNIACK, M., FERREIRA, M., LAU, E., LIN, A., MADDEN, S., O’NEIL,E., O’NEIL, P., RASIN, A., TRAN, N., AND ZDONIK, S. C-Store: A columnorientedDBMS. In Proc. of VLDB (Aug. 2005), pp. 553-564.
[35] STONEBRAKER, M., AOKI, P. M., DEVINE,R., LITWIN, W., AND OLSON, M. A. Mariposa: A new architecture for distributeddata. In Proc. of the Tenth ICDE(1994), IEEE Computer Society, pp. 54-65.
[36] SYBASE.COM. www.sybase.com/products/databaseservers/sybaseiq.Product page.
[37] ZHAO, B. Y., KUBIATOWICZ, J., ANDJOSEPH, A. D. Tapestry: An infrastructure for fault-tolerant wide-area locationand routing. Tech. Rep. UCB/CSD-01-1141, CS Division, UC Berkeley, Apr. 2001.
[38] ZUKOWSKI, M., BONCZ, P. A., NES, N.,AND HEMAN, S. MonetDB/X100 ?A DBMS in the CPU cache. IEEE Data Eng. Bull. 28, 2(2005), 17-22.