Agree with Andrew, adding SQL capability to HBase will be little messy task and not much value added to HBase when solutions like phoenix already available.
>>> 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. Make sense to me. Regards, Pankaj -----Original Message----- From: Andrew Purtell [mailto:apurt...@apache.org] Sent: Tuesday, August 21, 2018 3:06 AM To: dev <dev@hbase.apache.org> Subject: Re: Rough notes from dev meetup, day after hbaseconasia 2018, saturday morning 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.
