[
https://issues.apache.org/jira/browse/HBASE-61?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack updated HBASE-61:
-----------------------
Attachment: hfile2.patch
More stripping. This patch has HFile sort of working again (Its a hackup with
ugly byte array copies that we need to remove). I was able to do some basic
performance comparisons. If buffer size is 4k, then I can random access 10 byte
cells as fast a MapFile. If cells are bigger, HFile outperforms MapFile; e.g.
if cell is 100 bytes, HFile is 2x MapFile (These are extremely coarse tests
going against local filesystem).
Need to do more stripping. In particular implement Ryan Rawson idea of carrying
HFile block in an nio ByteBuffer giving out new ByteBuffer 'views' when a key
or value is asked for rather than copy byte arrays.
> [hbase] Create an HBase-specific MapFile implementation
> -------------------------------------------------------
>
> Key: HBASE-61
> URL: https://issues.apache.org/jira/browse/HBASE-61
> Project: Hadoop HBase
> Issue Type: Improvement
> Components: io
> Reporter: Bryan Duxbury
> Assignee: stack
> Priority: Minor
> Fix For: 0.20.0
>
> Attachments: cpucalltreetfile.html, hfile.patch, hfile2.patch,
> longestkey.patch, tfile.patch, tfile3.patch
>
>
> Today, HBase uses the Hadoop MapFile class to store data persistently to
> disk. This is convenient, as it's already done (and maintained by other
> people :). However, it's beginning to look like there might be possible
> performance benefits to be had from doing an HBase-specific implementation of
> MapFile that incorporated some precise features.
> This issue should serve as a place to track discussion about what features
> might be included in such an implementation.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
