存储相关概要–BigTable设计原理

引言

BigTable是google研发一个管理结构化数据的分布式存储系统,构建在GFS、Chubby等技术之上。其中:

  • GFS:是谷歌的分布式文件系统,开源分布式文件系统HDFS思想与之相似;
  • Chubby:是谷歌基于paxos算法实现的分布式锁服务,此外,它还提供一致性的分布式数据读写功能;

1 数据模型

1.1 存储方式

BigTable按key(row:string, column:string, time:int64) -> value(string)方式排序,方便快速索引。更细节地说,先按行名升序、如果行名相同再按列名升序、最后按时间戳为版本号降序排列。最后在文件系统中GFS中按lsm方式存储。

1.2 数据拆分

为了实现集群,BigTable以行名范围对数据拆分片存储,每个分片叫tablet。每个tablet是相同行键前缀的数据集合。假设用户的数据行健以用户id开头、用户id为9位,那么以行健前9位划分tablet,就可以让相同用户的数据内聚到一个tablet中。

1.3 与SQL的对比

首先,BigTable是用于管理结构化数据。但它与传统的SQL又有一些差异:

  • 每个SQL表的列是固定的,且列存储的数据类型也是固定的;但是BigTable的列数目、各行的列都可以不相同,所以BigTable是具备稀疏特征的说法。
  • SQL表的行号是数字型的;BigTable的行是字符串类型,即行名称,且各行的行名在写入时动态指定。
  • 在底层存储结构上,很多传统SQL存储引擎(例如Innodb)采用B+树,而BigTable采用的LSM方式,从存储方式看,BigTable是以key(row:string, column:string, time:int64) -> value(string)方式的KV存储。

2 体系架构

2.1 整体架构

请添加图片描述
整个BigTable由三部分组成,即client(客户端lib库)、master系统、tablet服务;然后基于Chubby和GFS实现。其中:

  • master服务只负责给tablet分配tablet、管理tablet服务器的状态等集群状态相关的工作;
  • client库是内嵌在客户端的库,为应用提供API;
  • tablet服务是处理数据请求的服务集群节点。每个tablet服务器处理至少一个、或多个tablet分片,然后转发给GFS持久化。

2.2 元数据管理

从前面可以看出BigTable最终数据是存储在GFS中,那么它是如何找到每个tablet分片在哪个GFS文件中的呢?其实元数据也是按tablet方式分片、分级存储的。与ceph自包含(或者说自存储)文件元数据一个原理。在Chubby中只记录顶级元数据的tablet位置或文件名。然后通过级联二级元数据的tablet,最终可以定位到用户数据的tablet。具体如下:
请添加图片描述
因为每个tablet由若干个sst文件组成,所以location在实现细节方面可以是一个文件序列,也可以像leveldb一样指向一个manifest文件,然后由manifest文件存储相关的多个sst文件。

3 读写流程

  • 写入流程

每个tablet服务器维护一个或多个tablet分片,每个tablet服务器使用一个WAL日志文件,用来记录接收的所管理分片的数据写入;然后将数据插入到内存中;当内存中数据达到上限,就会写入到对应的tablet分片的新sst文件中。此外,tablet服务还会处理后台sst的合并。整个过程与leveldb类似。

  • 读取流程

读取流程与leveldb也是类似的过程。先读取tablet服务内存中是否有数据;若没有就会读取tablet分片的sst文件中是否有数据;最后都没有才会返回查找失败。

  • 0
    点赞
  • 4
    收藏
    觉得还不错? 一键收藏
  • 1
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值