hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Taylor <jtay...@salesforce.com>
Subject Re: On coprocessor API evolution
Date Sun, 18 May 2014 18:50:31 GMT
Phoenix doesn't actually do anything particularly fancy with the
RegionServer interface. We typically just run the scan internally and
return a different scanner (over the aggregated or topN results).

We'd be happy to act as the "guinea pig" for this new, simpler coprocessor
API.

Thanks,
James


On Sun, May 18, 2014 at 12:41 AM, Andrew Purtell <apurtell@apache.org>wrote:

> That's a good point. We have use cases for the current APIs (security,
> Phoenix) but no motivating use case for HBASE-11125 yet. I would be better
> if we had one lined up.
>
>
> On Sunday, May 18, 2014, lars hofhansl <larsh@apache.org> wrote:
>
> > But note that such a high level interface will probably not allow access
> > at level necessary for Phoenix.
> > You can't eat your cake and keep it. For some performance you deep access
> > to HBase internals (RegionScanners, for example). At the same time, these
> > *are* internal.
> >
> >
> > I suppose to least we can do is marking these interfaces/classes clearly
> > (as we have started in 0.96 and later as being public/private/evolving,
> > etc).
> >
> > There's a use case for HBASE-11125, but to me at least it does not seem
> to
> > be Phoenix. But maybe I am wrong.
> >
> >
> > -- Lars
> >
> >
> >
> > ________________________________
> >  From: James Taylor <jtaylor@salesforce.com <javascript:;>>
> > To: "dev@hbase.apache.org <javascript:;>" <dev@hbase.apache.org
> <javascript:;>
> > >
> > Sent: Thursday, May 15, 2014 6:47 PM
> > Subject: Re: On coprocessor API evolution
> >
> >
> > +1 to HBASE-11125. Current incarnation of coprocessors expose too much of
> > the guts of the implementation.
> >
> >
> >
> > On Wed, May 14, 2014 at 6:13 PM, Andrew Purtell <apurtell@apache.org
> <javascript:;>>
> > wrote:
> >
> > > Because coprocessor APIs are so tightly bound with internals, if we
> apply
> > > suggested rules like as mentioned on HBASE-11054:
> > >
> > >       I'd say policy should be no changes to method apis across minor
> > > versions
> > >
> > > This will lock coprocessor based components to the limitations of the
> API
> > > as we encounter them. Core code does not suffer this limitation, we are
> > > otherwise free to refactor and change internal methods. For example, if
> > we
> > > apply this policy to the 0.98 branch, then we will have to abandon
> > further
> > > security feature development there and move to trunk only. This is
> > because
> > > we already are aware that coprocessor APIs as they stand are
> insufficient
> > > still.
> > >
> > > Coprocessor APIs are a special class of internal method. We have had a
> > > tension between allowing freedom of movement for developing them out
> and
> > > providing some measure of stability for implementors for a while.
> > >
> > > It is my belief that the way forward is something like HBASE-11125.
> > Perhaps
> > > we can take this discussion to that JIRA and have this long overdue
> > > conversation.
> > >
> > > Regarding security features specifically, I would also like to call
> your
> > > attention to HBASE-11127. I think security has been an optional feature
> > > long enough, it is becoming a core requirement for the project, so
> should
> > > be moved into core. Sure, we can therefore sidestep any issues with
> > > coprocessor API sufficiency for hosting security features. However, in
> my
> > > opinion we should pursue both HBASE-11125 and HBASE-11127; the first to
> > > provide the relative stability long asked for by coprocessor API users,
> > the
> > > latter to cleanly solve emerging issues with concurrency and
> versioning.
> > >
> > >
> > > --
> > > Best regards,
> > >
> > >    - Andy
> > >
> > > Problems worthy of attack prove their worth by hitting back. - Piet
> Hein
> > > (via Tom White)
> > >
>
>
>
> --
> Best regards,
>
>    - Andy
>
> Problems worthy of attack prove their worth by hitting back. - Piet Hein
> (via Tom White)
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message