hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Otis Gospodnetic <otis_gospodne...@yahoo.com>
Subject Re: LZ4 compression support
Date Thu, 17 May 2012 06:02:07 GMT
Yeah, saw that...
Was just wondering why Vladimir thinks HBase users won't see any perf. improvements and whether
Laxman has the numbers from benchmarking he referred to.

Otis 
----
Performance Monitoring for Solr / ElasticSearch / HBase - http://sematext.com/spm 



>________________________________
> From: Andrew Purtell <andrew.purtell@gmail.com>
>To: "dev@hbase.apache.org" <dev@hbase.apache.org> 
>Cc: "dev@hbase.apache.org" <dev@hbase.apache.org>; "lakshman.ch@huawei.com" <lakshman.ch@huawei.com>;
Vladimir Rodionov <vrodionov@carrieriq.com> 
>Sent: Thursday, May 17, 2012 1:49 AM
>Subject: Re: LZ4 compression support
> 
>It's on the to do list: https://issues.apache.org/jira/browse/HBASE-5838
>
>On May 16, 2012, at 8:17 PM, Otis Gospodnetic <otis_gospodnetic@yahoo.com> wrote:
>
>> Hi,
>> (almost 3 months old thread)
>> 
>> LZ4 perf test numbers in https://issues.apache.org/jira/browse/HADOOP-7657?focusedCommentId=13170733&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13170733
looks pretty impressive.  Why do you think HBase users would not see perf difference in HBase? 
We saw it when we moved from LZO to Snappy.
>> 
>> Laxman, did you end up testing LZ4 with HBase?  Would it be possible for you to
share the results?
>> 
>> Thanks,
>> Otis 
>> ----
>> Performance Monitoring for Solr / ElasticSearch / HBase - http://sematext.com/spm

>> 
>> 
>> 
>> 
>>> ________________________________
>>> From: Vladimir Rodionov <vrodionov@carrieriq.com>
>>> To: "dev@hbase.apache.org" <dev@hbase.apache.org>; "lakshman.ch@huawei.com"
<lakshman.ch@huawei.com>; 'Stack' <stack@duboce.net> 
>>> Sent: Tuesday, February 28, 2012 1:20 PM
>>> Subject: RE: LZ4 compression support
>>> 
>>> LZ4 is slightly faster than snappy (from my own tests) but I really doubt that
anyone will see performance difference in HBase
>>> (or in Hadoop)
>>> 
>>> Best regards,
>>> Vladimir Rodionov
>>> Principal Platform Engineer
>>> Carrier IQ, www.carrieriq.com
>>> e-mail: vrodionov@carrieriq.com
>>> 
>>> ________________________________________
>>> From: Laxman [lakshman.ch@huawei.com]
>>> Sent: Tuesday, February 28, 2012 7:17 AM
>>> To: 'Stack'; dev@hbase.apache.org
>>> Subject: RE: LZ4 compression support
>>> 
>>> Hi Stack,
>>> 
>>> I haven't tried LZ4 in Hadoop. Currently, I'm directly testing LZ4 with
>>> HBase.
>>> Will publish my findings soon.
>>> 
>>> --
>>> Regards,
>>> Laxman
>>> 
>>>> -----Original Message-----
>>>> From: saint.ack@gmail.com [mailto:saint.ack@gmail.com] On Behalf Of
>>>> Stack
>>>> Sent: Monday, February 27, 2012 11:33 PM
>>>> To: dev@hbase.apache.org; lakshman.ch@huawei.com
>>>> Subject: Re: LZ4 compression support
>>>> 
>>>> On Mon, Feb 27, 2012 at 6:59 AM, Laxman <lakshman.ch@huawei.com> wrote:
>>>>> Hi,
>>>>> 
>>>>> Some more compression algorithms are supported in Hadoop.
>>>>> 
>>>>> IMO, if not all, we can add support for few faster algorithms (Like
>>>> LZ4) in
>>>>> HBase also to take the advantage of its speed.
>>>>> https://issues.apache.org/jira/browse/HADOOP-7657
>>>>> 
>>>> 
>>>> What would you suggest Laxman?  Have you tried hbase against hadoop
>>>> 0.23.1 using LZ4?  Or are you thinking of pulling it into hbase?
>>>> St.Ack
>>> 
>>> 
>>> Confidentiality Notice:  The information contained in this message, including
any attachments hereto, may be confidential and is intended to be read only by the individual
or entity to whom this message is addressed. If the reader of this message is not the intended
recipient or an agent or designee of the intended recipient, please note that any review,
use, disclosure or distribution of this message or its attachments, in any form, is strictly
prohibited.  If you have received this message in error, please immediately notify the sender
and/or Notifications@carrieriq.com and delete or destroy any copy of this message and its
attachments.
>>> 
>>> 
>
>
>
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message