[
https://issues.apache.org/jira/browse/HBASE-16213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yu Li updated HBASE-16213:
--------------------------
Release Note:
HBASE-16213 introduced a new DataBlockEncoding in name of ROW_INDEX_V1, which
could improve random read (get) performance especially when the average record
size (key-value size per row) is small. To use this feature, please set
DATA_BLOCK_ENCODING to ROW_INDEX_V1 for CF of newly created table, or change
existing CF with below command:
alter 'table_name',{NAME => 'cf', DATA_BLOCK_ENCODING => 'ROW_INDEX_V1'}.
Please note that if we turn this DBE on, HFile block will be bigger than NONE
encoding because it adds some meta infos for binary search:
/**
* Store cells following every row's start offset, so we can binary search to a
row's cells.
*
* Format:
* flat cells
* integer: number of rows
* integer: row0's offset
* integer: row1's offset
* ....
* integer: dataSize
*
*/
was:
HBASE-16213 introduced a new DataBlockEncoding in name of ROW_INDEX_V1, which
could improve random read (get) performance especially when the average record
size (key-value size per row) is small. Use below command to enable this
feature:
alter 'table_name',{NAME => 'cf', DATA_BLOCK_ENCODING => 'ROW_INDEX_V1'}.
Please note that if we turn this DBE on, HFile block will be bigger than NONE
encoding because it adds some meta infos for binary search:
/**
* Store cells following every row's start offset, so we can binary search to a
row's cells.
*
* Format:
* flat cells
* integer: number of rows
* integer: row0's offset
* integer: row1's offset
* ....
* integer: dataSize
*
*/
> 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
> Fix For: 2.0.0, 1.4.0
>
> Attachments: HBASE-16213-master_v1.patch,
> HBASE-16213-master_v3.patch, HBASE-16213-master_v4.patch,
> HBASE-16213-master_v5.patch, HBASE-16213-master_v6.patch,
> HBASE-16213.branch-1.v1.patch, HBASE-16213.branch-1.v4.patch,
> HBASE-16213.branch-1.v4.patch, HBASE-16213.patch,
> HBASE-16213_branch1_v3.patch, HBASE-16213_v2.patch, hfile-cpu.png,
> hfile_block_performance.pptx, hfile_block_performance2.pptx,
> hfile_block_performance_E2E.pptx
>
>
> 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)
