Google三大核心技术之三：BigTable
官方的Google Reader blog中有对BigT able 的解释。这是Google 内部开发的一个用来处理大数据量的系统。这种系统适合处理半结构化的数据比如RSS 数据源。以下发言是Andrew Hitchcock在2005 年10月18号基于：Google 的工程师Jeff Dean 在华盛顿大学的一次谈话(Creative Commons License).
首先，BigT able 从2004 年初就开始研发了，到现在为止已经用了将近8个月。（2005年2月）目前大概有100个左右的服务使用BigT able，比如：Print,Search History,Maps和Orkut。根据Google的一贯做法，内部开发的BigT able是为跑在廉价的PC机上设计的。BigT able 让Google在提供新服务时的运行成本降低，最大限度地利用了计算能力。BigT able 是建立在GFS ，Scheduler ，Lock Service 和MapReduce 之上的。
每个T able都是一个多维的稀疏图sparse map。T able 由行和列组成，并且每个存储单元cell 都有一个时间戳。在不同的时间对同一个存储单元cell有多份拷贝，这样就可以记录数据的变动情况。在他的例子中，行是URLs ，列可以定义一个名字，比如：contents。Contents 字段就可以存储文件的数据。或者列名是：”language”，可以存储一个“EN”的语言代码字符串。
为了管理巨大的T able，把T able根据行分割，这些分割后的数据统称为：T ablets。每个T ablets大概有100-200 MB，每个机器存储100个左右的T ablets。底层的架构是：GFS。由于GFS是一种分布式的文件系统，采用T ablets 的机制后，可以获得很好的负载均衡。比如：可以把经常响应的表移动到其他空闲机器上，然后快速重建。
T ablets在系统中的存储方式是不可修改的immutable 的SST ables，一台机器一个日志文件。当系统的内存满后，系统会压缩一些T ablets。由于Jeff在论述这点的时候说的很快，所以我没有时间把听到的都记录下来，因此下面是一个大概的说明：
压缩分为：主要和次要的两部分。次要的压缩仅仅包括几个Tablets，而主要的压缩时关于整个系统的压缩。主压缩有回收硬盘空间的功能。Tablets的位置实际上是存储在几个特殊的BigTable的存储单元cell中。看起来这是一个三层的系统。
客户端有一个指向METAO的Tablets的指针。如果METAO的Tablets被频繁使用，那个这台机器就会放弃其他的tablets专门支持METAO这个Tablets。METAO tablets 保持着所有的META1的tablets的记录。这些tablets中包含着查找tablets的实际位置。（老实说翻译到这里，我也不太明白。）在这个系统中不存在大的瓶颈，因为被频繁调用的数据已经被提前获得并进行了缓存。
现在我们返回到对列的说明：列是类似下面的形式：family:optional_qualifier。在他的例子中，行：也许有列：”contents:其中包含html页面的代码。“ anchor:/news” 中包含着相对应的url，”anchor:/” 包含着链接的文字部分。列中包含着类型信息。
(翻译到这里我要插一句，以前我看过一个关于万能数据库的文章，当时很激动，就联系了作者，现在回想起来，或许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 的页面，行按照以下的方式命名：“n.www/index.html:http”.在未压缩前的web page 页面大小是：45.1 TB ，压缩后的大小是：4.2 TB ，只是原来的9.2%。Links 数据压缩到原来的13.9% , 链接文本数据压缩到原来的12.7%。
Google 还有很多没有添加但是已经考虑的功能。
1. 数据操作表达式，这样可以把脚本发送到客户端来提供修改数据的功能。
2. 多行数据的事物支持。
3. 提高大数据存储单元的效率。
4. BigT able 作为服务运行。
好像：每个服务比如：maps 和search history 历史搜索记录都有他们自己的集群运行BigT able。
他们还考虑运行一个全局的BigT able 系统，但这需要比较公平的分割资源和计算时间。
