Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Date: Tue, 29 Nov 2011 17:39:41 +0000 (UTC)
From: "Phabricator (Commented) (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Message-ID: 
 <766685839.22476.1322588381042.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <657671452.46177.1313609127186.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Commented] (HBASE-4218) Delta Encoding of KeyValues  (aka
 prefix compression)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

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

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

  Nice work, Mikhail and Jacek.

  Please add category to the new tests.

  Are there performance numbers for various encoders other than Prefix encoder ?

INLINE COMMENTS
  src/main/java/org/apache/hadoop/hbase/io/hfile/HFileReaderV1.java:337 As Matt pointed out, the return value should be stored in hfileBlock so that we don't incur double encoding.
  src/main/java/org/apache/hadoop/hbase/io/hfile/HFileReaderV2.java:305 Similar to the case in HFileReaderV1, return value should be stored in dataBlock.
  src/main/java/org/apache/hadoop/hbase/io/deltaencoder/DeltaEncoderAlgorithms.java:33 Matt suggested alternative names for DeltaEncoding:
  KeyValueEncoding, DataBlockEncoding, HCellEncoding, BlockEncoding.

  DataBlockEncoding sounds good.
  src/main/java/org/apache/hadoop/hbase/io/deltaencoder/DiffKeyDeltaEncoder.java:405 Misspelling: comperator should be comparator.
  src/main/java/org/apache/hadoop/hbase/io/deltaencoder/DeltaEncoderAlgorithms.java:65 Javadoc doesn't match actual class name.
  src/main/java/org/apache/hadoop/hbase/io/deltaencoder/FastDiffDeltaEncoder.java:53 The tail should read '128 bit encoding'
  src/main/java/org/apache/hadoop/hbase/io/deltaencoder/FastDiffDeltaEncoder.java:28 This class is only used locally. It should be an inner class.
  src/main/java/org/apache/hadoop/hbase/io/deltaencoder/DiffKeyDeltaEncoder.java:49 Tail should read '128 bit encoding'
  src/main/java/org/apache/hadoop/hbase/io/deltaencoder/DiffKeyDeltaEncoder.java:346 Please remove extra blank line.
  src/main/java/org/apache/hadoop/hbase/io/deltaencoder/DiffKeyDeltaEncoder.java:28 Please change this class to inner class.
  src/main/java/org/apache/hadoop/hbase/io/deltaencoder/DeltaEncoderBufferTooSmallException.java:22 Should read 'which indicates'

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