hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ramkrishna.s.vasudevan (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-10801) Ensure DBE interfaces can work with Cell
Date Mon, 21 Apr 2014 04:45:18 GMT

    [ 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)

Mime
View raw message