Google BigTable 学习笔记

BigTable基本的数据模型是一个多维度Map (row:string, colu mn:string,time:int64)->string
Bigtable三个主要的组件：
链接到客户程序中的库（供客户端调用服务）：
一个Master服务器（由Chubby支持）：
Chubby上会有活跃的Tablet Servers的列表，Master会时刻跟踪这个列表；
Chubby上还存有各Tablet Server的Root Tablet位置，用来供Master获得Tablet Server上的METADATA Tablet；
一些锁文件，用来保证Master的性，以及Tablet Server的注册信息和状态；
Master还会维护一个未分配Tablet队列，这是在Master刚启动时候就开始加载的，之后也会动态维护更新。
总之Master通过调用Chubby上的一些注册文件信息以及自己的内存中维护的表来管理Tablet Servers，但Client实际访问数据时不必通过Master
多个Tablet 服务器：
用来负责其上的每个Tablet的读写操作，以及Tablet的分裂；
汇总图

 

还有不少问题没有明白：
文章里说“一个Chubby服务包括五个活动的副本，其中一个副本被选为Master”，这里副本的意思是什么？为什么需要五个副本。Chubby服务和Master服务到底是有什么关系？Chubby服务和Master服务是在同一台机器上的么？我个人认为是Chubby只有用来维护一些静态数据，然后供活动的Master服务调用。不知道理解的对不对。
第六章优化里提到“客户程序可以将多个列族组合成一个局部性群族。对Tablet 中的每个局部性群组都会生成一个单独的SSTable ”，这里所谓的生成单独的SSTable是指把原先的拆分还是类似于做原先的一个子集的副本？个人偏向于后一个。
在“Commit日志的实现”里，提到“为了避免多次读取日志文件，我们首先把日志按照关键字（table ，row name，log sequence
number ）排序。排序之后，对同一个Tablet 的修改操作的日志记录就连续存放在了一起，因此，我们只要一次磁盘Seek操作、之后顺序读取就可以了。” 这和之前的方法有什么区别？是说现在的话每个需要用日志回复的Tablet服务器不需要加载整个日志文件，而只需要从那个有日志的服务器中seek后顺序读取？这样就会快吗？？？
“Tablet恢复提速”中，Minor Compaction是怎么对日志文件做归并的？为什么日志文件中会有没有归并的记录？因为有两个线程生成的日志文件？它不是用来将Memtable转化成SSTable进行持久化存储的么？
————————————————
版权声明：本文为CSDN博主「warlock333」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/warlock333/article/details/8187092