hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pankaj kr <pankaj...@huawei.com>
Subject RE: Rough notes from dev meetup, day after hbaseconasia 2018, saturday morning
Date Tue, 21 Aug 2018 02:58:04 GMT
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:apurtell@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 <stack@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.
Mime
View raw message