Strong agree on your points here. You cover a lot of the intricacies
that I glossed over. Thank you for taking the time to write that all down.
I am happy to spin out the points I identified to dev@phoenix if you (or
others) think that they are all worthwhile discussions to have.
On 8/20/18 3:06 PM, Andrew Purtell wrote:
It would be helpful if someone could forward the relevant bits of Phoenix
discussion to the Phoenix dev list. One thing I know that project lacks is
usability feedback. I don't see anyone writing in with suggestions, mainly
complaining about it on a HBase list somewhere. Could just be I lack
perspective and those conversations are happening somewhere, but I am a
subscriber to all of the relevant lists and this is my observation. If a
correct observation, this is not really fair. I work somewhere that has
Phoenix in production. There is no doubt the attempt to implement RDBMS
functionality *inside* HBase as an add on component is a challenging
undertaking. However, any would be substitute I have seen to date either
doesn't actually attempt the same challenges, or takes a shortcut which
renders any comparison to the proverbial "apples and oranges". The tell
here is the notion of *lightweight* SQL access. Reads as a tremendous
limitation of scope. SQL is a huge standard incorporating 30+ years of
development in relational systems capabilities and semantics. We will get
into trouble if we ever attempt a "lightweight" SQL interface to HBase that
fails to match expectations which automatically attach to the effort
whenever you claim it to be a SQL interface. This is a cross the Phoenix
project already bears. If SQL support is really the goal it would be better
to assist there. Or, if the goal is the barest minimal SQL-like thing
someone needs to support their use case, and then contribute to HBase, call
it something else, like Cassandra did with CQL. Would be like the other
connectors - thrift, REST, Kafka, etc. - and should go into the connectors
repo, in my opinion.
On Sun, Aug 19, 2018 at 3:50 AM Stack <st...@duboce.net> wrote:
Next we went over backburner items mention on previous day staring with
SQL-like access.
What about lightweight SQL support?
At Huawei... they have a project going for lightweight SQL support in hbase
based-on calcite.
For big queries, they'd go to sparksql.
Did you look at phoenix?
Phoenix is complicated, difficult. Calcite migration not done in Phoenix
(Sparksql is not calcite-based).
Talk to phoenix project about generating a lightweight artifact. We could
help with build. One nice idea was building with a cut-down grammar, one
that removed all the "big stuff" and problematics. Could return to the user
a nice "not supported" if they try to do a 10Bx10B join.
An interesting idea about a facade query analyzer making transfer to
sparksql if big query. Would need stats.
