[
https://issues.apache.org/jira/browse/HBASE-10801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13975385#comment-13975385
]
ramkrishna.s.vasudevan commented on HBASE-10801:
------------------------------------------------
bq.We use ByteBuffer instead of ByteRange? Thats ok?
ByteRange is also fine. But till we finalise on the APIs in BR, I thought
would work with BB only.
bq.Should these be throwing UnsupportedOperationException instead of a null
when we do these?
Ok we can change it.
bq.What is going on here in extractOffsetsAndLengthsFromKey?
First thing is, this goes exactly with the KV format because our current buffer
is strictly KV based.
bq.Why SeekerStateMembers at all and not just create a KeyValue over this buffer
This is not possible because the currentBuffer is currenlyl the buffer that has
encoded KVs (the value part is actually not encoded). So we decode the key part
and add it to a new buffer. To use the concept of Cell, the value need not be
copied. Hence I try to copy the key part alone and return as a Cell itself. So
here there are two different buffers so we cannot just wrap it as a KV.
bq.Why even take the value as arguments if we are not going to make use of it?
It needs to be. Because later while we do scan.next() we tend to save a
reference of the previous cell and then do next. So we have to clone the
members of the key buffer. Not doing so would end up changing the valuelength
and valueoffset references.
bq.(The external compressed tags flag comes from hfile?)
Yes.
Initial patch if you see was passing a SeekerState and referencing
seekerState.seekerStateMembers. But it was proving bit costly.
bq.It needs explaining in class comment.
Okie.
bq.Would SeekerStateCoordinates or SeekerStateLocation be a better name?
I could rename them. Was not able to get a convincing name.
bq.That this stuff doesn't make things worse – that after warm up, we are doing
maybe a bit better w/ the new code?
I was able to confirm that we are not performing worse for sure after this. I
could check with more tests. The whole impact is got only if we change the
code to use Cell in the read path otherwise the call to
KeyValueUtil.ensureKeyValue() would make things worse.
> Ensure DBE interfaces can work with Cell
> ----------------------------------------
>
> Key: HBASE-10801
> URL: https://issues.apache.org/jira/browse/HBASE-10801
> Project: HBase
> Issue Type: Sub-task
> Reporter: ramkrishna.s.vasudevan
> Assignee: ramkrishna.s.vasudevan
> Fix For: 0.99.0
>
> Attachments: HBASE-10801.patch, HBASE-10801_1.patch,
> HBASE-10801_2.patch, HBASE-10801_3.patch, HBASE-10801_4.patch
>
>
> Some changes to the interfaces may be needed for DBEs or may be the way it
> works currently may be need to be modified inorder to make DBEs work with
> Cells. Suggestions and ideas welcome.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
