A fair point indeed. On Mon, Aug 20, 2018 at 12:32 PM Vladimir Rodionov <vladrodio...@gmail.com> wrote:
> 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. > > > -- Best regards, Andrew Words like orphans lost among the crosstalk, meaning torn from truth's decrepit hands - A23, Crosstalk
