[
https://issues.apache.org/jira/browse/HBASE-4218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13179349#comment-13179349
]
Mikhail Bautin commented on HBASE-4218:
---------------------------------------
A brief status update. I am in the process of implementing support for column
family data block encoding configuration changes. Those changes are coming in
the next version of the patch that I will post tomorrow. After discussing this
with Kannan, our solution is:
* Assign an in-cache data block encoding to every HFile reader. This in-cache
encoding is determined as follows:
** If the HFile is not encoded on disk, the in-cache encoding is set to the
column family's DATA_BLOCK_ENCODING.
** If the HFile is encoded on disk, the in-cache encoding is set to the HFile
encoding to avoid the wasted effort of re-encoding blocks for cache.
* When a non-encoded block is loaded from disk, it is encoded using the
in-cache encoding and put in cache.
* When an encoded block is loaded from disk, its encoding is left as is.
* To reduce the complexity of data block encoding switching, we can include the
in-cache encoding type in the block cache key. For example, if
ENCODED_IN_CACHE_ONLY is turned on without encoding on disk, and then the
encoding is turned off altogether, the cache will be populated with non-encoded
blocks (since they will have completely different keys) and encoded blocks will
age out from the cache. While this is suboptimal, the implementation is very
simple and the common case (when the CF encoding options do not change) is not
complicated with unnecessary corner cases.
> Data Block Encoding of KeyValues (aka delta encoding / prefix compression)
> ---------------------------------------------------------------------------
>
> Key: HBASE-4218
> URL: https://issues.apache.org/jira/browse/HBASE-4218
> Project: HBase
> Issue Type: Improvement
> Components: io
> Affects Versions: 0.94.0
> Reporter: Jacek Migdal
> Assignee: Mikhail Bautin
> Labels: compression
> Fix For: 0.94.0
>
> Attachments: 0001-Delta-encoding-fixed-encoded-scanners.patch,
> 0001-Delta-encoding.patch, 4218-v16.txt, 4218.txt, D447.1.patch,
> D447.10.patch, D447.11.patch, D447.12.patch, D447.13.patch, D447.14.patch,
> D447.15.patch, D447.16.patch, D447.17.patch, D447.2.patch, D447.3.patch,
> D447.4.patch, D447.5.patch, D447.6.patch, D447.7.patch, D447.8.patch,
> D447.9.patch, Data-block-encoding-2011-12-23.patch,
> Delta-encoding.patch-2011-12-22_11_52_07.patch,
> Delta_encoding_with_memstore_TS.patch, open-source.diff
>
>
> A compression for keys. Keys are sorted in HFile and they are usually very
> similar. Because of that, it is possible to design better compression than
> general purpose algorithms,
> It is an additional step designed to be used in memory. It aims to save
> memory in cache as well as speeding seeks within HFileBlocks. It should
> improve performance a lot, if key lengths are larger than value lengths. For
> example, it makes a lot of sense to use it when value is a counter.
> Initial tests on real data (key length = ~ 90 bytes , value length = 8 bytes)
> shows that I could achieve decent level of compression:
> key compression ratio: 92%
> total compression ratio: 85%
> LZO on the same data: 85%
> LZO after delta encoding: 91%
> While having much better performance (20-80% faster decompression ratio than
> LZO). Moreover, it should allow far more efficient seeking which should
> improve performance a bit.
> It seems that a simple compression algorithms are good enough. Most of the
> savings are due to prefix compression, int128 encoding, timestamp diffs and
> bitfields to avoid duplication. That way, comparisons of compressed data can
> be much faster than a byte comparator (thanks to prefix compression and
> bitfields).
> In order to implement it in HBase two important changes in design will be
> needed:
> -solidify interface to HFileBlock / HFileReader Scanner to provide seeking
> and iterating; access to uncompressed buffer in HFileBlock will have bad
> performance
> -extend comparators to support comparison assuming that N first bytes are
> equal (or some fields are equal)
> Link to a discussion about something similar:
> http://search-hadoop.com/m/5aqGXJEnaD1/hbase+windows&subj=Re+prefix+compression
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
