bigtable与GFS

一、 GFS整体介绍

1、GFS为何是弱一致性的？
2、HDFS的meta文件备机整合是怎么回事？

任何分布式系统都要关注：
容错性，一致性，负载均衡，垃圾回收

二、bigtable与zookeeper,GFS之间的关系

2-1关系型数据库与非关系型数据库

关系型数据库

bigtable 非关系型数据库，全部数据都存在一张大表里面，以牺牲存储容量换取查询效率

通过上述的图片我们可以看到，bigtable采用非关系型数据库，实际上就是一个一个看的（k，v）结构，key就是行主键，value分为列族，里面有很多列。这样通过key，可以方便的查到key对应的所有value，如果是关系型数据库，比如第一个图片中，需要寻找某个学生的属性，可能要通过系表，找到学生的外键，然后如果没有列存，还需要遍历整个学生表。

2-2 bigtable的架构

从整体上看，bigtable类似于在GFS上层又做了一层分布式的事情，将一张大表分布式的存放在不同的server上面。每个子表则对应一个ssttable文件，很多子表则对应很多ssttable。对于每个server来说，它并不理解字表这个概念，只是单纯的接收master的一个get，put操作，东西多了内存放不下了，就dump到ssttable文件里面。这个ssttable文件则以GFS的分发以副本的形式下放到GFS里面。这个就是和leveldb的不同之处：leveldb在自己的内存中维护一个version，里面记录ssttable的元数据，而bigtable中的元数据存放在master上面，并且是多级缓存。

几个问题：
1、master是怎样选择分发到哪个字表server的？
理论上是一开始根据负载计算得出的，后面是根据记录在zookeeper上面的znode得到的

2、元数据表里面存放的都是什么信息？元数据库表只有一张么？
不，有很多张
3、根表格里面存放的又是什么信息？上面来查数据，带着key来查，再根表中怎么和这个key对应？
更高级的key的范围，如下图

4、这些表格需要下盘存储么？还是只存在在内存中？
是在内存中的，但是这些表格的一些基本元数据在zookeeper的元数据中也存有一份，供master实时监控