[ https://issues.apache.org/jira/browse/HBASE-16213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15426127#comment-15426127 ]
ramkrishna.s.vasudevan commented on HBASE-16213: ------------------------------------------------ I verfied the updated patch and the comments seems to be fixed. I have not checked the logic of how the bytebuffers are traversed back and forth and I believe the test cases would have caught them. May be there are lot of garbage getting generated because of lot of slices and duplicates. I think that can be seen later if really it is a problem. As of now am fine with this patch. +1. > A new HFileBlock structure for fast random get > ---------------------------------------------- > > Key: HBASE-16213 > URL: https://issues.apache.org/jira/browse/HBASE-16213 > Project: HBase > Issue Type: New Feature > Components: Performance > Reporter: binlijin > Assignee: binlijin > Attachments: HBASE-16213-master_v1.patch, HBASE-16213.patch, > HBASE-16213_branch1_v3.patch, HBASE-16213_v2.patch, hfile-cpu.png, > hfile_block_performance.pptx, hfile_block_performance2.pptx, > new-hfile-block.xlsx > > > HFileBlock store cells sequential, current when to get a row from the block, > it scan from the first cell until the row's cell. > The new structure store every row's start offset with data, so it can find > the exact row with binarySearch. > I use EncodedSeekPerformanceTest test the performance. > First use ycsb write 100w data, every row have only one qualifier, and > valueLength=16B/64/256B/1k. > Then use EncodedSeekPerformanceTest to test random read 1w or 100w row, and > also record HFileBlock's dataSize/dataWithMetaSize in the encoding. -- This message was sent by Atlassian JIRA (v6.3.4#6332)