《Google-Bigtable》读书笔记

1. “Bigtable为客户提供了简单的数据模型，利用这个模型，客户可以动态控制数据的分布和格式，用户也可以自己推测底层存储数据的位置相关性。”这也就要求，表的结构是与业务紧密相关的，写代码的人，不得不去了解是如何存储的，否则查询效率会很低。

2. “Bigtable通过行关键字的字典顺序来组织数据”，这个与关系数据库看似一致，关系数据库不是有索引么，表呈现的时候也是按照字典序的，但是Bittable中的“组织数据”的意思是物理存储上也是挨着的。这也意味着，只有一个行关键字，但是为了一张表复用多个业务，一个行关键字中会有多个关系数据库中的“字段”，比如，行关键字可以是设备id+设备类型+设备名称什么的一个大长串。

3. “列关键字组成的集合叫做“列族“，列族是访问控制的基本单位。”这里的访问控制不仅包括查询，更新，甚至物理的存储位置。既然都是一个“列族”说明，列族内的列至少有点关系了，都一个族群了。也就是说在查询的时候可能一起查询，或者他们的类型是一样的，类型一样，方便压缩。

4. “Bigtable可以和MapReduce一起使用，MapReduce是Google开发的大规模并行计算框架。我们已经开发了一些 Wrapper类，通过使用这些 Wrapper类，Bigtable可以作为MapReduce框架的输入和输出”

5. “BigTable内部存储数据的文件是 Google SSTable格式的。SSTable是一个持久化的、排序的、不可更改的Map 结构，而Map是一个key-value映射的数据结构，key和 value的值都是任意的Byte 串。可以对SSTable进行如下的操作：查询与一个 key 值相关的 value，或者遍历某个 key 值范围内的所有的 key-value 对。从内部看，SSTable是一系列的数据块（通常每个块的大小是 64KB，这个大小是可以配置的）。SSTable使用块索引（通常存储在 SSTable的最后）来定位数据块；在打开 SSTable的时候，索引被加载到内存。每次查找都可以通过一次磁盘搜索完成：首先使用二分查找法在内存中的索引里找到数据块的位置，然后再从硬盘读取相应的数据块。也可以选择把整个 SSTable都放在内存中，这样就不必访问硬盘了。 ” ——内部数据结构。64K不大也不小，对于普通的硬盘来说一般是4k，而HDFS一般是百兆左右。分块有利于加快索引的速度，与内存中的数据类似，通过索引能够直接计算出地址，然后直接访问。

6. “Bigtable 包括了三个主要的组件：链接到客户程序中的库、一个 Master 服务器和多个 Tablet 服务器。针对系统工作负载的变化情况，BigTable 可以动态的向集群中添加（或者删除）Tablet服务器。 Master 服务器主要负责以下工作：为 Tablet 服务器分配 Tablets、检测新加入的或者过期失效的 Table 服务器、对Tablet服务器进行负载均衡、以及对保存在 GFS上的文件进行垃圾收集。除此之外，它还处理对模式的相关修改操作，例如建立表和列族。每个Tablet服务器都管理一个Tablet的集合（通常每个服务器有大约数十个至上千个 Tablet）。每个Tablet服务器负责处理它所加载的Tablet的读写操作，以及在Tablets过大时，对其进行分割。” ——单master结构。

7. “和很多 Single-Master 类型的分布式存储系统类似，客户端读取的数据都不经过 Master 服务器：客户程序直接和 Tablet 服务器通信进行读写操作。由于 BigTable 的客户程序不必通过 Master 服务器来获取Tablet 的位置信息，因此，大多数客户程序甚至完全不需要和 Master 服务器通信。在实际应用中，Master 服务器的负载是很轻的。 ” ——获取Tablet的信息都不经过master而是交给Chubby（“BigTable 还依赖一个高可用的、序列化的分布式锁服务组件，叫做 Chubby”）。系统设计的一个基本出发点——尽量减少master的负载。这个“master”是Tablet的master，而不是客户端的master，master处理的基本是Tablet的事情。那么路由信息或者说Tablet的信息存在哪里呢？只是在特殊的Tablet表里面，chubby会记录相关的表。