第一章
Apache HBase是一个分布式的基于于读性能优化的列式存储，读性能的优化来自于每个列簇对应一个文件。HBase最初思想来源于Google文件系统。以列为单位进行数据聚合， 可以减少IO， 因为列上的数据结构天生相似，逻辑上来说每行之间只有轻微的不同，所以更有利于提高压缩比从而降低返回结果时的带宽消耗,
在网站用户量增加一定程度的时候，减少压力的第一步是增加用于并行读取的从服务器，也就是读写分离，主服务器只服务于写请求，因为网站请求主要由用户浏览构成，写请求实际是很少的， 在这个方案抗一段时间后下一步就是增加缓存，将读操作接入到高速内存缓存当中，但是有了缓存以后就会产生数据的不一致性， 也就是数据库数据与缓存数据的不一致性， 这个不一致性的时间差需要做到尽量最小化。 再继续随着网站的功能扩容，这些功能都会转化为后台数据库的查询语句，以前顺利执行的SQL Join也会突然变慢，或者无法执行，这个时候就需要采用逆范式化存储结构，也就是为了节省时间多设计一些冗余字段，以空间换取时间的策略。（存储过程是可以解决多个客户端同时更新数据的一致性问题，也就是需要始终保证多张表的数据一致性时的解决方案），存储过程也会慢慢无效，此时索引的性能提升也会慢慢下降。这个时候可以考虑数据分区，但是代价昂贵，运维成本高
HBase中扩展和负载均衡的基本单元称为region,本质上region是以行键排序的连续存储区间，region太大的时候就会把他们动态拆分，反之就会合并，一台region server可以同时加载多个region.
HFile中存储的是经过排序的键值映射结构,每个HFile有一个块索引，在内存中的块索引中进行二分查找，确定可能包含键的块,然后读取磁盘块找到实际要找的键.
每次更新数据时，都会先将数据记录在提交日志中(WAL write-ahead log),然后再将这些数据写入内存的memstore中，一旦内存保存的写入数据的大小超过了一个给定的最大值，就会将这些数据移出内存作为HFile刷到磁盘中，数据移出内存后系统就会丢弃对应的提交日志，只保留未持久化到磁盘的提交日志。
随着memstore中的数据不断刷到磁盘中，会产生越来越多的HFile文件，HBase内部有一个解决问题的管家机制。将文件进行合并 1: minor合并:将多个小文件重写为数量较少的大文件，减少文件存储数量（实际是个多路归并的过程）. 2:major合并:将一个region中的若干个HFile重写为一个新的HFile, major是清理墓碑记录的唯一机会
HBase 读:
如果想快速访问数据，通用的原则是数据保持有序并尽可能保存在内存里。HBase实现了这两个目标，大多数情况下读操作可以做到毫秒级。HBase读动作必须重新衔接持久化到硬盘上的HFile和内存中MemStore里的数据。HBase在读操作上使用了LRU(最近最少使用算法)缓存技术。这种缓存也叫做BlockCache，和MemStore在一个JVM堆里。BlockCache设计用来保存从HFile里读入内存的频繁访问的数据，避免硬盘读。每个列族都有自己的BlockCache。
掌握BlockCache是优化HBase性能的一个重要组成部分。BlockCache中的Block是HBase从硬盘完成一次读取的数据单位。HFile物理存放形式是一个Block的序列外加这些Block的索引。这意味着，从HBase里读取一个Block需要先在索引上查找一次该Block，然后从硬盘读出。Block是建立索引的最小数据单位，也是从硬盘读取的最小数据单位。Block大小按照列族设定，默认值是64KB。根据使用场景你可能会调大或者调小该值。Block变小会导致索引变大，进而消耗更多内存；Block变大意味着索引项变少，索引变小，因此节省内存。
从HBase中读出一行，首先会检查MemStore等待修改的队列，然后检查BlockCache看包含该行的Block是否最近被访问过，最后访问硬盘上的对应HFile。