4 ms·

Whew. Those years of enduring "SQL is dead" posts were not easy. Now if we can just rebrand "cloud" to "someone else's computer", much will be right with the wo

Whew. Those years of enduring "SQL is dead" posts were not easy. Now if we can just rebrand "cloud" to "someone else's computer", much will be right with the world.

peterwwillis 8y ago
Really it should be rebranded "shared hosting".
- aklemm 8y ago
  Novel. I like it.
dboreham 8y ago
Web. Scale.
ebikelaw 8y ago
The conflation of SQL with consistency in this blog post is dumb. Yes Google offers SQL on Spanner but the query execution is built atop lower level Spanner primitives that are also available to developers and are similar to Bigtable concepts. Also Bigtable is still much, much larger and more important within Google than is Spanner/F1, so the death of Bigtable is much overhyped. Point is there are strong and weak consistency models with and without SQL execution engines, and they’re all useful.
- derefr 8y ago
  The SQL standard specifies explicit consistency semantics for statements and transactions, though. So something claiming to adhere to e.g. SQL:2011, is claiming that executing certain commands will have certain consistency properties (and if you've set up your DBMS to have weaker consistency, then it should be blaring a loud alarm that you've effectively put it in a non-SQL-standard-conformant mode.) Other generic DBMS query protocols could specify their own consistency semantics, but I'm not aware of any that do. (I guess, if you consider REST a "DBMS query protocol", then CouchDB is an example of a DBMS "conforming" to the consistency semantics specified in the REST protocol.)
  - ebikelaw 8y ago
    If that's your definition then it's even more dumb to hold up Google Cloud Spanner as an example of how SQL gives you consistency. There's NO WAY to mutate Spanner tables via SQL. All writes are performed via the lower-level RPC interfaces. The only thing you can do with Spanner from SQL is query it. The consistency provided by Spanner is clearly not provided by SQL.
    - derefr 8y ago
      Even if a DBMS only exposes read-only SQL support, that still has consistency-model implications—namely that, if you can execute several SQL statements in a transaction with a long delay between those statements, then all the statements in the transaction should execute against the same MVCC "version" of the affected tables. So a write on that lower-level RPC interface shouldn't, by the SQL spec, be able to cause a sequence of SQL wire messages like this: BEGIN SELECT COUNT(*) FROM foo; -- 100s later SELECT COUNT(*) FROM foo; COMMIT; ...to return separate numbers for those two SELECTs. If it could, under Spanner, then Spanner wouldn't be conformant to [the read-only subset] of whatever SQL standard it claims to obey. But, according to the Cloud Spanner docs (https://cloud.google.com/spanner/docs/transactions#read-only_transactions https://cloud.google.com/spanner/docs/transactions#read-only...), the above code will always return the same values for the two queries. And, if you're feeling argumentative, you could interpret the reason for the particular consistency semantics, as the fact that Cloud Spanner claims to support SQL, and SQL mandates that consistency. You could suppose that, without that claim, Cloud Spanner would never have bothered building a transactional MVCC layer into their architecture.
      - ebikelaw 8y ago
        Unfortunately, no. Spanner may garbage collect the snapshot timestamp to which your example query was bound, if the garbage collection policy was triggered by additional writes at greater timestamps, or by the simple passage of time. The result of the second query may be a permanent error indicating that your data has disappeared. Spanner had a transactional MVCC system in their original implementation described in the 2012 paper which predates SQL support described in the 2017 paper. Therefore it is probably wrong to credit SQL with Spanner's MVCC system.
- atomic77 8y ago
  I also will never understand why people have so much trouble decoupling SQL, the query language, from classic RDBMS systems. Being able to use a SQL-like dialect in systems like Hive, Spark SQL, and now even Elasticsearch makes those systems infinitely more useful. Now if only I didn't have to keep looking up the pandas "Comparison with SQL" page every time I have to do some manipulations to a data frame...
  - munk-a 8y ago
    Also some services really get held back by their lack of SQL support. We use splunk and the lack of SQL expression comprehension hurts (especially with their lack of `IN`)
- coding123 8y ago
  It also conflated Elasticsearches new native SQL feature too, which is also query only and sits atop a non-relational engine. Doesn't change how much I love Elastic.
hinkley 8y ago
As much as I hate NoSQL (which is considerable), I think it was destined to happen. Sometimes the incumbent needs a kick in the ass. It feels like the pace of improvement in boring old databases has had an uptick for the last five or so years. That feeling of slowness is probably what opened the door in the first place. If you put enough beers in me I would have admitted as much at the time. Database progress got boring. But the other thing is that people forget the past when it's been too long since the Dark Times. I have my fingers crossed, and perhaps I will regret that naivete some day, but I have my fingers crossed anyway that there's a whole generation of young developers that will know, viscerally, why we use Relational Databases. Why concurrent access to data is hard and we should leave it to the professionals instead of rolling our own every time we're feeling bored at work. The same way we generally let other people do billing, or data viz. [Edit to add] One of the biggest things I'm champing at the bit for an opportunity to use is the newer event streaming stuff that builds on exporting the WAL data from ACID databases. My OLTP data set gets to be the system of record as God and Man intended, but there's a perfectly sane mechanism to support the occasionally very valid OLAP-oriented business concerns. Any time a tool can take away something that makes my life difficult or unpredictable is a good tool. I just haven't been at the right sized company that it's an unsolved problem that we need to solve, and I have higher priorities for my own stuff.
- zzzcpan 8y ago
  Slowness of progress in traditional databases has absolutely nothing to do with it. Primary reason NoSQL even exists is inability of traditional databases to run in distributed environments with decent availability, scalability, latency/performance and low maintenance requirements. It was never about SQL the language or relational model (which, by the way, is not inherently better than other models). Nothing has changed since. As there exist fundamental limitations preventing all those traditional databases from ever satisfying requirements. And new distributed relational databases designed and built from the ground up so far don't seem to be able to meet neither SQL crowd's expectations nor win people who are facing actual distributed problems. It's like progress in databases doesn't favor familiarity over other things at all, effectively resetting familiarity with relational model altogether and forcing even models to compete with each other for fresh minds.

Whew. Those years of enduring "SQL is dead" posts were not easy. Now if we can just rebrand "cloud" to "someone else's computer", much will be right with the world.

peterwwillis 8y ago

Really it should be rebranded "shared hosting".

aklemm 8y ago
Novel. I like it.

dboreham 8y ago

Web. Scale.

ebikelaw 8y ago

The conflation of SQL with consistency in this blog post is dumb. Yes Google offers SQL on Spanner but the query execution is built atop lower level Spanner primitives that are also available to developers and are similar to Bigtable concepts. Also Bigtable is still much, much larger and more important within Google than is Spanner/F1, so the death of Bigtable is much overhyped. Point is there are strong and weak consistency models with and without SQL execution engines, and they’re all useful.

derefr 8y ago
The SQL standard specifies explicit consistency semantics for statements and transactions, though. So something claiming to adhere to e.g. SQL:2011, is claiming that executing certain commands will have certain consistency properties (and if you've set up your DBMS to have weaker consistency, then it should be blaring a loud alarm that you've effectively put it in a non-SQL-standard-conformant mode.) Other generic DBMS query protocols could specify their own consistency semantics, but I'm not aware of any that do. (I guess, if you consider REST a "DBMS query protocol", then CouchDB is an example of a DBMS "conforming" to the consistency semantics specified in the REST protocol.)
- ebikelaw 8y ago
  If that's your definition then it's even more dumb to hold up Google Cloud Spanner as an example of how SQL gives you consistency. There's NO WAY to mutate Spanner tables via SQL. All writes are performed via the lower-level RPC interfaces. The only thing you can do with Spanner from SQL is query it. The consistency provided by Spanner is clearly not provided by SQL.
  - derefr 8y ago
    Even if a DBMS only exposes read-only SQL support, that still has consistency-model implications—namely that, if you can execute several SQL statements in a transaction with a long delay between those statements, then all the statements in the transaction should execute against the same MVCC "version" of the affected tables. So a write on that lower-level RPC interface shouldn't, by the SQL spec, be able to cause a sequence of SQL wire messages like this: BEGIN SELECT COUNT(*) FROM foo; -- 100s later SELECT COUNT(*) FROM foo; COMMIT; ...to return separate numbers for those two SELECTs. If it could, under Spanner, then Spanner wouldn't be conformant to [the read-only subset] of whatever SQL standard it claims to obey. But, according to the Cloud Spanner docs (https://cloud.google.com/spanner/docs/transactions#read-only_transactions https://cloud.google.com/spanner/docs/transactions#read-only...), the above code will always return the same values for the two queries. And, if you're feeling argumentative, you could interpret the reason for the particular consistency semantics, as the fact that Cloud Spanner claims to support SQL, and SQL mandates that consistency. You could suppose that, without that claim, Cloud Spanner would never have bothered building a transactional MVCC layer into their architecture.
    - ebikelaw 8y ago
      Unfortunately, no. Spanner may garbage collect the snapshot timestamp to which your example query was bound, if the garbage collection policy was triggered by additional writes at greater timestamps, or by the simple passage of time. The result of the second query may be a permanent error indicating that your data has disappeared. Spanner had a transactional MVCC system in their original implementation described in the 2012 paper which predates SQL support described in the 2017 paper. Therefore it is probably wrong to credit SQL with Spanner's MVCC system.
atomic77 8y ago
I also will never understand why people have so much trouble decoupling SQL, the query language, from classic RDBMS systems. Being able to use a SQL-like dialect in systems like Hive, Spark SQL, and now even Elasticsearch makes those systems infinitely more useful. Now if only I didn't have to keep looking up the pandas "Comparison with SQL" page every time I have to do some manipulations to a data frame...
- munk-a 8y ago
  Also some services really get held back by their lack of SQL support. We use splunk and the lack of SQL expression comprehension hurts (especially with their lack of `IN`)
coding123 8y ago
It also conflated Elasticsearches new native SQL feature too, which is also query only and sits atop a non-relational engine. Doesn't change how much I love Elastic.

hinkley 8y ago

As much as I hate NoSQL (which is considerable), I think it was destined to happen. Sometimes the incumbent needs a kick in the ass. It feels like the pace of improvement in boring old databases has had an uptick for the last five or so years. That feeling of slowness is probably what opened the door in the first place. If you put enough beers in me I would have admitted as much at the time. Database progress got boring. But the other thing is that people forget the past when it's been too long since the Dark Times. I have my fingers crossed, and perhaps I will regret that naivete some day, but I have my fingers crossed anyway that there's a whole generation of young developers that will know, viscerally, why we use Relational Databases. Why concurrent access to data is hard and we should leave it to the professionals instead of rolling our own every time we're feeling bored at work. The same way we generally let other people do billing, or data viz. [Edit to add] One of the biggest things I'm champing at the bit for an opportunity to use is the newer event streaming stuff that builds on exporting the WAL data from ACID databases. My OLTP data set gets to be the system of record as God and Man intended, but there's a perfectly sane mechanism to support the occasionally very valid OLAP-oriented business concerns. Any time a tool can take away something that makes my life difficult or unpredictable is a good tool. I just haven't been at the right sized company that it's an unsolved problem that we need to solve, and I have higher priorities for my own stuff.

zzzcpan 8y ago
Slowness of progress in traditional databases has absolutely nothing to do with it. Primary reason NoSQL even exists is inability of traditional databases to run in distributed environments with decent availability, scalability, latency/performance and low maintenance requirements. It was never about SQL the language or relational model (which, by the way, is not inherently better than other models). Nothing has changed since. As there exist fundamental limitations preventing all those traditional databases from ever satisfying requirements. And new distributed relational databases designed and built from the ground up so far don't seem to be able to meet neither SQL crowd's expectations nor win people who are facing actual distributed problems. It's like progress in databases doesn't favor familiarity over other things at all, effectively resetting familiarity with relational model altogether and forcing even models to compete with each other for fresh minds.