Live data from Hacker News

NewSQL databases fail to guarantee consistency and I blame Spanner

dbmsmusings.blogspot.com

11–20 of 319 posts

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

#11
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?

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

#12
> 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" I think one would need to show that it has some significant problem in the environment it was designed for.

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

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

Without some description of what "false claims" and "misinterpretation" you mean, this is a content-free post.

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

#15

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

That's because the author is pushing Calvin, which came out of his research group.

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

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

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

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

Nice writeup, but given the title, I was hoping you would also have a constructive test case that shows that these systems fail to meet their guarantees (like Jepsen did). :)

I wonder if any of the aforementioned systems (Calvin/Spanner/YugaByte) that can opportunistically commit transactions and detect issues and roll back + retry all within the scope of the RPC so it can still conform to linearisability requirement?

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

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

Do these concerns also apply in an HTAP or OLAP context e.g. systems like Cloudera's Kudu, which uses Hybrid Time? Or maybe Volt which you also worked on?

OLAP systems tend to be read only (for analytics) so the question of transactions and consistency isn't really applicable.

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

#19
post #9

Earlier quoted context omitted.

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.

Without some description of what "false claims" and "misinterpretation" you mean, this is a content-free post.

It has more "content" than the post to which it replies.

"This is good."

"No, it is bad, in these particular areas."

[EDIT:] Granted, the post could still be wrong, but ISTM accusations of content-freedom tend to be projections.

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

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

The problem isn't a lack of very accurate clocks per se, right? What you need is an accurate bound on clock error, whatever it might be. It sounds to me that non-Googles are specifying bound parameters that, unlike Google, they cannot guarantee. Doesn't that mean the blame goes to whomever put inaccurate bound parameters into the software? Why blame the algorithm for garbage input?
Post reply on HN