61–70 of 88 posts
Below are the reasons given in the blog post and I am trying to compare them with Hive SQL + Spark
SQL compatibility - I need to check this as I am not a SQL expert, but Hive SQL seems compatible
First-class nested data - supported
Optional schema and query stability - supported
Minimal extensions - feels same goals in Hive SQL
Format independence - yes
Data store independence - yes.
PartiQL> SELECT * FROM [1,2,3] | ===' > --- OK! (86 ms) Jeez. 86ms for this query on this data set? Hope that's not representative of the general performance!
You missed the point. The modern infrastructure's primary value is scalability. This number is of course bad, for the data. But this number will be more impressive when the data is million time bigger.
In the era of 64-core processors, scaling horizontally is meaningless for 99.9% of architecture designs. Latency matters to everyone, always.
Trivial queries taking nearly 1/10th of a second on modern kit is absolutely atrocious, and shows a total lack of awareness of performance as a feature.
Now, in practice, perhaps with sufficient adoption and integration, PartiQL might be good enough for 80% of use cases.
Earlier quoted context omitted.
You missed the point. The modern infrastructure's primary value is scalability. This number is of course bad, for the data. But this number will be more impressive when the data is million time bigger.
You missed the point. Modern infrastructure's scalability is irrelevant if even one user's experience is poor. In the era of 64-core processors, scaling horizontally is meaningless for 99.9% of architecture designs. Latency matters to everyone, always. Trivial queries taking nearly 1/10th of a second on modern kit is absolutely atrocious, and shows a total lack of awareness of performance as a feature.
The time reported by the REPL can be misleading.
There is work that we definitely need to do on performance as we develop PartiQL. Performance is something we have been considering since inception and we will keep considering as we go forward.
PartiQL> SELECT * FROM [1,2,3] | ===' > --- OK! (86 ms) Jeez. 86ms for this query on this data set? Hope that's not representative of the general performance!
It's an early reference implementation and demo program to show off the language syntax, it doesn't have much to do with whatever engine actually executes the query and that will be the majority of any real query's timing.
Regardless, even the query parsing and compilation should be much faster if it moves into lower-level language like C++ or Rust.
Is this a GraphQL alternative or more for accessing DBs in the backend?
GraphQL has some similarities in handling complex queries across multiple data sources, but also has lots of functionality and large ecosystem around offering it as a public API to clients.
Will this be integrated into AWS Athena? The blog post doesn't mention it.
Earlier quoted context omitted.
You missed the point. The modern infrastructure's primary value is scalability. This number is of course bad, for the data. But this number will be more impressive when the data is million time bigger.
You missed the point. Modern infrastructure's scalability is irrelevant if even one user's experience is poor. In the era of 64-core processors, scaling horizontally is meaningless for 99.9% of architecture designs. Latency matters to everyone, always. Trivial queries taking nearly 1/10th of a second on modern kit is absolutely atrocious, and shows a total lack of awareness of performance as a feature.
I used to do a lot of BigQuery for analytics. Latency in BigQuery is crap and clearly not it's selling point, we're not talking ms here, we're talking seconds at a minimum. Yet it's a really nice database for it's use cases.