简介
Region内每个ColumnFamily的数据组成一个Store。每个Store内包括一个MemStore和若干个StoreFile(HFile)组成。
Memstore类重要成员变量
volatile KeyValueSkipListSet kvset;*//内存中存放更新的KV的数据结构*
volatile KeyValueSkipListSet snapshot;*//Flush操作时的KV暂存区域*
final ReentrantReadWriteLock lock = **new** ReentrantReadWriteLock();*//Flush操作与kvset之间的可重入读写锁*
final AtomicLong size;*//跟踪记录MemStore的占用的Heap内存大小*
TimeRangeTracker timeRangeTracker;*//跟踪记录kvset的最小和最大时间戳*
TimeRangeTracker snapshotTimeRangeTracker;*//跟踪记录snapshot的最小和最大时间戳*
MemStoreLAB allocator;*//实际内存分配器*</pre>
Memstore 工作流程
Memstore 工作流程
Memstore Flush
HBase为了方便按照RowKey进行检索，要求HFile中数据都按照RowKey进行排序，Memstore数据在flush为HFile之前会进行一次排序
为了减少flush过程对读写的影响，HBase采用了类似于两阶段提交的方式，将整个flush过程分为三个阶段：
-
prepare阶段：遍历当前Region中的所有Memstore，将Memstore中当前数据集kvset做一个快照snapshot，然后再新建一个新的kvset。后期的所有写入操作都会写入新的kvset中，而整个flush阶段读操作会首先分别遍历kvset和snapshot，如果查找不到再会到HFile中查找。prepare阶段需要加一把updateLock对写请求阻塞，结束之后会释放该锁。因为此阶段没有任何费时操作，因此持锁时间很短。
-
flush阶段：遍历所有Memstore，将prepare阶段生成的snapshot持久化为临时文件，临时文件会统一放到目录.tmp下。这个过程因为涉及到磁盘IO操作，因此相对比较耗时。
-
commit阶段：遍历所有的Memstore，将flush阶段生成的临时文件移到指定的ColumnFamily目录下，针对HFile生成对应的storefile和Reader，把storefile添加到HStore的storefiles列表中，最后再清空prepare阶段生成的snapshot。
频繁的Memstore Flushes
要避免“写阻塞”，貌似让Flush操作尽量的早于达到触发“写操作”的阈值为宜。但是，这将导致频繁的Flush操作，而由此带来的后果便是读性能下降以及额外的负载。
每次的Memstore Flush都会为每个CF创建一个HFile。频繁的Flush就会创建大量的HFile。这样HBase在检索的时候，就不得不读取大量的HFile，读性能会受很大影响。
为预防打开过多HFile及避免读性能恶化，HBase有专门的HFile合并处理(HFile Compaction Process)。HBase会周期性的合并数个小HFile为一个大的HFile。明显的，有Memstore Flush产生的HFile越多，集群系统就要做更多的合并操作(额外负载)。更糟糕的是：Compaction处理是跟集群上的其他请求并行进行的。当HBase不能够跟上Compaction的时候(同样有阈值设置项)，会在RS上出现“写阻塞”。像上面说到的，这是最最不希望的。
提示：严重关切RS上Compaction Queue 的size。要在其引起问题前，阻止其持续增大。
想了解更多HFile 创建和合并，可参看 Visualizing HBase Flushes And Compactions。
理想情况下，在不超过hbase.regionserver.global.memstore.upperLimit的情况下，Memstore应该尽可能多的使用内存(配置给Memstore部分的，而不是真个Heap的)。下图展示了一张“较好”的情况：
网络图片
KeyValueSkipListSet
hbase使用的是jdk提供的ConcurrentSkipListMap，并对其进行了的封装，Map结构是<KeyValue,KeyValue>的形式。Concurrent表示线程安全。
SkipList是一种高效的数据结构，之前专门写过文章，这里就不表了
Memstore 引起的内存碎片问题
写入MemStore中的KV，被记录在kvset中。根据JVM内存的垃圾回收策略，在如下条件会触发Full GC。 1、内存满或者触发阈值。 2、内存碎片过多，造成新的分配找不到合适的内存空间。 RS上服务多个Region，如果不对KV的分配空间进行控制的话，由于访问的无序性以及KV长度的不同，每个Region上的KV会无规律地分散在内存上。Region执行了MemStore的Flush操作，再经过JVM GC之后就会出现零散的内存碎片现象，而进一步数据大量写入，就会触发Full-GC。
为了解决因为内存碎片造成的Full-GC的现象，RegionServer引入了MSLAB（HBASE-3455）。MSLAB全称是MemStore-Local Allocation Buffers。它通过预先分配连续的内存块，把零散的内存申请合并，有效改善了过多内存碎片导致的Full GC问题。 MSLAB的工作原理如下： 1、在MemStore初始化时，创建MemStoreLAB对象allocator。 2、创建一个2M大小的Chunk数组，偏移量起始设置为0。Chunk的大小可以通过参数hbase.hregion.memstore.mslab.chunksize调整。 3、 当MemStore有KeyValue加入时，maybeCloneWithAllocator(KeyValue)函数调用allocator为其查找KeyValue.getBuffer()大小的空间，若KeyValue的大小低于默认的256K，会尝试在当前Chunk下查找空间，如果空间不够，MemStoreLAB重新申请新的Chunk。选中Chunk之后，会修改offset=原偏移量+KeyValue.getBuffer().length。chunk内控制每个KeyValue大小由hbase.hregion.memstore.mslab.max.allocation配置。 4、 空间检查通过的KeyValue，会拷贝到Chunk的数据块中。此时，原KeyValue由于不再被MemStore引用，会在接下来的JVM的Minor GC被清理。
MSLAB解决了因为碎片造成Full GC的问题，然而在MemStore被Flush到文件系统时，没有reference的chunk，需要GC来进行回收，因此，在更新操作频繁发生时，会造成较多的Young GC。 针对该问题，HBASE-8163提出了MemStoreChunkPool的解决方案，方案已经被HBase-0.95版本接收。它的实现思路： 1、 创建chunk池来管理没有被引用的chunk，不再依靠JVM的GC回收。 2、 当一个chunk没有引用时，会被放入chunk池。 3、chunk池设置阈值，如果超过了，则会放弃放入新的chunk到chunk池。 4、 如果当需要新的chunk时，首先从chunk池中获取。 根据patch的测试显示，配置MemStoreChunkPool之后，YGC降低了40%，写性能有5%的提升。如果是0.95以下版本的用户，可以参考HBASE-8163给出patch。
网友评论