Yes I think it would be worthwhile. Would-be user feedback on usability is the best kind of feedback a project can get.
On Mon, Aug 20, 2018 at 1:21 PM Josh Elser <els...@apache.org> wrote: > 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. > > > -- Best regards, Andrew Words like orphans lost among the crosstalk, meaning torn from truth's decrepit hands - A23, Crosstalk
