Hacker News Reader

Comment by ebikelaw | Hacker News Reader

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.

View on HN

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.)

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.

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...), 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.

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.

> The result of the second query may be a permanent error indicating that your data has disappeared.

That's actually okay, per SQL. Any SQL transaction may fail, for any reason, at the server's discretion. Because the user's permission to operate on the table was revoked in the middle of their transaction, for example. Or because the server is going down and wants to drop connections.

SQL clients have to be written to assume that any transaction could enter a failed state "before" the execution of a statement, even if the previous statement returned a success.

Helpfully, though, they know that 1. by the SQL standard, that failure means that no part of the transaction applied; and 2. that this failure-state is a failure of the transaction context to be valid, rather than a failure of their statement to be valid. (They don't know that their statement is valid, but they know that they haven't been told that it isn't.)

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...

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`)

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.

Reply on news.ycombinator.com