[
https://issues.apache.org/jira/browse/HBASE-14832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15014070#comment-15014070
]
ramkrishna.s.vasudevan commented on HBASE-14832:
------------------------------------------------
bq.The patch will work though we've not converted PrefixTree? PrefixTree will
run really slow if it is doing copies all the time which will be a big surprise.
The read part there is no problem. Only when we try to write the Prefixtree
cell we need to ensure that we handle offheap cells also. Currently in
compaction case there will be a copy happening while writing back to the new
file.
bq.Ditto for TagCompression. It will work after the patch goes in, it'll just
be slow because of all the copies?
Again this is applicable only during writes (during compaction). Not during
reads.
bq.Can you explain this more or point to a place in the code that shows what
you are seeing?
My point was that when DBEs are enabled then the cell that we get to write
during compaction will be a DBE cell ie the decoded cell based on the DBE algo
and that will be written back after encoding into the new file.
In our current trunk, these DBE decoded cells are of two types (onheap DBE cell
and offheap DBE cell). In the offheap cell only the value part is referring to
the offheap hfileblock coming out of the bucket cache. All other components are
onheap byte[] only since the need to be decoded.
bq.Was ByteRange an experiment that now should be purged from the code base? I
see it used by PrefixTree. Is that the only place that uses it? I see support
in MemStore. Should we undo it? If deprecated, should we tidy it up some
I think PrefixTree needs it when the cells are KV based. Will check once if we
can purge it.
> Ensure write paths work with ByteBufferedCells in case of compaction
> --------------------------------------------------------------------
>
> Key: HBASE-14832
> URL: https://issues.apache.org/jira/browse/HBASE-14832
> Project: HBase
> Issue Type: Sub-task
> Components: regionserver, Scanners
> Affects Versions: 2.0.0
> Reporter: ramkrishna.s.vasudevan
> Assignee: ramkrishna.s.vasudevan
> Priority: Minor
> Fix For: 2.0.0
>
> Attachments: HBASE-14832.patch
>
>
> Currently any cell coming out of offheap Bucketcache while compaction does a
> copy using the getXXXArray() API since write path does not work with BBCells.
> This JIRA is aimed at changing the write path to support BBCells so that this
> copy is avoided.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
