hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stack <st...@duboce.net>
Subject Re: [DISCUSSION] "Convenience binaries" bundling Phoenix
Date Wed, 18 Mar 2015 18:11:20 GMT
My first reaction is that the convenience binaries better belong in phoenix
than here.

I would not be against an RM doing such convenience binaries but the RM job
is already broad and I would see most passing on this extra task not having
enough time to make a good job of it.


On Tue, Mar 17, 2015 at 12:44 PM, Andrew Purtell <apurtell@apache.org>

> Consider if the HBase project starts releasing new "convenience binaries",
> in addition to the existing ones, in which we bundle a recent/vetted/stable
> version of Phoenix, with the site file changes for loading their
> coprocessors already patched in (to hbase-default.xml) For now this would
> be done for 0.98 only, since that's the only release line supported by an
> actively developed Phoenix version. We could also do this for 0.94 releases
> with Phoenix 3 if the 0.94 RM wants, but I doubt there would be any demand
> for this, Phoenix 3 is inactive because that community has all moved to 4,
> I'd imagine that carries over here.
> Advantages:
> - HBase would ship with a SQL access option. There's the Phoenix JDBC
> driver of course, and we'd also bundle the psql and sqlline exec wrappers
> from the Phoenix binary distribution. We'd have both the jruby shell and a
> SQL shell, this is a powerful combination.
> - HBase ships with a library that assists users in making efficient queries
> if their data is typed, but this doesn't include the server side
> optimizations that the Phoenix coprocessors provide, and in that case no
> hand rolling is necessary.
> - HBase would ship with secondary indexes. These would not cover all
> possible use cases and requirements, let's stipulate that now and hope this
> doesn't kick off another circular discussion on that front. Unquestionably
> this is a compelling Phoenix feature so some use cases obviously can
> benefit, and if users find the combined distribution useful enough we don't
> have to discuss secondary indexes in HBase core again.
> - We will have done the necessary integration work for the combined result
> to be easy to use. Apache software cat herders will appreciate this.
> - It's totally optional, simply ignore the new binary packages if you don't
> care. This is not a Grand Unification proposal.
> Concerns:
> - More work for the RM. Unquestionably.
> - Concerns about the quality of the combined convenience artifact: Is there
> an implied warranty? Could we disclaim? Should we disclaim? If not, how
> does HBase do QA on this. Related to the above concern about RM bandwidth.
> Maybe Phoenix could help.
> - Increased coupling between the projects. Frankly, I think this already
> there, we just don't see it until we trip over issues that could have been
> avoided with more communication between projects. Pushing on Phoenix for
> bits for a monthly HBase release cadence will surface issues faster and
> improve communication between the projects. This benefits Phoenix with more
> QA bandwidth. This benefits HBase because we see Phoenix bringing in a
> significant number of users.
> - We may want to revisit again normalizing type support in HBase's client
> library and Phoenix, eventually.
> I could add more items to the advantage or concern lists but mainly want to
> float the idea for feedback at this time.
> Thoughts?
> --
> Best regards,
>    - Andy
> Problems worthy of attack prove their worth by hitting back. - Piet Hein
> (via Tom White)

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