作者：刘旭晖 Raymond 转载请注明出处
Email：colorant at 163.com
BLOG：http://blog.csdn.net/colorant/
更多论文阅读笔记 http://blog.csdn.net/colorant/article/details/8256145
关键字
Bigtable GFS分布式数据库
==目标问题 ==
高性能，高可靠性，可扩展的数据库，用于服务Google以搜索引擎，Earth为代表的产品的数据存储需求
==核心思想 ==
Bigtable的核心数据模型是一个稀疏的多维Map数据结构，以 (行-row,列-column,时间戳-timestamp)为索引，在每个被索引的单元中存储对Bigtable不透明的用户数据。
行：从逻辑上，Bigtable的数据是以行为单位存储的，以Row Key为index排序，一行可以存储的单元数不限，物理上，也是以row key为序存储的，因此基本上用户数据表的设计要充分利用这一点，尽量将相关的数据以相同或相近的Row Key来存储。
此外Bigtable数据也是以行的范围来划分数据段（tablet）的，每个tablet可以由不同的TabletServer来管理，这样不同区段的数据由不同的Server节点服务，可以保证数据的吞吐率（通过对Row Key的合理设计，来分散热点数据，平衡负载）
列：Bigtable的列是以Family为单位分组的，以Family:qualifier的格式呈现。分组的目的一方面是可以以Family为单位进行权限控制，更重要的是，可以将不同相关但是不同类型的数据在物理上分组存储，便于获得更好的压缩效果等。考虑到数据的稀疏性，以及不确定的Schema，具体列的数量是不限的，也无需事先声明。但是有哪些Family必须预先确定好
时间戳：timestamp是用来保存Cell的不同版本的数据，可以使用系统的时间戳，也可以是用户自己指定的用于识别版本号的任何系列数据，架构于Big Table之上的megastore就使用了timestamp来实现基于MVCC的ACID
==实现 ==
BigTable支持Row为单位的transaction，底层依赖于chubby来支持各种同步协同相关操作，如主节点的选取，metatable的accesscontrol等
底层使用GFS来储存Tablet的文件内容，由于文件内容的只读形式，任何更新操作都是通过创建新版本的Row来实现的，为了加快响应，减少IO操作，写数据时，首先将数据写入内存的Memtable结构中（按Rowkey排序的）当Memtable大小超过一定阀值后，将这个Memtable作为一个新的文件写出到文件系统中。为了防止故障时内存中的数据丢失，同时在磁盘上维护了一个commit Log，数据的操作记录先写入LOG，然后才会被插入到Memtable中。此外读数据时，由于同一行的不同列或不同版本的数据可能分布在不同的物理文件以及Memtable中，需要同时扫描这些位置提交合并的结果。为了减少相关操作的代价，BigTable会定期合并这些文件的内容写入到新的文件中（同时也能真正删除某些逻辑上已经被删除的数据）
BigTable支持文件的压缩，可以按Family指定不同的压缩方案。
BigTable支持In Memory的Familylocality group，相关的数据载入内存以后就不会被替换出去，用于加速特定热点数据的访问。
支持BloomFilter来快速判断特定数据的存在与否，用于加速数据检索。
==相关研究，项目等 ==
HBase基本上就是BigTable在Hadoop/HDFS上的开源实现，绝大多数思想都是一致的
megastore：架构在BigTable之上的跨地域数据存储方案