《大规模分布式存储系统》第六章 分布式表格系统

• Google BigTable

表格存储 与 键值存储

    表格存储的数据格式<rowkey，column family，timestamp>代表一行，所有的数据是主键（rowkey）排序的，可以抽象为主键为key，行尾value的键值存储，故称键值存储是表格存储的一个特例。

    需要注意的是，column family表示列组（很多列，需要预先定义），每列还可以有qualifler（子列，可以不用预先定义）。timestamp表述数据的版本，常规有两种机制，一种是保存固定的个数，另一种是保存制定时间内的所有版本。

架构

    BigTable系统分为上下两层，下层是GFS存储日志和数据，上层是索引层，本章着重介绍上层系统。上层系统主要分为三部分：中心控制节点、数据节点、Chubby锁服务（元信息存储、配置、节点探测等，可以理解为ZK）。上层存储索引信息，是单副本，故障后从下层的日志数据恢复上层索引数据。

    中心节点负责维护子表的元信息、子表的合并与分裂、子表级别的负载均衡等管理控制。

    Chubby锁服务类比开源zk，主要有一下职责：

        1. 中心节点选主。

        2. 存储导引数据（Bigtable采用二级索引，最原始的数据存在Chubby）。

        3. 节点加入、离开。

        4. 存储schema以及权限信息。

    二级索引：用户数据存在用户表，用户表的元数据存在元数据表（位置，文件编号、日志回放点），根表存储元数据表的元数据（主要是位置信息），根表称作导引信息存在Chubby内。

数据分布

    顺序存储，表格系统常用的分布方式，方便扫描。客户端读数据的大致流程：先从Chubby获取根表信息，接着获取元数据表信息，最后定位到子表（居然不是查中心节点）。客户端有两个策略需要注意，第一是缓存表信息，第二是预读子表的元数据。

复制与一致性

    首先，子表节点（Table Server）是单副本，通过Chubby互斥锁保证单副本全局唯一，防止子表节点加回时引入的不一致问题。其次，GFS中存储的是操作日志 和 SSTable数据（用户数据），当子表节点故障时，选取新的节点回放日志即可快速建立内存数据 + SSTable数据 = 全量的用户数据。最后，本质上BigTable实在GFS上搭建的一层索引，用户可以根据key查找索引再去获取数据，对比GFS返回偏移量（非连续）更好用一些。