[
https://issues.apache.org/jira/browse/HBASE-13387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14487770#comment-14487770
]
Anoop Sam John commented on HBASE-13387:
----------------------------------------
{quote}
This will change, right, because it is byte array based?
62 @Override
63 public boolean filterRowKey(Cell cell) throws IOException
{ 64 return filterRowKey(cell.getRowArray(), cell.getRowOffset(),
cell.getRowLength()); 65 }
{quote}
This is from FilterBase right? We fall back to old method in case a custom
Filter implemented the old one. (For BC). One thing to note is, as this calls
getRowArray() unconditionally, there can be bytes copy. We can see most of
our Filters wont impl this method. Still in read path, we will call this
method and which might cause perf issues.. So we will have to put a noop impl
in all Filter impls? (which dont impl filterRowKey()) Will have to do these
works in next version of patch.
bq.Lets see if static invocation is right thing to do. Later we may find that
ColumnPrefixFilter needs to use a factory to get appropriate Comparator.
As of now my plan to keep BufferedCell compares also into CellComparator not a
new Comparator. If new Comparator , then we will need some sort of config
based decision to turn offheap based reads ON.. Will come to this area later
Stack.
bq.Just a thought, could BufferedCell be under regionserver package?
As CellUtil needs it, we have to keep in hbase-common. But the package name can
change. I thought the same package name as Cell is better. wdyt?
bq.It should be ByteBufferedCell? I go to Cell for lengths? And since Cell has
getRowArray, here it should be getRowByteBuffer? getRowByteBufferPosition?
Ok can change the names.. ByteBuffer is what it is backed by. So more clear
name,
bq.Do we have to do this boolean for tags?
Which boolean? instance of? Oh yes I have checked row,fam, qual and value
parts.. Tags need some good ammount of clean up too. Will do.
bq.If present, we write them out, otherwise not?
If Cell is Streamable, it know how to write itself to an OS. Else we will get
each component and its lengths and write one component after the other. Cell
itself doing the oswrite (I call it stream method here) will be better wrt perf
adv. Less ops.
> Add ServerCell an extension to Cell
> -----------------------------------
>
> Key: HBASE-13387
> URL: https://issues.apache.org/jira/browse/HBASE-13387
> Project: HBase
> Issue Type: Sub-task
> Components: regionserver, Scanners
> Reporter: Anoop Sam John
> Assignee: Anoop Sam John
> Attachments: WIP_HBASE-13387_V2.patch, WIP_ServerCell.patch
>
>
> This came in btw the discussion abt the parent Jira and recently Stack added
> as a comment on the E2E patch on the parent Jira.
> The idea is to add a new Interface 'ServerCell' in which we can add new
> buffer based getter APIs, hasArray API etc. We will keep this interface
> @InterfaceAudience.Private
> Also we have to change the timestamp and seqId on Cells in server side. We
> have added new interfaces SettableSequenceId, SettableTimestamp for this. Now
> if we can add a ServerCell we can add the setter APIs there.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
