I will point out that the thin client can have advantages too:1. The query engine pool can be sized independently of clients and region servers now.2. Appropriate machine/VM configurations can be picked that are optimal for query execution.3. Client and (region) servers can be upgraded entirely independently. As Josh pointed out... As HBase commiter and PMC member I am unaware of any "native SQL" aspirations for HBase.
On Wednesday, September 19, 2018, 11:07:09 AM PDT, Josh Elser <els...@apache.org> wrote: On 9/18/18 12:08 PM, Jaanai Zhang wrote: >> >> I don't understand what performance issues you think exist based solely on >> the above. Those numbers appear to be precisely in line with my >> expectations. Can you please describe what issues you think exist? >> > > 1. Performance of the thick client has almost 1~4 time higher than the thin > client, the performance of the thin client will be decreased when the > number of concurrencies is increased. For some applications of the web > server, this is not enough. > 2. An HA thin client. > 3. SQL audit function > > A lot of developer like using the thin client, which has a lower > maintenance cost on the client.Sorry, that's all that comes to me. :) The thin-client is always doing more work to execute the same query as the thick-client (shipping results to/from PQS), so it shouldn't be surprising that the thin-client is slower. This is the trade-off to do less in the client and also make a well-defined API for other language to talk to PQS. Out of curiosity, did you increase the JVM heap for PQS or increase configuration property defaults for PQS to account for the increased concurrency? > Please be more specific. Asking for "more documentation" doesn't help us >> actually turn this around into more documentation. What are the specific >> pain points you have experienced? What topics do you want to know more >> about? Be as specific as possible. >> > > About documents: > 1. I think that we cloud add documents about migrate tools and migrate > cases since many users migrate from RDBMS(MYSQL/PG/SQL SERVER) to Phoenix > for some applications of non-transaction. > 2. How to design PK or indexes. > > About pain points: > The stability is a big problem. Most of the people use Phoenix as a common > RDBMS, they are informal to execute a query, even if they don't know why > server crash when a scan full table was executed, so define use boundary of > Phoenix is important that rejects some query and reports it user's client. A migration document would be a great. Something that can supplement the existing "Quick Start" document. What kind of points would you want to have centralized about designing PK's or indexes? > Are you referring to the hbase-spark (and thus, Spark SQL) integration? Or >> something that some company is building? >> > > Some companies are building with SPARK SQL to access Phoenix to support > OLAP and OLTP requirements. it will produce heavily load for HBase cluster > when Spark reads Phoenix tables, my co-workers want to directly read > HFiles of Phoenix tables for some offline business, but that depends on > more flexible Phoenix API. Just beware in calling "HBase native sql" as this implies that this is something that is a part of Apache HBase (which is not the case). I doubt anyone in the Phoenix community would take offense to saying that a basic read/write SQL-esque language on top of HBase would be much more simple/faster than Phoenix is now. The value that Phoenix provides is a _robust_ SQL implementation and a consistent secondary indexing support. Going beyond a "sql skin" and implementing a database management system is where Phoenix excels above the rest. > Uh, I also got some feedback that some features import for users, For > example, "alter table modify column" can avoid reloaded data again which is > expensive operate for the massive data table. I had upload patches to JIRA( > PHOENIX-4815 <https://issues.apache.org/jira/browse/PHOENIX-4815>), but > nobody responds to me :(. You should already know that we're all volunteers here, with our own responsibilities. You can ask for assistance/help in reviews, but, as always, be respectful of everyone's time. This goes for code reviews, as well as new documentation. > Now, i devote to develop chaos test and PQS stability(it was developed on > the branch of my company, these patches will contribute to the community > after stable running ), if you have any suggests, please tell to me what > you thinking. I would appreciate your reply. Would be happy to see what you create.
