5分钟了解BigTable

Posted 2023-04-12 奋羊羊

一、如何存-数据存储格式

1. 基本的存储形式

(row:string, column:string, time:int64)→string

Bigtable 是一个分布式, 多维, 映射表. 表中的数据通过一个行关键字（Row Key）、一个列关键字（Column Key）以及一个时间戳（Time Stamp）进行索引. 在Bigtable中一共有三级索引. 行关键字为第一级索引，列关键字为第二级索引，时间戳为第三级索引。

以上是关于bigtable的一个比较专业的定义，但专业的定义有时候在理解越来可能会有一定的困难。下面是我对bigtable数据的理解。

其基本的存储格式就是一个多维的表，而行的key值是唯一的。列 是按不同的业务，会分为不同的列族，也是对某一些数据进行再抽象，类似于一个 编程中一个对象，而对象的属性可能在不同的对象在实现的时候会有所不同。时间呢，就像另一个维度，会将同保存同一个对象在不同时期的数据。

2.tablet 是什么

所有的数据表（table:此时是bigtable中的一个概念）是按基本结构存储的，但在存储过程中，随着数据量的增大，此时，如果将所有数据存储在一起，显然对设备的要求是非常高的，此时，就需要对数据进行分开存储，在Bigtable中，数据分割是按行进行分割的。而行是按一定的规则（如字典序）进行排序的。并且行关键字（如“www.baidu.com”）是一个倒排索引("com.baidu.www")，方便对相同类型的数据（如域名）进行排序（如www.baidu.com,baidu.com,news.baidu.com,wenku.baidu.com,如果按字母顺序正常的排序，其是无法排在一起的，但如果是倒着排，则com.baidu开头的数据，肯定是能够排在一起的，）。将排序后的表（table）分割后形成的小的数据表称为tablet，tablet在增长后，还可以再分，但分割后，依然还是tablet,没有再叫别的名称。.

请注意：此处提到了一个表是bigtable中的一个概念，而不是说明。同时，也专门强调了一下行的排序，是有用的。

3.metadata中有什么

把一个表分割为多个小表（tablet）之后，就需要对各个小表（tablet）进行管理，需要记录如那些数据放在了那个表中，这些表放在那些位置等这些与表相关的信息，即元数据（metadata），存储元数据的表称为元数据表，元数据表也是一个Bigtable结构的表，其中的row:key是由tablet的table名与table中row key的上限编码成的，也就是由一个元数据中的行，能唯一确定一个tablet.而其列数据，则是由 tablet的位置及一些操作日志等构成的。当元数据增长到一定程度后，需要对元数据再进行分割，此时，对这些分割，就需要对分割的元数据表进行管理，该表称为root table，root table中存储着分割后的元数据表的相关信息，在Bigtable中，此表不再分割，是最上层的表结构。这个表就存放在Chubby file 中。

如下图所示： 

 二、服务架构

这三级的表结构是如何其数据的表现形式，在其应用方面，需要怎么管理呢？

1. tablet的管理

一个table中的数据，在分为多个tablet后，需要存储在不同的服务器上，此时就需要一个专门的服务器对这些而存储数据的服务器进行管理，就是由谁来分配那些数据由那个服务器进行存储，如果新增加服务器，该如何分配数据的问题，于是，其确定 由一个主服务器 管理 多个从服务器的主从式架构。

在这个过程中，需要确定两个问题：

1. 主服务器是如何产生的？
2. 主服务器是如何管理从服务器的？

而解决这两个问题的关键是一个叫chubby的。首先，所有的服务在加入时，都需要经过chubby服务的注册。才能加入到Bigtable的服务集群中，因此，chubby拥有所有的服务器的信息，同时，chubby还会定期的进行服务器状态的查询，来确定服务器的运行情况。

在一个数据集群中，master的产生是竞争上岗的，也就是所有的服务器都可以向chubby发送一个成为master的请求，获得一个master锁，当chubyy接受一个服务器请求后，就不会再接受其他服务器的请求，从而保证了在一段时间内，一个服务器集群中，只有一个master。

在一个服务器成为master后，会扫描chubby下服务器注册表目录（server directory，server file），来获取所有现存的服务器信息。

master与每个tablet server通信，来检测其上已经分配的tablet。

master 扫描由chubby 管理的METADATA 表，来获知tablet集合从而来管理从服务器上tablet。如给一个服务器分配tablet,在一个从服务器下线后，对其上的数据进行重新分配，如果一个从服务器上数据量过大，由master进行数据的再分配 ，从而实现负载均衡。

 草图如下 ：

官方架构如下：

 

至此，基本上对bigtable有了大概了解，达到标题的据说的目标，但只了解，了解，了解，了解，了解，

 

BigTable 设计 - BigTable 单元格大小的上限

【中文标题】BigTable 设计 - BigTable 单元格大小的上限

【英文标题】：BigTable Design - Upper Limit of the size of a BigTable cell

【发布时间】：2012-01-14 14:56:57

【问题描述】：

我想知道 BigTable 是否对单元格内容的大小有上限。我所说的 BigTable 单元格是指表的特定列族、特定行和特定时间戳中的单元格。如果是，那么上限是多少，如果不是，那么在不影响性能的情况下，cell 的大小可以扩大到多少？

BigTable 论文说每个 SSTable 文件内部都有 64Kb 块和一个索引。这是否意味着索引的键是row+column+timestamp（其中+表示连接），并且某个键映射的值是64kb的对应单元格？那么这是否意味着 BigTable 单元格不能超过 64 Kb？

谢谢

【问题讨论】：

好吧，先生。聪明的裤子......如果你没有什么可说的，你最好别这样......usenix.org/event/osdi06/tech/chang/chang_html

【参考方案1】：

你指的是google对大表的具体实现吗？我想只有谷歌的人才可以回答这个问题。

论文本身并没有将单元格限制为 64 kb。虽然没有提到，但我想单元格可以跨越多个 sstable 块。

大表数据模型的两个主要开源实现都允许大于 64kb 的单元格。 Apache Cassandra 的技术限制为 2gb，尽管实际限制要小得多。 Apache HBase 常见问题解答建议不要使用超过 10mb 的单元大小，但我不确定实际的技术限制。

【讨论】：

这很有帮助。谢谢！

【参考方案2】：

根据 BigTable 文档中的Designing Your Schema，有个别值的建议限制和硬限制。

建议限制：~10 兆字节（10.4858 兆字节）

硬限制：100 MB

但值得注意的是，对于行也有推荐和硬限制，并且有足够的满足推荐/硬限制的单元格很可能会超过行限制。