anchor.diff:  
   In general, you need to weigh your options between smaller size and faster compression/decompression. Following are some general guidelines, expanded from a discussion at link:https://lists.apache.org/thread.html/481e67a61163efaaf4345510447a9244871a8d428244868345a155ff%401378926618%40%3Cdev.hbase.apache.org%3E[Documenting Guidance on compression and codecs].
   
  +* In most cases, enabling LZ4 or Snappy by default is a good choice, because they have a low
  +  performance overhead and provide reasonable space savings. A fast compression algorithm almost
  +  always improves overall system performance by trading some increased CPU usage for better I/O
  +  efficiency.
  +* If the values are large (and not pre-compressed, such as images), use a data block compressor.
  +* For [firstterm]_cold data_, which is accessed infrequently, depending on your use case, it might
  +  make sense to opt for Zstandard at its higher compression levels, or LZMA, especially for high
  +  entropy binary data, or Brotli for data similar in characteristics to web data. Bzip2 might also
  +  be a reasonable option but Zstandard is very likely to offer superior decompression speed.
  +* For [firstterm]_hot data_, which is accessed frequently, you almost certainly want only LZ4,
  +  Snappy, LZO, or Zstandard at a low compression level. These options will not provide as high of
  +  a compression ratio but will in trade not unduly impact system performance.
   * If you have long keys (compared to the values) or many columns, use a prefix encoder.
     FAST_DIFF is recommended.
  -* If the values are large (and not precompressed, such as images), use a data block compressor.
  -* Use GZIP for [firstterm]_cold data_, which is accessed infrequently.
  -  GZIP compression uses more CPU resources than Snappy or LZO, but provides a higher compression ratio.
  -* Use Snappy or LZO for [firstterm]_hot data_, which is accessed frequently.
  -  Snappy and LZO use fewer CPU resources than GZIP, but do not provide as high of a compression ratio.
  -* In most cases, enabling Snappy or LZO by default is a good choice, because they have a low performance overhead and provide space savings.
  -* Before Snappy became available by Google in 2011, LZO was the default.
  -  Snappy has similar qualities as LZO but has been shown to perform better.
  +* If enabling WAL value compression, consider LZ4 or SNAPPY compression, or Zstandard at
  +  level 1. Reading and writing the WAL is performance critical. That said, the I/O
  +  savings of these compression options can improve overall system performance.
   
   [[hadoop.native.lib]]
   === Making use of Hadoop Native Libraries in HBase
  
positive.code: To enable data block encoding for a ColumnFamily, see <<data.block.encoding.enable,data.block.encoding.enable>>.
  
  .Block Compressors
  * none
  * Snappy
  * LZO
  * LZ4
  * GZ
  
  .Data Block Encoding Types
  Prefix::
  
negative.code: .Changes Take Effect Upon Compaction
  If you change compression or encoding for a ColumnFamily, the changes take effect during compaction.
  
  Some codecs take advantage of capabilities built into Java, such as GZip compression.
  Others rely on native libraries. Native libraries may be available via codec dependencies installed into
  HBase's library directory, or, if you are utilizing Hadoop codecs, as part of Hadoop. Hadoop codecs
  typically have a native code component so follow instructions for installing Hadoop native binary
  support at <<hadoop.native.lib>>.
  
  This section discusses common codecs that are used and tested with HBase.
  
  No matter what codec you use, be sure to test that it is installed correctly and is available on all nodes in your cluster.
  Extra operational steps may be necessary to be sure that codecs are available on newly-deployed nodes.
  You can use the <<compression.test,compression.test>> utility to check that a given codec is correctly installed.
  