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. St.Ack On Tue, Mar 17, 2015 at 12:44 PM, Andrew Purtell <apurt...@apache.org> wrote: > 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) >
