hbase 二进制数据写入_Hbase对于大对象存储的三种主要解决方案

本帖最后由 非鱼 于 2015-4-29 12:23 编辑

方案1：HBase自身的大对象存储方案

由于HBase底层数据都是以Bytes数组来存储,对于非结构化数据的大对象可以很容易的转成Bytes数组存进HBase。另一方面,由于HBase是一个按列存储的数据库,在一个大表中,为了不让大对象影响其他结构化数据的读性能,可以将大对象数据单独存储进HBase表的单个Column Family中。

这种方案的优势在于:

优势一:实现简单。充分利用HBase自身特点,按列存储,将大对象数据单独存为一个列族。不需要任何额外的代码或功能的引入。

优势二:数据管理方便。将大对象数据的管理完全交给HBase自身的机制,和其他数据一样以StoreFile形式存储在Region中,并按照HBase对于Region的管理方式统一进行迁移、合并、删除等操作。

优势三:保证一致性。延续HBase本身的强一致性和管理方式,保证其大对象数据的一致性。

而这种方案的缺点也很明显:

缺陷一:无法回避Split和Compaction,写性能较差。之前己经提到过HBase由于大对象的影响,在写入时容易频繁的触发Split和Compaction,由于Split对 于写操作的阻塞和Compaction对于集群I/O的占用,将直接对写性能造成直接的不良影响。缓慢的Compaction操作也会导致Flush的延时,从而阻塞住客户端的更新。

缺陷二:不稳定的延时。由于Split和Compaction带来的影响,导致其Flush过程被延时从而引发MemStore的不断增长导致客户端的插入被锁住,这种延时一方面难以满足实时系统的低延时要求,另一方面是其不稳定的延时有可能会导致超时异常而引发不必要的重试。

方案2：基于HDFS的HBase大对象存储方案

由于大对象数据容量过大导致频繁的触发Split和Compaction从而引发客户端写的阻塞,所以很容易的能够想到,如果我们将大对象数据排除在HBase本身的写流程之外,就可以