Big Table中文翻译

题记：google 的成功除了一个个出色的创意外，还由于有 Jeff Dean 这样的软件架构天才。

官方的 Google Reader blog 中有对BigTable 的解释。这是Google 内部开发的一个用来处理大数据量的系统。这种系统适合处理半结构化的数据好比 RSS 数据源。 如下发言  是 Andrew Hitchcock  在 2005 年10月18号 基于： Google 的工程师 Jeff Dean 在华盛顿大学的一次谈话 (Creative Commons License).

 

 

首先，BigTable 从 2004 年初就开始研发了，到如今为止已经用了将近8个月。（2005年2月）目前大概有100个左右的服务使用BigTable，好比： Print,Search History,Maps和 Orkut。根据Google的一向作法，内部开发的BigTable是为跑在廉价的PC机上设计的。BigTable 让Google在提供新服务时的运行成本下降，最大限度地利用了计算能力。BigTable 是创建在 GFS ，Scheduler ，Lock Service 和 MapReduce 之上的。

每一个Table都是一个多维的稀疏图 sparse map。Table 由行和列组成，而且每一个存储单元 cell 都有一个时间戳。在不一样的时间对同一个存储单元cell有多份拷贝，这样就能够记录数据的变更状况。在他的例子中，行是URLs ，列能够定义一个名字，好比：contents。Contents 字段就能够存储文件的数据。或者列名是：”language”，能够存储一个“EN”的语言代码字符串。

为了管理巨大的Table，把Table根据行分割，这些分割后的数据统称为：Tablets。每一个Tablets大概有 100-200 MB，每一个机器存储100个左右的 Tablets。底层的架构是：GFS。因为GFS是一种分布式的文件系统，采用Tablets的机制后，能够得到很好的负载均衡。好比：能够把常常响应的表移动到其余空闲机器上，而后快速重建。

Tablets在系统中的存储方式是不可修改的 immutable 的SSTables，一台机器一个日志文件。当系统的内存满后，系统会压缩一些Tablets。因为Jeff在论述这点的时候说的很快，因此我没有时间把听到的都记录下来，所以下面是一个大概的说明：

压缩分为：主要和次要的两部分。次要的压缩仅仅包括几个Tablets，而主要的压缩时关于整个系统的压缩。主压缩有回收硬盘空间的功能。Tablets的位置其实是存储在几个特殊的BigTable的存储单元cell中。看起来这是一个三层的系统。

客户端有一个指向METAO的Tablets的指针。若是METAO的Tablets被频繁使用，那个这台机器就会放弃其余的tablets专门支持METAO这个Tablets。METAO tablets 保持着全部的META1的tablets的记录。这些tablets中包含着查找tablets的实际位置。（老实说翻译到这里，我也不太明白。）在这个系统中不存在大的瓶颈，由于被频繁调用的数据已经被提早得到并进行了缓存。

    如今咱们返回到对 列的说明：列是相似下面的形式： family:optional_qualifier。在他的例子中，行：www.search-analysis.com  也许有列：”contents:其中包含html页面的代码。 “ anchor:cnn.com/news” 中包含着 相对应的url，”anchor:www.search-analysis.com/” 包含着连接的文字部分。列中包含着类型信息。

    (翻译到这里我要插一句，之前我看过一个关于万能数据库的文章，当时很激动，就联系了做者，如今回想起来，或许google的 bigtable 才是更好的方案，切不说分布式的特性，就是这种建华的表结构就颇有用处。)

    注意这里说的是列信息，而不是列类型。列的信息是以下信息，通常是：属性/规则。 好比：保存n份数据的拷贝 或者 保存数据n天长等等。当 tablets 从新创建的时候，就运用上面的规则，剔出不符合条件的记录。因为设计上的缘由，列自己的建立是很容易的，可是跟列相关的功能确实很是复杂的，好比上文提到的 类型和规则信息等。为了优化读取速度，列的功能被分割而后以组的方式存储在所建索引的机器上。这些被分割后的组做用于 列 ,而后被分割成不一样的 SSTables。这种方式能够提升系统的性能，由于小的，频繁读取的列能够被单独存储，和那些大的不常常访问的列隔离开来。

在一台机器上的全部的 tablets 共享一个log，在一个包含1亿的tablets的集群中，这将会致使很是多的文件被打开和写操做。新的log块常常被建立，通常是64M大小，这个GFS的块大小相等。当一个机器down掉后，控制机器就会从新发布他的log块到其余机器上继续进行处理。这台机器重建tablets而后询问控制机器处理结构的存储位置，而后直接对重建后的数据进行处理。

这个系统中有不少冗余数据，所以在系统中大量使用了压缩技术。

    Dean 对压缩的部分说的很快，我没有彻底记下来，因此我仍是说个大概吧：压缩前先寻找类似的 行，列，和时间 数据。

    他们使用不一样版本的： BMDiff 和 Zippy 技术。

   BMDiff 提供给他们很是快的写速度： 100MB/s – 1000MB/s 。Zippy 是和 LZW 相似的。Zippy 并不像 LZW 或者 gzip 那样压缩比高，可是他处理速度很是快。

    Dean 还给了一个关于压缩 web 蜘蛛数据的例子。这个例子的蜘蛛 包含 2.1B 的页面，行按照如下的方式命名：“com.cnn.www/index.html:http”.在未压缩前的web page 页面大小是：45.1 TB ，压缩后的大小是：4.2 TB ， 只是原来的 9.2%。Links 数据压缩到原来的 13.9% , 连接文本数据压缩到原来的 12.7%。

Google 还有不少没有添加可是已经考虑的功能。

    1.  数据操做表达式，这样能够把脚本发送到客户端来提供修改数据的功能。
    2. 多行数据的事物支持。
    3.  提升大数据存储单元的效率。
    4. BigTable 做为服务运行。
    好像：每一个服务好比： maps 和 search history 历史搜索记录都有他们本身的集群运行 BigTable。
    他们还考虑运行一个全局的 BigTable 系统，但这须要比较公平的分割资源和计算时间。

原文地址：
http://blog.csdn.net/accesine960/archive/2006/02/09/595628.aspx

http://blog.outer-court.com/archive/2005-10-23-n61.html