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

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

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值