[
https://issues.apache.org/jira/browse/HBASE-11425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14355478#comment-14355478
]
Vladimir Rodionov commented on HBASE-11425:
-------------------------------------------
{quote}
The change is when the data is cached in the non compressed form (But can be in
the DBE form)
{quote}
[~anoop.hbase], if the goal of this JIRA performance improvement, have you
estimate the following scenarios:
# DBE - ON, block compression - OFF (byte array end-to-end - BA)
# DBE - OFF, block compression - OFF (BA)
# DBE - ON, block compression - ON (BA)
# DBE - OFF, block compression - ON (BA)
# DBE - ON, block compression - OFF (byte buffer end-to-end - BB)
# DBE - OFF, block compression - OFF (BB)
# DBE - ON, block compression - ON (BB)
# DBE - OFF, block compression - ON (BB)
You optimize No 5 use case only. Do you think its going to be faster than any
of first four (BA)? People like compression, especially if it does not affect
benchmark performance too much and helps them with their application.
Essentially, you advise users not to use compression and use only DBE, but all
scan operations and get/multi get take performance hit with DBE enabled. I
think No. 4 (DBE - OFF, block compression ON, byte array backed) is going to be
faster than No. 5 (DBE - ON, block compression OFF , byte buffer - backed) in
any benchmark.
These are my words of caution ... before you start such a large project - make
sure that benefits you are hoping for are really possible.
> Cell/DBB end-to-end on the read-path
> ------------------------------------
>
> Key: HBASE-11425
> URL: https://issues.apache.org/jira/browse/HBASE-11425
> Project: HBase
> Issue Type: Umbrella
> Components: regionserver, Scanners
> Affects Versions: 0.99.0
> Reporter: Anoop Sam John
> Assignee: Anoop Sam John
> Attachments: Offheap reads in HBase using BBs_final.pdf
>
>
> Umbrella jira to make sure we can have blocks cached in offheap backed cache.
> In the entire read path, we can refer to this offheap buffer and avoid onheap
> copying.
> The high level items I can identify as of now are
> 1. Avoid the array() call on BB in read path.. (This is there in many
> classes. We can handle class by class)
> 2. Support Buffer based getter APIs in cell. In read path we will create a
> new Cell with backed by BB. Will need in CellComparator, Filter (like SCVF),
> CPs etc.
> 3. Avoid KeyValue.ensureKeyValue() calls in read path - This make byte copy.
> 4. Remove all CP hooks (which are already deprecated) which deal with KVs.
> (In read path)
> Will add subtasks under this.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
