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.