HBase Client使用注意点

HBase Client使用注意点：

1  HTable线程不安全。
   建议使用HTablePool，或者每次new一个HTable出来。
  
2  HTable和HConnection的关系。
   注意HTable对象之间通过Configuration共享HConnection。
   好吧，我偷懒了，实际上是通过HConnectionKey来共享HConnection的。
   因此，相同的Configuration(更精准的说法是连接相关参数相同，参阅HConnectionKey)实际上使用的是同一个HConnection。
   HConnectionKey可以查看源码。
  
3  HTable ResultScanner等等记着close。
   这个没有什么好说的，java世界里面，凡是有close方法的类型，使用结束后，调用close是合情合理的操作。
  
4  HTablePool。
   大部分应用都会使用HTablePool来管理HTable。
   注意这个Pool和一般的Pool有些不一样。
   超出pool maxsize时，一样可以得到HTable的引用，分别在于close时，如果未超出maxsize，htable返回给pool，如果超出maxsize，就close掉了事，和pool没有关系了。
   注意：PooledHTable多次close有问题。同一HTable有可能超过pool大小被close掉，同时，有其他引用被保留在pool中。

5  HTable的构建性能
   由于HTable和HConnection的关系,因此，无论是自己new Htable出来，还是使用HTablePool，都是第一次得到HConnection时比较耗时，后续相同的Configuration获取HTable时，
   都是很高效的，可以认为是一个快速操作。
   当然凡事有例外(很少见)，当HConnectionImplementation的cachedRegionLocations中EMPTY_START_ROW的缓存被冲掉的时候，由于构造HTable，默认会定位一下该row所在的HRegionLocation，
   这个时候构建一个HTable又变慢了。

6  HTablePool的maxSize设置。
   从性能角度来看，由于pool的特性，不会使用maxSize来限制可以获得HTable的数量，因此，maxSize大小无关。
   因此，该问题就变成了，应用中使用HTable的数量对应用有什么影响。
  
7  HTable的数量。  
   从内存角度看，由于HTable中有writeBuffer(不论autoFlush设置为true或者false,autoFlush只是影响flush的时机)，默认2M，太多的HTable并发，对内存有一定的压力。
   从线程角度，由于每个HTable中都有ExecutorService pool，因此HTable的数量会影响到应用线程的多少，线程的多少，反过来又影响内存，性能。
  
8  HTable的批量方法
   可以使用批量方法的地方尽量使用批量方法。性能比较好，原因是底层RPC次数少。
  
9  HTable的autoflush
   实时应用建议设置为true(默认值)，设置为false时性能较好，但是注意有可能丢数据。
  


HBase ORM framework simplehbase除了以下ORM的功能外，提供了HTablePool的管理功能。
1 可以配置autoflush为false时，定时commit writebuffer的当前cache内容。
2 另外，支持HTable的ExecutorService灵活配置，可以多个HTable使用同一个ExecutorService。


simplehbase功能简介 https://github.com/zhang-xzhi/simplehbase
数据类型映射：java类型和hbase的bytes之间的数据转换。
简单操作封装：封装了hbase的put,get,scan等操作为简单的java操作方式。
hbase query封装：封装了hbase的filter，可以使用sql-like的方式操作hbase。
动态query封装：类似于myibatis，可以使用xml配置动态语句查询hbase。
insert,update支持: 建立在hbase的checkAndPut之上。
hbase多版本支持：提供接口可以对hbase多版本数据进行查询,映射。
HTablePool管理。