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没有关系了。

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管理。 

你可能感兴趣的:(java,orm,hbase)