本文是HBase的欧洲传道者LARS GEORAGE的HBase vs. BigTable Comparison（需要FQ）一文的节选翻译版。
论文中提到的特性
首先，向大家介绍在2006年OSDI大会上发表BigTable论文，也就是《Bigtable: A Distributed Storage System for Structured Data》里面所提到的一些特性：
|
特性 |
BigTable |
HBase |
注释 |
| 原子的读写和修改 | 支持，基于Row的 | 支持，基于Row的 | 由于BigTable本身不是关系型数据库，所以它没有事务功能，但是有一个非常相近的机制，就是对一个Row的原子操作。 |
| 按照字典顺序对Row排序 | 支持 | 支持 |
和传统的关系型数据库的不同的是，其只支持按照字典顺序（lexicographic order）对Row排序。 |
| 支持Block格式存储 | 支持 | 支持 | 每个存储文件，都由一些小的block组成，这样能快速从大的存储文件中读取数据，默认Block的大小为64K。 |
| Block压缩 | 支持, 基于 column family | 支持, 基于 column family | BigTable使用BMDiff和Zippy这两种压缩算法。 |
| Column Family的个数 | 最多100 | 少于100 | |
| Column Family名字的格式 | 可打印 | 可答应 | 这两个系统都使用Column Family的名字作为文件系统中目录名 |
| Column名字的格式 | 任意 | 任意 | 可以是任意字节数组。 |
| Key和Value的格式 | 任意 | 任意 | 和上面一样，可以是任意字节数组。 |
| 访问控制 | 支持 | 不支持 | BigTable在column family这个层次实现了访问控制。 |
| Cell版本 | 支持 | 支持 | 主要通过Timestamp的形式来实现对Cell版本的控制。 |
| 自定义Timestamp | 支持 | 支持 | 这两个系统都能让用户自己设定Value的Timestamp或者默认的“now”。 |
| 数据TTL（Time-To-Live） | 支持 | 支持 | 数据Cell除了Timestamp之外，用户还能设定TTL，用来在一段时间后，自动删去旧的数据。 |
| 批处理写 | 支持 | 支持 | 两个系统都支持批处理写。 |
| 基于Value的计数器 | 支持 | 支持 | 这两个系统都可使用特定的Column作为原子的计数器。 |
| Row过滤器 | 支持 | 支持 | 在扫描Row的时候，可以通过过滤器来处理Row。 |
| 脚本工具 | 支持 | 不支持 | BigTable有Sawzall这个工具来帮助用户快速处理BigTable中的数据。 |
| MapReduce | 支持 | 支持 | BigTable和HBase都提供完善的类库和工具来支持MapReduce。 |
| 存储系统 | GFS | HDFS, S3, S3N, EBS | BigTable主要运行于Google的GFS上, 而且HBase能支持多种存储系统，只要有相关的驱动或者代理。 |
| 文件格式 | SSTable | HFile | 都是Immutable的，也就是写好之后，很少更改的。 |
| Block Index | 文件尾部 | 文件尾部 | |
| 内存映射 | Yes | No | BigTable能将存储文件直接映射到内存中。 |
| 锁服务 | Chubby | ZooKeeper | 虽然两者功能类似，但在实现机制上稍有不同，原因是ZooKeeper主要通过协调任务来实现锁服务的。 |
| 单一Master | 是 | 不是 | HBase最近添加了对多Master的支持，而且通过ZooKeeper来对那个”standby”的节点进行监控和管理。 |
| Tablet的个数 | 10-1000 | 10-1000 | 无论是BigTable，还是HBase，其每个Tablet节点都支持1000个左右的Tablet。 |
| Tablet的大小 | 100-200MB | 256MB | 大小可以用户自己设定。 |
| Root Tablet的地址 | 1st META | -ROOT- | BigTable系统在METADATA Table的第一个Tablet中存放第一个Tablet，也就是Root Tablet，而HBase使用单一的一个Tablet来存放Root Tablet。 |
| Client Tablet Cache | 支持 | 支持 | Client端会cache住tablet的地址，也可以通过检测来更新本地的cache。 |
| Locality组 | 支持 | 不支持 | 可将多个Column Family存储在一起。 |
| Meta Prefetch | 支持 | 不支持 | Client端能一下子读取多个Meta Tablet的信息，这样能减少今后的查找。 |
| Cell Cache | 支持 | 不支持 | 缓存一些访问很频繁的key/value对。 |
| In-Memory Column Families | 支持 | 支持 | 能将小的Table装载至内存，以提高访问速度。 |
| Block Cache | 支持 | 支持 | |
| Historian | 支持 | 支持 | METADATA Table会记录和Tablet有关的事件。 |
| Bloom Filter | 支持 | 支持 | 用于让系统快速确定这个Region是否存有所需的值。 |
| Write Ahead Log | 支持 | 支持 | 每个Tablet节点会其所承载的所有的Tablet准备一个Write Ahead Log来转载修改信息。 |
| Secondary Log | 支持 | 不支持 | 其是Write Ahead Log的副本，当前面那一个Log出现性能问题时，可以使用这个备份。 |
| 避免写Write-Ahead Log | 不清楚 | 支持 | 当执行大规模输入的时候，可以通过避免写Write-Ahead Log来提升速度。 |
| 快速Tablet切分 | 支持 | 支持 |
表1. 论文中提到的特性
新特性
在2009的LADIS大会上，Google院士jeff dean有一个非常精彩的Talk，称为“Design Lessons and Advice from Building Large Scale Distributed Systems”，在这次Talk中他提到了很多BigTable的新特性：
|
特性 |
BigTable |
HBase |
注释 |
| Client隔离 | 支持 | 不支持 | BigTable内部能服务多个不同的客户，而且能在它们之间保持数据隔离。 |
| Coprocessors | 支持 | 不支持 | BigTable能够在Tablet节点上加载代码，这样假设代码依赖的Tablet移动或者被切割，那么代码也会随着那个Tablet而移动。 |
| 崩溃（Corruption）的安全性 | 支持 | 不支持 | BigTable使用CRC校验码来确认数据是不是已经被安全写入。 |
| 复制 | 支持 | 不支持 | HBase现在也在实现这个特性。 |
表2. 在LADIS 2009大会上的Talk中提到的特性