hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "stack (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-13387) Add ServerCell an extension to Cell
Date Wed, 08 Apr 2015 21:48:12 GMT

    [ https://issues.apache.org/jira/browse/HBASE-13387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14486132#comment-14486132

stack commented on HBASE-13387:

bq. Also Cells added to Memstore and getting returned in Scan time

These won't be offheap or BB backed, right? So why type conversion needed?

bq. That is not an interface contract but an impl detail.

That the Cell is backed by an offheap BB should really be an implementation detail too.

Highlevel, a particular Cell implementation wants to change the read path implementation so
read path can deal when a basic presumption that no longer holds; i.e. that Cells are NOT
backed by byte array. The difficulty with this patch and the DBB/Cell effort is that it sprinkles
if/else throughout the code base reimplementing basics -- compares mostly but also retrofitting
into basic types off-heap APIs where there were none before -- so they will work also against
offheap BBs. Ideally, at a high-level (does it have to be at the regionserver level since
read path spans block read to rpc?), a switch would be thrown, and a factory would emit an
appropriate Cell type AND any read path classes such as comparators. Ideally the number of
classes and the loci where we need to be cognizant of difference will be few (two? The Cell
type and its comparators) and narrow. Is such an ideal possible lads?

bq. So what you say is keep the type of cell passing in read path as Cell itself...

We could have the switch at every compare nexus or would it be possible to do the switch at
a high-level once as suggested above.

bq. Pls note that, the getXXXArray APIs will throw Exception in case of buffer backed Cells.
So writers of Filter/CP has to do the instance of check always. 

Yeah, we want that. The filter is using raw APIs and needs to be insulated better from our
internals -- go via utils or get a comparator from a factory. Or we do as you suggest above
and we don't throw exception but do the performance-killing copy until the filter gets changed.

bq. ...can we have separate getXXXOffset() methods for getting offset in buffer?

Please say more on above.


> 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_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

View raw message