《大规模分布式存储系统》第六章分布式表格系统-优快云博客

本文链接：https://blog.youkuaiyun.com/weixin_41713182/article/details/79416810

本文深入探讨了分布式表格系统，以Google BigTable为例，详细介绍了其架构、数据分布、复制与一致性、容错机制、负载均衡以及分裂与合并。随后讨论了Google Megastore如何在BigTable基础上实现事务处理，以及其系统架构和并发控制。最后对比了Windows Azure Storage与BigTable的区别，强调了强一致性和元数据管理的差异。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

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返回偏移量（非连续）更好用一些。