You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hbase.apache.org by "stack (JIRA)" <ji...@apache.org> on 2009/01/17 19:56:59 UTC

[jira] Updated: (HBASE-1126) Enable choice of code; i.e. at a minimum enable LZO COMPRESSION support

     [ https://issues.apache.org/jira/browse/HBASE-1126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

stack updated HBASE-1126:
-------------------------

    Summary: Enable choice of code; i.e. at a minimum enable LZO COMPRESSION support  (was: LZO COMPRESSION support)

Broaden the issue to making it so users can choose codec.

Over in http://wiki.apache.org/hadoop/Hbase/PerformanceEvaluation#0_19_0, I tested the DefaultCodec (zlib, using native encoder/decoder) and found that random reads are horrid, writes just a bit slower and scans about the same.  I wonder how lzo would change this?  Perhaps scanning and writes would run as fast as non-compressed and random reads would come up close to non-compressed data?  I did notice that block compression made for less regions -- about half -- and this was with the PE data which does its best to foil good compression.

> Enable choice of code; i.e. at a minimum enable LZO COMPRESSION support
> -----------------------------------------------------------------------
>
>                 Key: HBASE-1126
>                 URL: https://issues.apache.org/jira/browse/HBASE-1126
>             Project: Hadoop HBase
>          Issue Type: New Feature
>         Environment: All
>            Reporter: Alex Newman
>
> It would be interesting to see the performance of lzo compressed Column Families Vs Normal ZlibBlock Compression. Based on some very preliminary performance profiling that I have done, as long as the cells are of reasonable size ( > 4k ), the zlib compression really dominates the overhead in random read/scanning situations.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.