[
https://issues.apache.org/jira/browse/HBASE-15477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15203782#comment-15203782
]
ramkrishna.s.vasudevan commented on HBASE-15477:
------------------------------------------------
bq.So we will NOT do "Do not save 'next block header' when we cache
hfileblocks"?
It is not like that. As per the patch in RB the serde part of HfileBlock will
not explicitly store the nextBlock header size. Instead already in the code
there is a next block prefetcher logic while reading the block from HDFS (not
from cache).
This logic is better to be retained which will come into play when we have some
scans that involves scanning from contiguous blocks. For 'gets' or scans that
skips blocks this optimization may not be useful.
If you see the code when the block comes from the cache we ideally don't make
use of this nextBlock info except for serde part. (correct me if am wrong
[[email protected]].
> Do not save 'next block header' when we cache hfileblocks
> ---------------------------------------------------------
>
> Key: HBASE-15477
> URL: https://issues.apache.org/jira/browse/HBASE-15477
> Project: HBase
> Issue Type: Sub-task
> Components: BlockCache, Performance
> Reporter: stack
> Assignee: stack
> Attachments: 15366v4.patch, 15477.patch, 15477v2.patch,
> 15477v3.patch, 15477v3.patch, 15477v4.patch
>
>
> When we read from HDFS, we overread to pick up the next blocks header.
> Doing this saves a seek as we move through the hfile; we save having to
> do an explicit seek just to read the block header every time we need to
> read the body. We used to read in the next header as part of the
> current blocks buffer. This buffer was then what got persisted to
> blockcache; so we were over-persisting wrtiting out our block plus the
> next blocks' header (overpersisting 33 bytes). Parse of HFileBlock
> complicated by this extra tail. Fix.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
