C* fares much better with their (very limited) CQL than HBase with its advanced Phoenix. Just saying.
My 2c -Vlad On Mon, Aug 20, 2018 at 12:06 PM, Andrew Purtell <apurt...@apache.org> 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. >
