内存压缩
77.概述
内存压缩(A.K.A Accordion)是 hbase-2.0.0 中的一项新功能。它首先在 Accordion 的 Apache HBase 博客上推出:HBase 通过内存压缩进行呼吸。引用博客:
Accordion 将 LSM 主体[ Log-Structured-Merge Tree ,HBase 所基于的设计模式]重新应用于 MemStore,以便在数据仍在 RAM 中时消除冗余和其他开销。这样做可以降低冲洗到 HDFS 的频率,从而减少写入放大和整个磁盘占用空间。由于刷新次数较少,因此 MemStore 溢出时写入操作停止的频率降低,因此写入性能得到改善。磁盘上的数据越少,对块缓存的压力越小,命中率越高,最终读取响应时间越长。最后,具有较少的磁盘写入也意味着在后台发生较少的压缩,即,从生产(读取和写入)工作中窃取的循环较少。总而言之,内存压缩的效果可以被设想为催化剂,使系统整体上移动得更快。
开发人员视图可在 Accordion:内存压缩的开发人员视图中找到。
内存压缩在高数据流失时效果最佳;当数据仍在内存中时,可以消除覆盖或过度版本。如果写入都是唯一的,则可能会拖动写入吞吐量(内存中压缩成本 CPU)。我们建议您在部署到生产之前进行测试和比较。
在本节中,我们将介绍如何启用 Accordion 和可用的配置。
78.启用
要启用内存中压缩,请在您希望行为的每个列族上设置 _IN_MEMORY COMPACTION 属性。 _IN_MEMORY COMPACTION 属性可以具有四个值之一。
_ 无 _:无内存压缩。
BASIC :基本策略启用刷新并保持刷新管道,直到我们跳过管道最大阈值,然后我们刷新到磁盘。没有内存中的压缩,但可以帮助提高吞吐量,因为数据从挥霍的原生 ConcurrentSkipListMap 数据类型转移到更紧凑(和高效)的数据类型。
EAGER :这是 BASIC 政策加上内存压缩的冲洗(很像是对 hfiles 进行的盘上压缩);在压缩方面,我们应用磁盘规则来消除版本,重复,ttl'd 单元格等。
ADAPTIVE :自适应压缩适应工作负载。它根据数据中重复单元格的比例应用索引压缩或数据压缩。实验。
要在表 _ 萝卜 _ 中的 info 列系列上启用 BASIC ,请禁用该表并将该属性添加到 info 列族,然后重新启用:
hbase(main):002:0> disable 'radish'
Took 0.5570 seconds
hbase(main):003:0> alter 'radish', {NAME => 'info', IN_MEMORY_COMPACTION => 'BASIC'}
Updating all regions with the new schema...
All regions updated.
Done.
Took 1.2413 seconds
hbase(main):004:0> describe 'radish'
Table radish is DISABLED
radish
COLUMN FAMILIES DESCRIPTION
{NAME => 'info', VERSIONS => '1', EVICT_BLOCKS_ON_CLOSE => 'false', NEW_VERSION_BEHAVIOR => 'false', KEEP_DELETED_CELLS => 'FALSE', CACHE_DATA_ON_WRITE => 'false', DATA_BLOCK_ENCODING => 'NONE', TTL => 'FOREVER', MIN_VERSIONS => '0', REPLICATION_SCOPE => '0', BLOOMFILTER => 'ROW', CACHE_INDEX_ON_WRITE => 'false', IN_MEMORY => 'false', CACHE_BLOOMS_ON_WRITE => 'false', PREFETCH_BLOCKS_ON_OPEN => 'false', COMPRESSION => 'NONE', BLOCKCACHE => 'true', BLOCKSIZE => '65536', METADATA => {
'IN_MEMORY_COMPACTION' => 'BASIC'}}
1 row(s)
Took 0.0239 seconds
hbase(main):005:0> enable 'radish'
Took 0.7537 seconds
请注意 IN_MEMORY_COMPACTION 属性如何显示为 METADATA 映射的一部分。
还有一个全局配置, hbase.hregion.compacting.memstore.type ,您可以在 hbase-site.xml 文件中设置。使用它来设置创建新表时的默认值(在创建列族存储时,我们首先查看列族配置,查找 _IN_MEMORY COMPACTION 设置,如果没有,我们再咨询 hbase.hregion.compacting.memstore.type 值使用其内容;默认为 BASIC )。
默认情况下,新的 hbase 系统表将具有 BASIC 内存中压缩集。为了另外指定,在新的表创建时,将 hbase.hregion.compacting.memstore.type 设置为 NONE (注意,设置此值后创建系统表将不具有追溯效果;您必须更改表格以将内存中属性设置为 NONE )。
当内存中的刷新发生时,通过将配置的区域刷新大小(在表描述符中设置或从 hbase.hregion.memstore.flush.size 中读取)除以列族的数量然后相乘来计算 hbase.memstore.inmemoryflush.threshold.factor 。默认值为 0.014。
监视管道所承载的刷新次数,以便符合 memstore 大小调整的范围,但您也可以通过设置 _hbase.hregion.compacting.pipeline.segments.limit 来设置总刷新次数的最大值 _。默认值为 2。
创建列族 Store 时,它会说明哪些 memstore 类型有效。在撰写本文时,有一个老派 DefaultMemStore 填充 ConcurrentSkipListMap ,然后刷新到磁盘或新的 CompactingMemStore ,它是提供这个新功能的实现内存中压缩设施。以下是来自 RegionServer 的日志行,该日志行显示了一个名为 _ 系列 _ 的列族存储配置为使用 CompactingMemStore :
Note how the IN_MEMORY_COMPACTION attribute shows as part of the _METADATA_ map.
2018-03-30 11:02:24,466 INFO [Time-limited test] regionserver.HStore(325): Store=family, memstore type=CompactingMemStore, storagePolicy=HOT, verifyBulkLoads=false, parallelPutCountPrintThreshold=10
在 CompactingMemStore 类( org.apache.hadoop.hbase.regionserver.CompactingMemStore )上启用 TRACE 级别日志记录,以查看其操作的详细信息。