3 ms·

Yeah, lots of bs in this text. The comparison of Synapse Analytics to BigQuery is totally flawed. Not only the cost presented in the chart is taken out of someo

Yeah, lots of bs in this text. The comparison of Synapse Analytics to BigQuery is totally flawed. Not only the cost presented in the chart is taken out of someone's back, the scale of those solutions do not match. Try doing multiple petabyte scale analysis on Synapse and then compare cost and performance to BigQuery. Maybe Databricks could match BQ in this use case.

jitl 3y ago
I think you're missing the point of the article. The article is arguing that these kinds of performance benchmarks/graphs as a whole are not the most important thing when it comes to database success. I think the points made here would stand if you shuffled all the names around in the images, or made up new names and data. There's even a graph later on that just compares "our system" (very fast) to "their system" (10x slower). I'm working on a database system right now, and my favorite paragraph was this one: > Performance must be measured from the user’s perspective, not the database’s. It is a UX problem and, like any UX problem, can’t really be described in a single number. This is surprising to many people, since they think performance, like car racing, is an objective thing. Just because you can say that a Lamborghini is faster than a Prius, they believe you should also be able to say that My database is faster than Your database. But just like a Lamborghini might not get me to work any faster than a Prius (or a bicycle, if there is traffic), the actual workload for a database is going to determine which one is faster.
- HackerThemAll 3y ago
  I also work in databases. The thing is the database engine isn't usually slow by itself. It's the programmers whose programs usually are just as lame as they are. For example during one of my "help us with the slow database server" consultancy assignments I discovered an incident of a query executed collectively over a 1000 times per second on average, adding considerable load to an already overloaded RDBMS, querying a single-row table where the company data (name and address) was stored, which has not changed for over 10 years. No caching in the app whatsoever. The clients _had to_ ask for this info afresh every so often. Eliminating this and only a few similar patterns reduced overall CPU consumption by some 50% and sped up the damn system a lot. I could write a book about this kind of bs I see every day. So, comparing BigQuery to some small data warehouse product, while BigQuery could not even get off the ground yet, that I call bs and put in the same drawer as the above. If the intention was to say "product x" vs "product y", this is what should have been done. But the author deliberately put the proper product names in a lame and dishonest perspective, which makes the whole thing not credible.
  - eyelidlessness 3y ago
    You seem very hung up on a particular graph, and don’t seem to have much to say about the text which follows it and has a substantially different takeaway than the graph alone seems to have impressed on you. Maybe give the article another read with a little bit more of an open mind.
  - ricardobeat 3y ago
    It seems clear that you haven’t actually read the rest of the piece (or are purposefully ignoring it). That graph is used as an a example of why benchmarks don’t matter.
  - porker 3y ago
    Write that book.
bushbaba 3y ago
99% of the BQ use cases I’ve seen is reporting on a dataset < 100GiB. 99% of all big data is really just enterprise reporting and having 1 tool that can work for nearly all reporting needs. Querying a petabyte just isn’t needed these days for nearly all sql needs. And for the 1% of the time it is, often teams prefer spark.
dhoe 3y ago
Do I understand you correctly that you're saying that the author of this post, one of the founding engineers of BigQuery, is being unfair to BigQuery?
- quadrature 3y ago
  I believe they’re saying the opposite.

jitl 3y ago

I think you're missing the point of the article. The article is arguing that these kinds of performance benchmarks/graphs as a whole are not the most important thing when it comes to database success. I think the points made here would stand if you shuffled all the names around in the images, or made up new names and data. There's even a graph later on that just compares "our system" (very fast) to "their system" (10x slower). I'm working on a database system right now, and my favorite paragraph was this one: > Performance must be measured from the user’s perspective, not the database’s. It is a UX problem and, like any UX problem, can’t really be described in a single number. This is surprising to many people, since they think performance, like car racing, is an objective thing. Just because you can say that a Lamborghini is faster than a Prius, they believe you should also be able to say that My database is faster than Your database. But just like a Lamborghini might not get me to work any faster than a Prius (or a bicycle, if there is traffic), the actual workload for a database is going to determine which one is faster.

HackerThemAll 3y ago
I also work in databases. The thing is the database engine isn't usually slow by itself. It's the programmers whose programs usually are just as lame as they are. For example during one of my "help us with the slow database server" consultancy assignments I discovered an incident of a query executed collectively over a 1000 times per second on average, adding considerable load to an already overloaded RDBMS, querying a single-row table where the company data (name and address) was stored, which has not changed for over 10 years. No caching in the app whatsoever. The clients _had to_ ask for this info afresh every so often. Eliminating this and only a few similar patterns reduced overall CPU consumption by some 50% and sped up the damn system a lot. I could write a book about this kind of bs I see every day. So, comparing BigQuery to some small data warehouse product, while BigQuery could not even get off the ground yet, that I call bs and put in the same drawer as the above. If the intention was to say "product x" vs "product y", this is what should have been done. But the author deliberately put the proper product names in a lame and dishonest perspective, which makes the whole thing not credible.
- eyelidlessness 3y ago
  You seem very hung up on a particular graph, and don’t seem to have much to say about the text which follows it and has a substantially different takeaway than the graph alone seems to have impressed on you. Maybe give the article another read with a little bit more of an open mind.
- ricardobeat 3y ago
  It seems clear that you haven’t actually read the rest of the piece (or are purposefully ignoring it). That graph is used as an a example of why benchmarks don’t matter.
- porker 3y ago
  Write that book.

bushbaba 3y ago

99% of the BQ use cases I’ve seen is reporting on a dataset < 100GiB. 99% of all big data is really just enterprise reporting and having 1 tool that can work for nearly all reporting needs. Querying a petabyte just isn’t needed these days for nearly all sql needs. And for the 1% of the time it is, often teams prefer spark.

dhoe 3y ago

Do I understand you correctly that you're saying that the author of this post, one of the founding engineers of BigQuery, is being unfair to BigQuery?

quadrature 3y ago
I believe they’re saying the opposite.