[
https://issues.apache.org/jira/browse/HBASE-12358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14214337#comment-14214337
]
ramkrishna.s.vasudevan commented on HBASE-12358:
------------------------------------------------
bq.Can you say more why you found this ramkrishna.s.vasudevan?
Pls refer to this comment from Anoop
bq.No I am wrong. Constructors in ByteBuffer is not public !
So when we want to have multiple BBs forming a HFileBlock then we cannot extend
BB to create a MultiBB and hence we thought we need our own way Class to
represent the BBs. So BR would be an option for that and for now BR would have
a BB inside it and that BB could be onheap/offheap. This is going to cause
additional redirection but we need to measure the performance before we have
our own impl of BR.
bq.You mean a getFamilyArray would have a companion getFamilyBuffer, and so on?
What would the getFamilyBuffer return?
Yes we would have a companion. If Cell says hasArray() as false but we try
using getFamilyArray then we would copy the buffer to an array and then return
it. (costly). The reverse one where hasArray is true ( assume a Kv), now we
would wrap the byte[] in a BR object and send it. (multiple short lived objects
would be created here).
Hence the use of hasArray is very important. Users should be using this APIs
prudently to decide which API to use.
If we need to avoid this we need to introduce a new Cell type which does not
extend Cell and use it in the read path. Then user has to rewrite his code
based on that new Cell but it will not have this getXXxArray and getXXXBuffer
confusion.
bq.Doing comparisons when the bytes are off heap, how would that work?
No problem. Since we would return only the BRs here we would create a BBBacked
BR and that could be offheap or onheap. All the util methods that we add would
check if this BB inside BR is onheap/offheap and based on that the comparisons
would work. This works even now in our POC.
bq.We'd have to do this even if Cell was BR backed?
Yes or we should totally have a new Cell impl (that does not extend Cell). A
total incompatible change.
bq.We want to have a single Interface that can be pasesd through the read-path
and then do different implementations? It'd be interesting if we couldn't
figure one that works for on-heap/off-heap.
We can do this the only thing is how we use the Cell interface. The
representation of on heap and offheap would go into that Cell's impl and rest
of the code would not bother about it.
> Create ByteBuffer backed Cell
> -----------------------------
>
> Key: HBASE-12358
> URL: https://issues.apache.org/jira/browse/HBASE-12358
> Project: HBase
> Issue Type: Sub-task
> Components: regionserver, Scanners
> Reporter: ramkrishna.s.vasudevan
> Assignee: ramkrishna.s.vasudevan
> Attachments: HBASE-12358.patch, HBASE-12358_1.patch,
> HBASE-12358_2.patch
>
>
> As part of HBASE-12224 and HBASE-12282 we wanted a Cell that is backed by BB.
> Changing the core Cell impl would not be needed as it is used in server
> only. So we will create a BB backed Cell and use it in the Server side read
> path. This JIRA just creates an interface that extends Cell and adds the
> needed API.
> The getTimeStamp and getTypebyte() can still refer to the original Cell API
> only. The getXXxOffset() and getXXXLength() can also refer to the original
> Cell only.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
