> > > 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". >
+1 on standardizing the data type and storage format API so that it would be easier for other projects to use. > 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)? > Providing relevant feedback before/after a query is run in general is very hard to do. If stats are enabled we have an estimate of how many rows/bytes will be scanned. We could have an optional feature that prevent users from running queries if the rows/bytes scanned are above a certain threshold. We should also enhance our explain plan documentation http://phoenix.apache.org/explainplan.html with example of queries so users know what kinds of queries Phoenix handles well. > 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? > Maybe Maryanne, Rajeshbabu or Ankit can comment on the feasibility of proceeding with the calcite integration. It would be good to standardize our query plan APIs so that we can generate a query plan from a spark catalyst plan for example.
