[
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
