概念一：LSM树
1.1 LSM大致介绍
传统RDBMS数据库使用B+树结构，它的特点是能够保持数据稳定有序，其插入与修改拥有较稳定的对数时间复杂度。
HBase使用LSM（Log-Structured Merge Tree日志结构合并树）树，用于为那些长期具有很高记录更新（插入或删除）频率的文件提供低成本的索引机制。LSM-Tree通过使用某种算法对索引变更进行延迟及批量处理，并通过一种类似于归并排序的方式联合使用一个基于内存的组件和一个或多个磁盘组件。
与传统访问方式（比如B+树）相比，该算法大大减少了磁盘磁臂的移动次数，同时还会提高那些使用传统访问方式进行插入时，磁盘磁臂开销（寻道+转动）远大于存储空间花费的情况的性价比。但是，对于那些需要立即响应的查找操作来说，某些情况下，它也会损失一些IO效率，因此LSM-Tree最适用于那些索引插入比查找操作更常见的情况。比如，对于历史记录表和日志文件来说，就属于这种情况。
1.2 B+树与LSM-Tree树本质区别
他们本质不同点在于他们使用现代硬盘的方式，尤其是磁盘。从磁盘使用方面讲，有两种不同的数据库范式：一种是寻道，另一种是传输。RDBMS是寻道型，它需要随机读写数据。LSM-Tree则属于传输型，它会顺序读写数据。
LSM-Tree工作在磁盘传输速率的级别上，因为它会使用日志文件和一个内存存储结构把随机写操作转换为顺序写。读操作与写操作是独立的，这样这两种操作之间就不会产生竞争。
概念二：底层持久化
2.1 存储的工作原理
一个新的客户端为找到某个特定的行键首先需要连接ZooKeeper Qurom。它会从Zookeeper检索持有-ROOT-Region的服务器名。通过这个信息，它询问拥有-ROOT-Region的RegionServer，得到持有对应行键的.META. 表Region的服务器名。这两个操作的结果都会被缓存下来，因此只需要查找一次。最后，它就可以查询.META. 服务器，然后检索包含给定行键的Region所在的服务器。
一旦它知道了给定的行键所处的位置，比如，在哪个Region里，它也会缓存该信息，同时直接连接持有该Region的HRegionServer。现在，客户端就有了去哪里获取行的完整信息而不需要再去查询.META.服务器。
2.2 Flush机制
Flush命令会将内存数据写入存储文件否则我们必须等着它直到超过配置的flush大小才会将数据插入存储文件中。
概念三： Region切分与合并
3.1 Region切分
当一个Region内的存储文件超过hbase.hregion.max.filesize时，该Region就需要split为两个。该过程完成迅速，因为系统只是简单地为新Region创建两个引用文件，每个只持有原始Region一半的内容。
（1）RegionServer通过在父Region内创建切分目录来完成。之后，它会关闭该Region，这样它就不再接受任何请求。
（2）然后RegionServer开始准备生成新的Region，通过在切分目录内设置必要的文件结构来完成。
（3）现在两个子Region已经就绪，同时将会被同一个服务器并行打开。现在需要更新.META.表，将这两个Region作为可用Region对待，同时会启动对这两个Region的合并。
（4）原始Region最终会被清除，意味着它会从.META.表中删除，磁盘上它的所有文件也会被删除。最后，Master会收到关于该split的通知，通过负载平衡等将这些新的Region移动到其他服务器上。
3.2 合并
存储文件处于严密的监控之下，这样后台进程就可以保证他们完全处于控制中。MemStore的flush操作会逐步增加磁盘上的文件数目。当数目足够多的时候，合并进程会将它们合并成规模更少但是更大的文件。
概念四：日志
为了避免产生过多的小文件，RegionServer在未收集到足够数据flush到磁盘之前，会一直把它保存在内存中。为解决这个问题HBase采用WAL策略：每次更新之前，将数据写写到一个日志中，只有当写入成功后才通过客户端该操作成功。
4.1 概要流程
类似Mysql中的bin-log，WAL会记录下针对数据的所有变更，在内存产生问题时，可以通过日志回放，恢复到服务器宕机之前的状态。
首先，客户端发起数据更新动作，每个更新操作都会被包装为一个KeyValue对象，然后通过RPC调用发送出去，该调用到达具有对应Region的某个HRegionServer。
其次，KeyValue对象到达后，会被发送到指定的行键所对应的HRegion。数据会先写入WAL，然后存入相应的MemStore中。
最终，当MemStore达到一定大小后，或者过了特定时间段后，数据就会异步地持久化到文件系统中。在此期间都存储在内存中。WAL可以保证数据不会丢失。
4.2 日志一致性
日志流数据的持久化过程具体如何实现，是否存在数据丢失的问题？为了能够让日志的读取可以读到服务器crash时刻最后写入的那个位置，或者尽可能接近该位置，这就需要一个feature:append支持。HBase目前会检测底层的Hadoop库是否支持synFs()或者hflush()。这是linux级别的，作用是当系统异常时commit buffer cache to disk。