Sorry for replying late. I attended HBaesCon Asia as a speaker and got some some notes. I think Phoenix’ pains as following:
1. Thick client isn’t as more popular as thin client. For some we applications: 1. Users need to spend a lot of time to solve the dependencies, 2. Users worry about the stability which some calculation operates are processed within thick client . 3. Some people hope use multi program language client, such as Go, .Net and Python etc… Other benefits: 1 Easy to add SQL audit function. 2. Recognise invalid SQL and report to user... As you said this definitely a big issue which is worth paying more attention. However thick client exists some problems, it is recently test data about performance: 2. Actually, Phoenix has a high barrier for beginner than common RDBMS, users need to learn HBase before using Phoenix, Most of people don’t know how to reasonable to use, so we need more detail documents make Phoenix use easier. 3. HBase 3.0 has a plan about native SQL, does Phoenix has a plan? Even if many peoples don’t know HBase has a SQL layer which is called Phoenix, so can we put the link on HBase website? On 2018/08/27 18:03:30, Josh Elser <e...@apache.org> wrote: > (bcc: dev@hbase, in case folks there have been waiting for me to send > > this email to dev@phoenix)> > > Hi,> > > In case you missed it, there was an HBaseCon event held in Asia > > recently. Stack took some great notes and shared them with the HBase > > community. A few of them touched on Phoenix, directly or in a related > > manner. I think they are good "criticisms" that are beneficial for us to > > hear.> > > 1. The phoenix-$version-client.jar size is prohibitively large> > > In this day and age, I'm surprised that this is a big issue for people. > > I know have a lot of cruft, most of which coming from hadoop. We have > > gotten better here over recent releases, but I would guess that there is > > more we can do.> > > 2. Can Phoenix be the de-facto schema for SQL on HBase?> > > We've long asserted "if you have to ask how Phoenix serializes data, you > > shouldn't be do it" (a nod that you have to write lots of code). What if > > we turn that on its head? Could we extract our PDataType serialization, > > composite row-key, column encoding, etc into a minimal API that folks > > with their own itches can use?> > > With the growing integrations into Phoenix, we could embrace them by > > providing an API to make what they're doing easier. In the same vein, we > > cement ourselves as a cornerstone of doing it "correctly".> > > 3. Better recommendations to users to not attempt certain queries.> > > We definitively know that there are certain types of queries that > > Phoenix cannot support well (compared to optimal Phoenix use-cases). > > Users very commonly fall into such pitfalls on their own and this leaves > > a bad taste in their mouth (thinking that the product "stinks").> > > Can we do a better job of telling the user when and why it happened? > > What would such a user-interaction model look like? Can we supplement > > the "why" with instructions of what to do differently (even if in the > > abstract)?> > > 4. Phoenix-Calcite> > > This was mentioned as a "nice to have". From what I understand, there > > was nothing explicitly from with the implementation or approach, just > > that it was a massive undertaking to continue with little immediate > > gain. Would this be a boon for us to try to continue in some form? Are > > there steps we can take that would help push us along the right path?> > > Anyways, I'd love to hear everyone's thoughts. While the concerns were > > raised at HBaseCon Asia, the suggestions that accompany them here are > > largely mine ;). Feel free to break them out into their own threads if > > you think that would be better (or say that you disagree with me -- > > that's cool too)!> > > - Josh> >
