Google Big Table

   进入当今这个数据时代，大数据技术自然是热的发烫，许多企业需要面对上亿的用户，没有大数据的支持自然无法运转，Google作为一家知名企业，其大数据技术自然是顶尖水平，我看了Google的三大论文之一的Google Big Table，以下是我对这项技术的粗略理解。
   Big Table是一个分布式的结构化数据存储系统，可以用来处理海量数据，通常是分布在数千台普通服务器上的 PB 级的数据，我把这比喻成另外一种形态的云技术云技术，这项技术给客户一个非常简单的数据模型，让客户自己动态控制数据的格式和分布，通过一系列的处理，这些数据都被转换成字符串给客户程序，通过仔细选择数据的模式，客户可以控制数据的位置相关性，最后，可以通过BigTable 的模式参数来控制数据是存放在内存中、还是硬盘上。简而言之就是用行关键字、列关键字以及时间戳来标记数据再通过客户程序处理打包存储在BigTable里面，客户可以通过API函数修改里面的数据。
  在任何一个时刻，一个Tablet只能分配给一个Tablet服务器。Master服务器记录了当前有哪些活跃的Tablet服务器、哪些Tablet分配给了哪些Tablet服务器、哪些Tablet还没有被分配。当一个Tablet还没有被分配、并且刚好有一个Tablet服务器有足够的空闲空间装载该Tablet，Master服务器会给这个Tablet服务器发送一个装载请求，把Tablet分配给这个服务器，追踪记录则由Chubby完成。
   Tablet的持久化状态信息保存在GFS 上。更新操作提交到REDO日志中。在这些更新操作中，最近提交的那些存放在一个排序的缓存中，我们称这个缓存为memtable；较早的更新存放在一系列SSTable中。为了恢复一个Tablet，Tablet服务器首先从METADATA表中读取它的元数据。Tablet的元数据包含了组成这个Tablet的SSTable的列表，以及一系列的Redo Point，这些Redo Point指向可能含有该Tablet数据的已提交的日志记录。Tablet服务器把SSTable的索引读进内存，之后通过重复Redo Point之后提交的更新来重建memtable。
   随着写操作的执行，memtable的大小不断增加。当memtable的尺寸到达一个门限值的时候，这个memtable就会被冻结，然后创建一个新的memtable；被冻结住memtable会被转换成SSTable，然后写入GFS，Minor Compaction过程有两个目的：shrink Tablet服务器使用的内存，以及在服务器灾难恢复过程中，减少必须从提交日志里读取的数据量。在Compaction过程中，正在进行的读写操作仍能继续，就是当memtable大到一定程度是打包压缩，从而达到以上两个优点。