BigTable

分布式数据存储系统

Bigtable分布式数据存储系统是Google为其内部海量的结构化数据开发的云存储技术，是Google的第三项云计算关键技术，是所有云时代分布式存储系统的开发蓝本，已经在超过60个Google的产品和项目上得到了应用。

历史及现状

为解决海量数据存储的问题，Google的软件开发工程师研发了Bigtable，并于2005年4月投入使用。Google在2006年的OSDI大会上发表了关于Bigtable分布式数据库的论文。

Bigtable为Google60多种产品和项目提供存储和获取结构化数据的支撑平台，其中包括有Google Print、Orkut、Google Maps和Blogger等，而且在Google内部至少运行着500个Bigtable集群。

数据模型

Bigtable是一个稀疏、分布式、持久化存储的多维有序映射表，表的索引是行关键字、列关键字和时间戳。Bigtable中存储的表项都是未经解析的字节数组，其数据模型如下：

选定该数据模型，是在仔细分析了Bigtable系统的种种用途之后决定的。比如一个存储了大量网页及其相关信息的表Webtable，Webtable使用URL作为行关键字，使用网页的某些属性作为列名，网页的内容存入contents列中，并使用获取该网页的时间戳标识同一个网页的不同版本。在Bigtable中，Webtable的存储范例如图《Webtable范例片段》所示。

行关键字

行关键字可以是任意字符串，最大支持64KB。Bigtable按照行关键字的字典序组织数据，利用这个特性可以通过选择合适的行关键字，使数据访问具有良好的局部性。如Webtable中，通过将反转的URL作为行关键字，可以将同一个域名下的网页聚集在一起。表的行区间可以动态划分，每个行区间称为一个子表。子表是Bigtable数据分布和负载均衡的基本单位，不同的子表可以有不同的大小。为了限制子表的移动和恢复成本，每个子表默认的最大尺寸为200MB。

列族

列关键字一般都表示一种数据类型，列关键字的集合称作列族，列族是访问控制的基本单位。存储在同一列族下的数据属于同一种类型，列族下的数据被压缩在一起保存。数据在被存储之前必须先创建列族，并且表中的列族不宜过多，通常几百个，但表中可以有无限多个列。在Bigtable中列关键字的命名语法为：“列族：限定词”，列族名称必须是可打印的字符串，限定词则可以是任意字符串。如Webtable中名为anchor的列族，该列族的每一个列关键字代表一个锚链接；anchor列族的限定词是引用网页的站点名，每列的数据项是链接文本。

时间戳

Bigtable中的表项可以包含同一数据的不同版本，采用时间戳进行索引。时间戳是64位整型，既可以由系统赋值也可由用户指定。表项的不同版本按照时间戳倒序排列，即最新的数据排在最前面。为了简化多版本数据的管理，每个列族都有两个设置参数用于版本的自动回收，用户可以指定保存最近N个版本，或保留足够新的版本(如最近7天的内容)。在Webtable的例子中，contents列族存储的时间戳是网络爬虫抓取页面的时间，表中的回收机制是保留任一页面的最近三个版本。

举例

下面用JSON的数据格式展示了Bigtable的数据模型。

如图《Bigtable数据模型》所示，表的名称是“tableName”，行的名称是“rowA”。“rowA”有两个列族分别为“ColumnFamilyA”和“ColumnFamilyB”。每个列族又可以同时拥有多个列，每列都有自己唯一的列标示符。例如，在列族“ColumnFamilyA”中有两列，分别为“IdentifierA”和“IdentifierB”。

值得注意的是Bigtable允许空值作为列的标示符。例如，在列族“ColumnFamilyB”中有一个空值的列标示符。

Bigtable可以同时存储多个版本的数据，每个版本的数据都有自己唯一的时间戳，而且不同版本的数据是按照时间戳递减的顺序排列的。

架构

Bigtable系统实现了数据的分布式管理和结构的组织。Bigtable包含了3个主要的组件：链接到每个客户的库，一个Master服务器和多个Tablet服务器。根据负载情况的变化，Bigtable可以动态的向集群中添加或者删除Tablet服务器。

Master的主要任务是向Tablet服务器分配Tablet，检测是否有新加入或者失效的Tablet服务器，对Tablet-server进行负载均衡，以及对GFS上文件进行垃圾收集。除此之外，它还可以进行模式修改，例如表和列族的建立。

每个Tablet服务器都管理了一系列的Tablet。每个Tablet服务器处理它自身上面的Tablet的读写请求，并且当其上面的Tablets增长到一定程度对过大的Tablets进行分割。

和很多的单一Master分布式存储系统类似，客户端读取的数据不经过Master，客户直接和Tablet服务器通信进行读写操作。

Bigtable依赖一个高可用和持续分布式锁服务器Chubby进行管理。Chubby提供了一个名字空间，里面包含了目录和小文件。每个目录或者文件可以当成是一个锁，读写文件的操作都是原子的。每个Chubby的客户程序都维护一个与Chubby服务的会话。

Bigtable使用Google的分布式文件系统（GFS）存储日志文件和数据文件。Bigtable集群通常运行在一个共享的机器池里，Bigtable依赖集群管理系统调度任务、管理共享机器上的资源、处理机器的故障以及监视机器的状态。

与并行关系数据库的比较

下表从不同方面对Bigtable和传统并行分布式关系数据库进行比较。