《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会记录相关的表。

Table of Contents