hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "He Yongqiang (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-5313) Restructure hfiles layout for better compression
Date Mon, 13 Feb 2012 18:56:59 GMT

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

He Yongqiang commented on HBASE-5313:
-------------------------------------

bq. However, those compression numbers are pretty nice. I worry a little bit about having
now an hfileV3, so soon on the heels of the last, leading to a proliferation of versions.
My other concern is that the columnar storage doesn't make sense for all cases - Dremel is
for a specific use case.
That being said, I would love to see the ability to do Dremel in HBase. How about along with
a new version/columnar data support comes the ability to select storage files on a per-table
basis? That would enable some tables to be optimized for certain use cases, other tables for
others, rather than having to use completely different clusters (continuing the multi-tenancy
story).

@Jesse Yates, Yeah. Agree here. One big thing we need to answer is how to integrate with current
HFile implementation. We want to reuse code as much as possible. I guess a nested columnar
structure like Dremel is what we finally want for HBase. But we first need to figure out a
good story of how applications will use it.


                
> Restructure hfiles layout for better compression
> ------------------------------------------------
>
>                 Key: HBASE-5313
>                 URL: https://issues.apache.org/jira/browse/HBASE-5313
>             Project: HBase
>          Issue Type: Improvement
>          Components: io
>            Reporter: dhruba borthakur
>            Assignee: dhruba borthakur
>
> A HFile block contain a stream of key-values. Can we can organize these kvs on the disk
in a better way so that we get much greater compression ratios?
> One option (thanks Prakash) is to store all the keys in the beginning of the block (let's
call this the key-section) and then store all their corresponding values towards the end of
the block. This will allow us to not-even decompress the values when we are scanning and skipping
over rows in the block.
> Any other ideas? 

--
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

        

Mime
View raw message