Bigtable(二):Bigtable如何实现伸缩性及高性能_bigtable cache refresh

自己通过阅读了解论文和极客时间相关讲解，并通过自己已有的框架知识，总结该文章。本篇紧接上文，Bigtable如何解决伸缩性，高性能等问题，需要有基础的HBase知识。

Bigtable 的基本数据模型

一张很宽的稀疏性表。

这里放一个HBase的表结构

这里Row Key是主键，而剩下为该列的信息和值。（列不一定存在）。

很多人说HBase是列式数据库，实则不然，它更像是KV键值对类型的数据库，也正因此他是稀疏的并节省了空间，列式数据库应该是在物理结构上，按列存储，如ORC，Perquet等。但整张HBase表是一张逻辑表。

这种key-value的结构，可以使得他随意改变表的字段结构，但是不会有太多开销，类比于Mysql更改表的结构就需要锁住整张表，要好的太多。这种更像是推迟的"决策"，令我们更灵活。

伸缩性

BigTable通过动态区间分区，自动分裂的方式来增加他的可伸缩性，当一个分区数据过多时，其会自动分为两个分区，当一个分区过少时，其将与旁边的分区进行合并。这使得每个分区在数据量上，会相对比较均匀。而且，在分区发生变化的时候，需要调整的只有一个分区，不会有大量搬运数据的压力。

BigTable的如何实现上述所说功能，其主要依靠Master 、Chubby、为每个分片提供服务的 Tablet Server及底层作为数据存储的GFS实现。

Tablet Server是实际提供数据读写服务的组件，并负责将分区进行合并，分裂。

Master 负责Tablets分给哪些Tablet Server，也起负载均衡的功能。（这是Mysql难以做到的，其原理是其底层依赖于GFS这个分布式存储的组件，数据和服务可以不在同一个机器上）。

Tablet Server只负责在线服务，而非数据存储，当进行负载均衡时，我们只是调度Tablet，并不需要将数据一起搬走。而Mysql数据和服务是在同一节点的。（我们并不保障Tablet Server所服务的Tablets下的底层SSTable数据，在同一个物理服务器上）

Master的作用：分配 Tablets 给 Tablet Server；检测 Tablet Server 的新增和过期；平衡 Tablet Server 的负载；对于 GFS 上的数据进行垃圾回收（GC）；管理表和列族的 Schema 变更，比如表和列族的创建与删除。

Chubby的作用：确保我们只有一个 Master（防止网络分区，脑裂问题）；存储 Bigtable 数据的引导位置（root表，我们读写数据无需经过Master）；发现 Tablet Servers 以及在它们终止之后完成清理工作；存储 Bigtable 的 Schema 信息；存储 ACL，Bigtable 的访问权限。

Chubby类似我们所学的Zookeeper，我们不必担心Chubby的压力，因为root表只有一张且不会分裂，客户端可以对其已经查询过的进行缓存。另外即使Master挂掉，我们也无需害怕，因为客户端读写根本不经过Master，这使得其更加高可用。（读写过程不再阐述，和HBase基本一样）

高性能的随机数据写入（本质仍旧是顺序写）

我们的写入数据只要写入日志文件（崩溃后，重放即可），就算成功，而后其将数据写入MemTable，当达到阈值时，我们将其冻结，写入新的MemTable。被冻结的MemTable被转换为SSTable的文件写入GFS，而后将内存释放。其中写入都是顺序写，并且在MemTable中的数据也会进行排序。

修改并非真的进行“修改”，而是存储多个版本，在其进行Major Compaction时，保留时间戳最近的三个版本的数据，这个时候老的才被删除。而删除动作也只是打上delete的标志，熟悉HBase结构，即可知。在读取时会将其忽视，合并时将其真的删除。（本质通过合并 SSTable，清理掉过期版本和被标记为删除的数据）

高性能的随机数据读取

• MemTable的数据结构：跳表（O(logN)），利于插入，读取，和进行范围读取。

• SSTable的数据结构：第一部分，实际要存储的行键、列、值以及时间戳，数据会按照行键排序分成一个个固定大小的块（block）来进行存储。第二部分，一系列的元数据和索引信息，其中包括用来快速过滤当前SSTable 中不存在的行键盘的布隆过滤器（并不一定，但至少有90的概率）。另外我们还有元数据索引块，数据索引块，使得我们可以更快的查询。

  因为数据块本身是顺序存储的，所以我们只需要将其进行有序链表的多路归并即可。Major Compaction减少SSTable的时候，也减少了我们访问硬盘的次数。

• 两级缓存架构（LRU）
  高层的缓存，对查询结果进行缓存，即 Scan Cache。低层的缓存，对查询所获取到的整个数据块进行缓存（局部性原理），即 Block Cache。当我们查询原来查询过的数据，或者临近的数据，我们可以很快的得到数据而不用访问磁盘。

  实际HBase的LRUBlockCache的三段缓存架构:
  第一段single-access占用25%的比例，也即单次读取区，block被读出后先放到这个区域，当被读到屡次后会升级到下一个区域。
  第二段multi-acsess占用50%的比例，也即屡次读取区，当一个被缓冲到单次读取区后又被访问屡次，会升级到这个区。
  第三段in-memory占用25%的比例，这个区域跟Block被访问几回没有关系，它只存放那些被设置了IN-MEMORY=true的列族中读取出来的block。

所以其高性能来源于，MemTable和SSTable的数据结构，合并 SSTable以减少读请求需要访问的 SSTable 的数量，布隆过滤器，索引，两级缓存架构。

至此全部结束！