- 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数据(用户数据),当子表节点故障时,选取新的节点回放日志即可快速建立内存数据 +