相关语录

如果客户端缓存中没有查到对应的rowkey信息，需要首先到ZooKeeper上/hbase-root/meta-region-server节点查找HBase元数据表所在的RegionServer。向hbase:meta所在的RegionServer发送查询请求，在元数据表中查找rowkey所在的RegionServer以及Region信息。客户端接收到返回结果之后会将结果缓存到本地，以备下次使用。

如果发现currentNode后继节点的值小于等于待查询值，则沿着这条链表向后查询，否则，切换到当前节点的下一层链表。

NameNode本质上是一个独立的维护所有文件元数据的高可用KV数据库系统。为了保证每一次文件元数据都不丢失，NameNode采用写EditLog和FsImage的方式来保证元数据的高效持久化。每一次文件元数据的写入，都是先做一次EditLog的顺序写，然后再修改NameNode的内存状态。同时NameNode会有一个内部线程，周期性地把内存状态导出到本地磁盘持久化成FsImage（假设导出FsImage的时间点为t），那么对于小于时间点t的EditLog都认为是过期状态，是可以清理的，这个过程叫做推进checkpoint。

扩容操作一般分为两个步骤：首先，需要增加节点并让系统感知到节点加入；其次，需要将系统中已有节点负载迁移到新加入节点上。

对于本地数据，ShortCircuitLocalRead策略允许客户端绕过DataNode直接从磁盘上读取本地数据，因为不需要经过DataNode而减少了多次网络传输开销，因此数据读取的效率会更高。

Scanner的核心体系包括三层Scanner：RegionScanner，StoreScanner，MemStoreScanner和StoreFileScanner。

注意，这是一个非常关键的字段，表明了LSM树内存储的不只是数据，而是每一次操作记录。

StochasticLoadBalancer是目前HBase默认的负载均衡策略

HBaseTTL过期的数据是通过Compaction机制进行删除的，因此会出现失效时间到期之后，数据还存在于系统之中但查询不出来的情况。

用于解决Google内部海量结构化数据的存储以及高效读写问题。