hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Phabricator (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-4218) Delta Encoding of KeyValues (aka prefix compression)
Date Tue, 29 Nov 2011 20:39:40 GMT

    [ https://issues.apache.org/jira/browse/HBASE-4218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13159531#comment-13159531
] 

Phabricator commented on HBASE-4218:
------------------------------------

todd has commented on the revision "[jira] [HBASE-4218] Delta encoding for keys in HFile".

  I only got through a little bit of the giant patch, but it looks well done and decently
unit-tested, so I'm +1 once you have some cluster testing results that show it basically works
:)

  Test-plan should include an upgrade test from an unpatched HFile v2 format and an HFile
v1 (0.90) upgrade

INLINE COMMENTS
  src/main/java/org/apache/hadoop/hbase/HColumnDescriptor.java:99 seems odd that the type
of this is boolean whereas the IN_CACHE one is an Algorithm type. If it's a requirement that
the algo be the same, then maybe rename this one to be DEFAULT_DELTA_ENCODING_IN_MEMORY_ENABLED
  src/main/java/org/apache/hadoop/hbase/KeyValue.java:2022 This interface name isn't quite
clear to me, since it doesn't compare prefixes. Maybe SuffixComparator? Or ComparatorAssumingEqualPrefix
(though that's a bit lengthy)?
  src/main/java/org/apache/hadoop/hbase/io/deltaencoder/BitsetKeyDeltaEncoder.java:34-42 should
use inline HTML to format this right
  src/main/java/org/apache/hadoop/hbase/io/deltaencoder/BitsetKeyDeltaEncoder.java:56 s/writeHere/out/g
for consistent style
  src/main/java/org/apache/hadoop/hbase/io/deltaencoder/BitsetKeyDeltaEncoder.java:69 s/source/in/g
  src/main/java/org/apache/hadoop/hbase/io/deltaencoder/DeltaEncoder.java:32-35 use HTML <ul>...
  src/main/java/org/apache/hadoop/hbase/io/hfile/AbstractHFileWriter.java:90 typo
  src/main/java/org/apache/hadoop/hbase/io/hfile/EmptyBlockDeltaEncoder.java:29 maybe "NoOpDeltaEncoder"
is a better name? (it's not that the block is empty)

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: D447.1.patch, D447.2.patch, D447.3.patch, D447.4.patch, D447.5.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

        

Mime
View raw message