Live data from Hacker News

NewSQL databases fail to guarantee consistency and I blame Spanner

dbmsmusings.blogspot.com

21–30 of 319 posts

Re: NewSQL databases fail to guarantee consistency and I blame Spanner

#21
This is the clearest presentation of why CAP is misleading that I’ve ever seen! Wonderful.

If the app programmer knows they don’t have global consistency, just consistency per partition, I wonder if in practice there are ways to achieve the necessary application-level guarantees such as in the photo-sharing case (not that it sounds that appealing to need to do so).

Re: NewSQL databases fail to guarantee consistency and I blame Spanner

#22
post #2

I'm the author of that post. I'm happy to respond to comments on the post on this thread for the next several hours. You can also leave comments on the post itself, and I will respond there at any time.

Hi, you used DynamoDB as an example of a weakly consistent system in the opening paragraph, but it actually supports both modes [1]. The point of confusion might come from the fact that the service described in 2007 Dynamo paper was an inspiration for DynamoDB, rather than DynamoDB itself.

Disclaimer, I work for AWS, but not on DynamoDB team.

[1] https://docs.aws.amazon.com/amazondynamodb/latest/developerg...

Re: NewSQL databases fail to guarantee consistency and I blame Spanner

#23
post #9
post #3

In case you're wondering : this is a very worthwhile read.

Too many false claims for my taste. Especially wrt to eventual consistency and consistency guarantees. Also some misinterpretation of CAP theorem to fit the narrative. Very typical FaunaDB promotional post.

The author of the CAP theorem says the same thing about CAP:

https://www.infoq.com/articles/cap-twelve-years-later-how-th...

Re: NewSQL databases fail to guarantee consistency and I blame Spanner

#24
post #2

I'm the author of that post. I'm happy to respond to comments on the post on this thread for the next several hours. You can also leave comments on the post itself, and I will respond there at any time.

I question your statement that building apps on weakly-consistent systems is so difficult. I’ve worked on very large scale systems that you’ve definitely heard of and probably used that are built atop storage systems with very weak semantics and asynchronous replication. Aren’t such systems existence proofs, or do you think there’s just a huge difference between the abilities of engineers in various organizations?

Re: NewSQL databases fail to guarantee consistency and I blame Spanner

#25
The post talks about Spanner using "a specialized hardware solution that uses both GPS and atomic clocks to ensure a minimal clock skew across servers." But what it fails to mention is that is that this time is distributed using a software solution --- NTP, in fact.

Google makes its "leap-smeared NTP network" available via Google's Public NTP service. And it's not expensive for someone to buy their own GPS clock and run their own leap-smared NTP service.

Yes, it means that someone who installs a NewSQL database will have to set up their own time infrastructure. But that's not hard! There are lots of things about hardware setup which are at a similar level of trickiness, such as UPS with notification so that servers can shutdown gracefully when the batteries are exhausted, locating your servers in on-prem data centers so that if a flood takes out one data center, you have continuity of service elsewhere, etc., etc.

Or of course, you can pay a cloud infrastructure provider (which Google happens to provide, but Amazon and Azure also provides similar services) to take care all of these details for you. Heck, if you use Google Compute Platform, you can use the original Spanner service (accept no substitutes :-)

Re: NewSQL databases fail to guarantee consistency and I blame Spanner

#26
post #16

> We will trace the failure to guarantee consistency to a controversial design decision made by Spanner that has been tragically and imperfectly emulated in other systems. This post doesn't establish any "controversy" about Spanner's design decision. It only says that it requires special hardware, which other systems attempt to emulate despite not having this specialized hardware. To call this decision "controversial…

By controversial, I mean that in the database research community (where I spend most of my time), there is significant disagreement about global consensus vs. Spanner's choice of partitioned consensus.

Disagreement about what though? Does Spanner's solution have an objective problem? Do you or others in your community have specific reasons to believe that it cannot deliver on its promises?

Re: NewSQL databases fail to guarantee consistency and I blame Spanner

#27
post #22
post #2

I'm the author of that post. I'm happy to respond to comments on the post on this thread for the next several hours. You can also leave comments on the post itself, and I will respond there at any time.

Hi, you used DynamoDB as an example of a weakly consistent system in the opening paragraph, but it actually supports both modes [1]. The point of confusion might come from the fact that the service described in 2007 Dynamo paper was an inspiration for DynamoDB, rather than DynamoDB itself. Disclaimer, I work for AWS, but not on DynamoDB team. [1] https://docs.aws.amazon.com/amazondynamodb/latest/developerg...

Thanks. I added a parenthetical remark to the post to indicate that I was talking about DynamoDB's default settings.

Re: NewSQL databases fail to guarantee consistency and I blame Spanner

#28
post #2

I'm the author of that post. I'm happy to respond to comments on the post on this thread for the next several hours. You can also leave comments on the post itself, and I will respond there at any time.

why didn't you disclose your connections in your post? It appears you've written much the same article for FaunaDB's official blog in the past (https://fauna.com/blog/distributed-consistency-at-scale-span...).

Re: NewSQL databases fail to guarantee consistency and I blame Spanner

#29
I’ve seen comments on HN over the years in which someone Dunning-Kruegers their way into saying that TrueTime is easily replicated. I always wonder if they have sixteen senior SREs in their pocket, because that’s the level of production engineering Google applies to the problem. Time SRE has at various points had take measures up to and including calling the USAF and telling them their satellites are fucked up. If you don’t have the staff for this, the easiest way to get access to TrueTime is probably to just use Cloud Spanner.

Re: NewSQL databases fail to guarantee consistency and I blame Spanner

#30
post #2

I'm the author of that post. I'm happy to respond to comments on the post on this thread for the next several hours. You can also leave comments on the post itself, and I will respond there at any time.

I recently came across CockroachDB and thought it's capabilities interesting, almost too good to be true. I also have been looking at Citus Data which shards and distributes transactions, are you aware of any consistency shortcomings with it?

CockroachDB's performance is dependent on time synchronization. If a node detects it's too far behind, it will commit suicide.

However, before it detects it, there is a possibility of stale reads.

https://www.cockroachlabs.com/docs/stable/recommended-produc...

Post reply on HN