Bigtable解读
基本
Bigtable 是在GFS上的结构化的系统。很多人也把它称之为分布式表格系统。Bigtable在GFS和Chubby的基础上首次实现了可用的LSM树。
bigtable的key由三部分组成，关键字，列关键字+时间戳
(row:string,column:string,time:int64)->string
它的key由三部分组成，行关键字+列关键字+时间戳。它的value是一个bute数组。
分别对应行主键，列名。value从业务角度理解可以是一个未解析的byte数组。
在谷歌给出的例子中
url就是行关键字，anchor和内容就是列关键字。
url 列名时间戳形成了多个键值对，比如途中就有6个k-v对
其中t是数据版本。
为什么要把各列的值拆成多个k-v对呢？而不是一整行数据放在一起呢。因为对于网页索引来说网页内容非常大，读取也比较慢。而对于anchor这样的小字段读取就非常的快。并且俩者的查询往往不是一个业务场景。常见的是先用anchor索引确定网页后在读取完整的页面内容。这样吧他们放在一起对于读取anchor的场景就非常不利了。所以虽然他们有相同的url但还是分开存储好。然后谷歌还提出了列族的概念，就是吧一些有共性的字段整合到一起，在存储访问等方面统一管理。
API：bigtable提供的功能包括
- 建表、删表DDL
- 对单行数据增删查功能，不支持修改
- 范围扫描功能（弱化的where）。
bigtable只支持单行的事务。因此bigtable只能用在宽松的场景。
结构
在最底层bigtable把数据按照字典序排列之后以range划分。bigtable把这样一个range的数据称为一个tablet
一个tablet对应一个GFS中的文件。有一个全局唯一的文件名。并且一个tablet相当于一个LSM树。
要注意GFS支持append不支持update。而LSM树的所有操作都是append操作。
对于Bigtable来说只需要一个tablet的文件名就可以直接从GFS中进行读写了。但是这里我们需要一个手段把我们要查询的key值和tablet文件名联系起来。
为了解决这个问题Bigtable设计了三层的类似B+树结构的结构来存储tablet的位置信息。
这里的三层结构是存储位置信息不要和存储具体kv的lsm树搞混。LSM树是一个tablet内部的概念。
- Chubby file，负责选择出Root tablet
- root tablet 包含一个特殊的METADATA表；记录METADATA例所有的TABLET位置信息
- METADATA，其中的每个tablet包含了一个usertablet的集合
- 多个usertablet存储数据的最终项。
经过计算能存储2048PB的数据
整个bigtable还需要client来提供服务。为了避免tablet服务器出现宕机的情况需要master服务器来检测各tablet服务器的状态。
查找流程为
- 通过client项chubby查找key
- 访问到chubby指向的tablet开始。逐层向下
- 找到自自己要找到tablet
- 在找到tablet的lsm树中进行查找
每次都进行这样的流程会有些慢，可以加上路径缓存。把路径上第一层的RootTablet，第二层的MetaDATA和第三层的Tablet位置都加入缓存。Bigtable把这个缓存存储在客户端称为客户端缓存。