- 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进行持久化存储的么?