Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

NewSQL databases fail to guarantee consistency and I blame Spanner

dbmsmusings.blogspot.com

Post reply on HN
Print view View original

111–120 of 319 posts

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

#111

Post by wongarsu »

mannykannot wrote: post #82
21 wrote: post #71

Earlier quoted context omitted.

> Is it really surprising that people who have extremely precise time needs and a whole team devoted to solving them would notice issues that other people wouldn't If GPS timing is bad, a lot of people will notice that their position on the map is incorrect, because that's the whole purpose of the GPS network. A 1 microsecond error is 300 meters.

GPS is not typically used to confirm a position that is known accurately by other means, and that is not its purpose. Only in those cases where there is a manifest conflict with independent spatial information will the problem be evident.

>GPS is not typically used to confirm a position that is known accurately by other means

I am not so sure about that. The most common use of GPS is in satnav in cars. Satnavs typically show a map, and typically it is very easy to confirm your position on a map. Any inaccuracy by more than the usual few meters would be quickly noticed by the majority of GPS users.

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

#112

Post by dustingetz »

romed wrote: post #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 yo…

When infinite resources are available, organizations will somehow find a way to consume them. There are properly consistent not-SQL architectures that do not need clocks, Datomic is one, and it does not require coordination with any government agencies to operate. https://www.datomic.com/

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

#113

Post by hinkley »

niftich wrote: post #50
dgreensp wrote: post #23

Earlier quoted context omitted.

The author of the CAP theorem says the same thing about CAP: https://www.infoq.com/articles/cap-twelve-years-later-how-th...

The middle part of 'CAP Twelve Years Later' [1], especially the part about 'Managing Partitions', and the associated diagram, really should be mandatory reading for anyone who invokes CAP, as it drives home the fact that a partition creates alternate universes (invariants), which have to be reconciled after the fact, and points out that allowing reads only is a valid strategy to provide Consistency (erroring out on w…

> recording the intent to mutate some data in a way that enables duplicates to be discarded later, and for the mutation to be performed at a time that it is safe.

Isn’t that, fundamentally, old school batch processing? Plus ça change, plus c’est le même chose...

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

#114

Post by ianopolous »

amluto wrote: post #106
ianopolous wrote: post #64

Earlier quoted context omitted.

I've always had an issue with systems assuming a universal time, because physics (Special Relativity) tells us there is no such thing. Two events in different places will be viewed as having a different order depending on your frame of reference. All that really matters on a physical level is causal connections. I believe vector clocks capture this semantic. But they have other trade-offs.

Special relativity has no such problem. In SR you can easily define a “time” coordinate everywhere such that all events can be timestamped with that coordinate and will respect causality. GR at least usually has this property as well. (It doesn’t in the presence of closed timelike curves. It does in weak gravity and in the FLRW metric in cosmology. I’m not sure about the general strong gravity case.

Of course every inertial frame in SR has a well defined time coordinate, but that is not a universal time - other frames will disagree on which of two not-causally-connected events happened first. This is normally explained through the lack of a well defined "simultaneity" across different inertial frames.

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

#115

Post by matwood »

Quekid5 wrote: post #78
nemothekid wrote: post #48

> Systems that guarantee consistency only experience a necessary reduction in availability in the event of a network partition. As networks become more redundant, partitions become an increasingly rare event. And even if there is a partition, it is still possible for the majority partition to be available In my experience, yes network partitions are incredibly rare. However 99% of my distributed ststem partitions hav…

I may be a bit of an old fart, but this is the exact reasoning behind my decision to never go with "distributed X" if there's a "single-machine X" where you can just vertically scale. If you can afford 3-5 machines/VMs for a cluster you can almost certainly afford a single machine/VM with 2-4x the resources/CPU and chances are that it'll perform just as well (or better) because it doesn't have network latency to cont…

> I may be a bit of an old fart, but this is the exact reasoning behind my decision to never go with "distributed X" if there's a "single-machine X" where you can just vertically scale.

I use this same reasoning to use an RDBMS until I find a reason it will not work. An ACID compliant datastore makes so many things easier until you hit a very large scale.

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

#116

Post by rch »

dsp1234 wrote: post #94
Twirrim wrote: post #68

Earlier quoted context omitted.

It's not really the default settings, per se. You don't have to change any bit of configuration about your database to get consistency. The DynamoDB API gives you the GetItem API call and a boolean property to choose to make it a consistent read. It's left as a very simple task for developers leveraging DynamoDB to make the appropriate trade offs on consistent or inconsistent read. source: Used to work for AWS on a s…

From the GetItem docs[0] "GetItem provides an eventually consistent read by default." This seems to meet the definition of "DynamoDB's default settings" [0] - https://docs.aws.amazon.com/amazondynamodb/latest/APIReferen...

It's enough of a gray area to make DynamoDB a poor example in this context, since if I were to claim that it was eventually consistent without additional configuration, then an informed person might reasonably assume I didn't know what I was talking about.

It would be better to state that both eventually consistent and fully consistent reads are available, and consistency can be enforced up front via configuration.

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

#117

Post by Serow225 »

Quekid5 wrote: post #78
nemothekid wrote: post #48

> Systems that guarantee consistency only experience a necessary reduction in availability in the event of a network partition. As networks become more redundant, partitions become an increasingly rare event. And even if there is a partition, it is still possible for the majority partition to be available In my experience, yes network partitions are incredibly rare. However 99% of my distributed ststem partitions hav…

I may be a bit of an old fart, but this is the exact reasoning behind my decision to never go with "distributed X" if there's a "single-machine X" where you can just vertically scale. If you can afford 3-5 machines/VMs for a cluster you can almost certainly afford a single machine/VM with 2-4x the resources/CPU and chances are that it'll perform just as well (or better) because it doesn't have network latency to cont…

My experience is that it's unfortunately really hard to convince people who don't deeply understand distributed systems (but think they know) that just because a system is called 'HA' or can have an 'HA' mode turned on, that doing so has downsides. They freak out if you try to propose _not_ running the HA mode, because they don't (or aren't willing to) understand the potential downsides of dealing with split-brain, bad recovery, etc. They just see it as a "enable checkbox and forget it" kind of thing that should always be turned on. This is a big struggle of mine, any suggestions would be appreciated...

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

#118

Post by ianopolous »

ianopolous wrote: post #90
notatcomputer68 wrote: post #67

Earlier quoted context omitted.

Can't you solve that by just picking a reference frame though?

You need a quite elaborate system of a grid of synchronized, stationary clocks and rods to correctly define a reference frame, which is worse than what's required to come up with a "good enough on earth to some time resolution" true time.

To be clear this is pretty much exactly what the system of GPS satellites does, but without physical rods, and it is very expensive to construct and maintain. This works fine to a certain accuracy as long as you restrict your application to staying on earth.

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

#119

Post by Dave_Rosenthal »

idubrov wrote: post #89

Any comments on how FoundationDB might be the same / different?

FoundationDB adheres to the highest level of consistency (linearizability) and, unlike Spanner or its derivatives, does not rely on clocks to achieve this.

I'm surprised FoundationDB is not mentioned in the article. Maybe it didn't help the author make his point, but it is both the most mature of the new breed of ACID+noSQL databases and completely free/open source.

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

#120

Post by jakelarkin »

abadid wrote: 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.

won't batching transactions increasing the failure rate by a multiple of (batch size)? how should users reason about that tradeoff?
Post reply on HN