[
https://issues.apache.org/jira/browse/HBASE-4218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13168970#comment-13168970
]
Phabricator commented on HBASE-4218:
------------------------------------
mbautin has commented on the revision "[jira] [HBASE-4218] Delta encoding for
keys in HFile".
Addressing Michael's comments. A new version of the diff will follow. Running
unit tests.
INLINE COMMENTS
src/main/java/org/apache/hadoop/hbase/HColumnDescriptor.java:99 Renamed to
DEFAULT_DELTA_ENCODING_IN_MEMORY_ENABLED.
src/main/java/org/apache/hadoop/hbase/KeyValue.java:2022 How about
SamePrefixComparator? This means the same thing as the latter but is shorter.
src/main/java/org/apache/hadoop/hbase/io/deltaencoder/BitsetKeyDeltaEncoder.java:34-42
Done.
src/main/java/org/apache/hadoop/hbase/io/deltaencoder/BitsetKeyDeltaEncoder.java:56
Done.
src/main/java/org/apache/hadoop/hbase/io/deltaencoder/BitsetKeyDeltaEncoder.java:69
Done.
src/main/java/org/apache/hadoop/hbase/io/deltaencoder/DeltaEncoder.java:32-35
Done.
src/main/java/org/apache/hadoop/hbase/io/hfile/AbstractHFileWriter.java:90
Fixed.
src/main/java/org/apache/hadoop/hbase/KeyValue.java:2020 This extension to
the comparator interface is used in BufferedDeltaEncoder to improve performance
if the supplied comparator implements this interface. We don't need to compare
the first commonPrefix bytes of the two keys if we already know they are the
same.
src/main/java/org/apache/hadoop/hbase/KeyValue.java:2148 This is the same as
the old comparator code. We are assuming that the two KVs are valid.
src/main/java/org/apache/hadoop/hbase/KeyValue.java:2156 I've looked into
this and indeed saw some code duplication. I refactored the rest of this
function into a common one shared between the two comparators.
src/main/java/org/apache/hadoop/hbase/io/deltaencoder/BitsetKeyDeltaEncoder.java:89
I guess we might need to think about a bigger unified compression framework
for HFiles, HLogs, and RPC at some point.
REVISION DETAIL
https://reviews.facebook.net/D447
> Delta Encoding of KeyValues (aka 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
> Attachments: 0001-Delta-encoding-fixed-encoded-scanners.patch,
> D447.1.patch, D447.2.patch, D447.3.patch, D447.4.patch, D447.5.patch,
> D447.6.patch, D447.7.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
