Configuring the HBase BlockCache

All of the sizes of these objects are highly dependent on your usage patterns and the characteristics of your data. For this reason, the HBase Web UI and Cloudera Manager each expose several metrics to help you size and tune the BlockCache.

If the data needed for an operation does not all fit in memory, using the BlockCache can be counter-productive, because data that you are still using may be evicted, or even if other data is evicted, excess garbage collection can adversely effect performance. For this type of operation, you may decide to bypass the BlockCache. To bypass the BlockCache for a given Scan or Get, use the setCacheBlocks(false) method.

hbase> alter 'myTable', CONFIGURATION => {NAME => 'myCF', BLOCKCACHE => 'false'}

The LruBlockCache implementation resides entirely within the Java heap. Fetching from LruBluckCache will always be faster than BucketCache, because no disk seeks are required. However, LruBlockCache is more impacted by garbage-collection and performance can be less predictable over time than BucketCache.

LruBlockCache contains three levels of block priority to allow for scan-resistance and in-memory column families:

• Single access priority: The first time a block is loaded from HDFS, that block is given single access priority, which means that it will be part of the first group to be considered during evictions. Scanned blocks are more likely to be evicted than blocks that are used more frequently.

• Multi access priority: If a block in the single access priority group is accessed again, that block is assigned multi access priority, which moves it to the second group considered during evictions, and is therefore less likely to be evicted.

• In-memory access priority: If the block belongs to a column family which is configured with the in-memory configuration option, its priority is changed to in memory access priority, regardless of its access pattern. This group is the last group considered during evictions, but is not guaranteed not to be evicted. Catalog tables are configured with in-memory access priority.

  To configure a column family for in-memory access, use the following syntax in HBase Shell:

  hbase> alter 'myTable', 'myCF', CONFIGURATION => {IN_MEMORY => 'true'}

  To use the Java API to configure a column family for in-memory access, use the HColumnDescriptor.setInMemory(true) method.

When you use the LruBlockCache, the blocks needed to satisfy each read are cached, evicting older cached objects if the LruBlockCache is full. The size cached objects for a given read may be significantly larger than the actual result of the read. For instance, if HBase needs to scan through 20 HFile blocks to return a 100 byte result, and the HFile blocksize is 100 KB, the read will add 20 * 100 KB to the LruBlockCache.

number of RegionServers * heap size * hfile.block.cache.size * 0.99

To tune the size of the LruBlockCache, you can add RegionServers to increase it, or you can tune hfile.block.cache.size to reduce it. Reducing it will cause cache evictions to happen more often.

The BucketCache stores cached objects in different "buckets", based upon the sizes of the objects. By default, the buckets are all the same size, controlled by the configuration property hfile.bucketcache.size. However, you can configure multiple bucket sizes if your data fits into different, predictable size categories, using the hfile.bucketcache.sizes property instead, which takes a comma-separated list of sizes as its value. Evictions are managed independently per bucket.