hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From lars hofhansl <la...@apache.org>
Subject Re: [DISCUSSION] "Convenience binaries" bundling Phoenix
Date Wed, 18 Mar 2015 21:32:14 GMT
Again... 'bit late chiming in.

I'd be +1 on this. We'd essentially just ship HBase with an extra shell.I don't think Phoenix
can do this, because it does not usually ship the bits needed to run HBase, but just the bits
to add to HBase to have Phoenix.Phoenix should not be in the business to maintain an HBase
distribution.
One could argue that we should not be in the business to maintain a Phoenix distribution.
But we wouldn't really. We'd just add the Phoenix jar to our binary distro, pre-hook the coprocessors,
and add the SQLLine, and psql.On the HBase side I'd suggest we'd add a script to dev-support
to package up the HBase+Phoenix distro, and maybe we add a new target to the pom to pull a
Phoenix version.

What exactly we'd ship should be discussed (all the Phoenix tools, or just some?) Giving HBase
a nice SQL shell seems cool to me, and that's were some more of the more hairy issues might
be found.

-- Lars

      From: Andrew Purtell <apurtell@apache.org>
 To: "dev@hbase.apache.org" <dev@hbase.apache.org> 
 Sent: Tuesday, March 17, 2015 12:44 PM
 Subject: [DISCUSSION] "Convenience binaries" bundling Phoenix
   
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)


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