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.
