hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ted Yu <yuzhih...@gmail.com>
Subject Re: Beware of PREFIX_TREE block encoding
Date Sun, 20 Oct 2013 03:33:53 GMT

>From this graph (HBASE-4676), PREFIX_TREE block encoding is not sensitive
to variation in block size:

What was your block size ?
If you don't bypass StoreScanner/KeyValueHeap, would that make a difference


On Sat, Oct 19, 2013 at 7:34 PM, Vladimir Rodionov

> What I wanted to say by this? HBase still does not have block encoding
> which is optimal for both scan and seek (re-seek).
> I do not think these goals are mutually exclusive.
> Best regards,
> Vladimir Rodionov
> Principal Platform Engineer
> Carrier IQ, www.carrieriq.com
> e-mail: vrodionov@carrieriq.com
> ________________________________________
> From: Vladimir Rodionov [vladrodionov@gmail.com]
> Sent: Saturday, October 19, 2013 7:32 PM
> To: dev@hbase.apache.org
> Subject: Beware of PREFIX_TREE block encoding
> The scan performance is bad. 10 x slower on my tests than for blocks with
> NONE encoding. I scan data directly from block cache through
> StoreFileScanner (bypassing all StoreScanner/KeyValueHeap stuff). It should
> be clearly stated  that this encoding degrades overall performance
> significantly in favor of data size reduction and is suitable only for Gets
> - not for Scans.
> Best regards,
> -Vladimir Rodionov
> -
> 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.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message