昨天在飞机上的2个小时看了一遍HBase的Client API，有几点心得：
1.在Put小记录时最好关闭autoFlush，并合理设置WriterBuffer：
因为每次Put都要进行一次RPC调用+WAL（关闭对写入提升非常大）+Server端处理，如果对于大批量小数据写入的话RPC的RTT消耗的时间就会成为写入的损耗点，因此可以通过本地缓冲批量提交的方式；默认的WriteBuffer大小是2MB，当autoFlush关闭时，客户端每次put都会写入到一个ArrayList内，每10次检查一次，当size超过WriteBuffer size时则进行一次flushCommit，会将WB的Put按照RS进行分组，每个RS进行一次RPC调用处理；
当提交到Server端后，如果发生异常，则会将WB中已经写入的Put删除，保留提交失败的进行异常处理；
不过WB的大小需要合理设置，因为占用本地和RS的内存.
本地内存占用很好估计，而服务端的内存最大消耗则是：hbase.client.write.buffer * hbase.regionserver.handler.count * number ofregion server
2.Scanner的batch/cache设置：
Scan具体的处理流程如下图：
Caching的设置主要影响RSnext的调用(可以理解成面向“行”的batch)，而batch则是RSRegionScanner每次nextInternal获取的keyvalue数（可以理解成面向“列”的batch）；
因此具体SCAN调用RPC次数由两个参数共同决定=cells总数/（caching*min(batch,cells/row)）；
那这里scanner的next(n)其实和MYSQL JDBC里的fetch类似，其实是在客户端loop模拟的，而不是真的在server端进行batch fetch，其实这里的scan和mysql 里的cursor是非常类似的，因此理解了一个理解另外一个就是水到渠成了.
不过这里也有WB同样的问题就是内存消耗，以及网络传输,处理完毕时及时关闭.
3.HConnection的处理：
简称HC，都是由shared的HCManager产生，而一个HC是存储在HCManager的HBASE_INSTANCES的MAP类型里，也就是说同一个Client+Conf是共享HC的，这样有个好处就是首先共享了 ZK连接，其实就是在split/merge时只对一个HC进行metadata refresh就OK了.
缺点就是这些连接会一直保持到客户端进程退出，会导致ZK连接超maxClientCnxns异常.
4.Coprocessor：
类似对比MySQL的trigger和procedure.稍候再详细介绍
5.Counter
这个计数器非常好用，不过用HBase做计数compared to redis是不是略重了：P
6.RowLock
这个应该是被禁用掉的东西，RS杀手啊...可以把rpc handler hold住lease.period...
7.管理API：
Split/Compact 运维利器:)
