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

221–230 of 319 posts

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

#221

Post by erikb »

CydeWeys wrote: post #212
erikb wrote: post #155

Earlier quoted context omitted.

Why does anybody need to provide consistency? Often you don't have complete consistency anyways. There are bugs, there are time delays, there is parallel processing. Why even have the requirement?

Let me expand on an example issue that comes up. Nomulus is software that runs a domain name registry, including most notably the .app TLD. There are three fundamental objects at play here; the domains themselves, contacts (ownership information that goes into WHOIS), and hosts (nameserver information that feeds into DNS). There's a many-to-many relationship here, in that contacts and hosts can be reused over an arbi…

I don't see how this relates to the question whether consistency is needed. If two tables only have 80% of all the rows that you expect you can STILL do a join on them. It's just that the join, just like your original data, is not containing all data sets. The join itself will not raise an exception because of that.

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

#222

Post by erikb »

zzzcpan wrote: post #176
erikb wrote: post #155

Earlier quoted context omitted.

Why does anybody need to provide consistency? Often you don't have complete consistency anyways. There are bugs, there are time delays, there is parallel processing. Why even have the requirement?

Well, it's pretty hard to even find applications that require strong global consistency and are willing to sacrifice latency for that. Typically apps don't need much consistency at all and can sacrifice some data instead, like with most RDBMS setups in the wild. Beyond that SEC (strong eventual consistency) covers pretty much all consistency needs there are.

> it's pretty hard to even find applications that require strong global consistency

Exactly my point, even a little generalized. The world isn't consistent, why always put unrealistic constraints unto ourselves. If we change from "I really need to have all the datasets in all of their truthest form" and instead go with "well there is some data coming, better than nothing" the whole system might be even more reliable. Things in the middle won't die just because the world is imperfect.

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

#223

Post by CydeWeys »

erikb wrote: post #221
CydeWeys wrote: post #212

Earlier quoted context omitted.

Let me expand on an example issue that comes up. Nomulus is software that runs a domain name registry, including most notably the .app TLD. There are three fundamental objects at play here; the domains themselves, contacts (ownership information that goes into WHOIS), and hosts (nameserver information that feeds into DNS). There's a many-to-many relationship here, in that contacts and hosts can be reused over an arbi…

I don't see how this relates to the question whether consistency is needed. If two tables only have 80% of all the rows that you expect you can STILL do a join on them. It's just that the join, just like your original data, is not containing all data sets. The join itself will not raise an exception because of that.

Strong consistency is required because you cannot delete/rename a host or contact if it is in use at all. Hence the requirement for strong consistency. It's not good enough to say that you can go ahead with the operation because it's not used by at least 80% of domains; you need to know that it's not in used by any domains.

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

#224

Post by abadid »

rkarthik007 wrote: post #199

CTO of YugaByte here. We firmly stand by our claims, and I wanted to explain more. From the post by Daniel: YugaByte, however, continues to claim a guarantee of consistency. I would advise people not to trust this claim. YugaByte, by virtue of its Spanner roots, will run into consistency violations when the local clock on a server suddenly jumps beyond the skew uncertainty window. >> The statement about YugaByte DB i…

Looks like you cross-posted this comment here and on my blog, so I'll also cross-post in my response.

I am quite confused by your statement that YugaByte does not claim linearizability. The C of CAP is linearizability (see the original CAP theorem https://users.ece.cmu.edu/~adrian/731-sp04/readings/GL-cap.p...). By claiming to be CP from CAP, you are claiming linearizability.

CockroachDB also makes the same CP claim. However, they explicitly walk back from this claim (https://www.cockroachlabs.com/blog/living-without-atomic-clo...). In contrast, YugaByte documentation makes no effort to walk back from this claim. Rather, the documentation seems to indicate that YugaByte is linearizable at: https://blog.yugabyte.com/jepsen-testing-on-yugabyte-db-data... and https://docs.yugabyte.com/latest/develop/learn/acid-transact....

Also, I would encourage you to read the Herlihy-Wing paper on linearizability published in 1990. You seem to be confusing linearizability with ACID isolation levels, which are actually a different concept. Peter Bailis has a good blog post on the difference: http://www.bailis.org/blog/linearizability-versus-serializab....

On your third point, we agree. However, the point of my post is that relying on max clock skew without hardware support is dangerous. I’m going so far as to say that it’s so dangerous that it is incorrect to claim consistency guarantees when you make such assumptions.

I would really encourage YugaByte to consider using global consensus instead of partitioned consensus. I believe you will find it much easier to support serializability (which as you said, is on your road map) and linearizability.

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

#225

Post by threeseed »

jpalomaki wrote: post #39

And majority of developers don’t need NoSQL or NewSQL - they are well off with PostgreSQL. I think the old and tried should be the default choice here and other paths taken only after careful consideration and good justifications.

Or how about instead of just blindly picking a system. You spend a week or two to evaluate a few that you think might mesh well for your data structures. PostgreSQL doesn't work well for many, many common use cases.

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

#226

Post by icedchai »

guelo wrote: post #166
chubot wrote: post #148

Earlier quoted context omitted.

Yup, Google clusters also originally had machines with 1 or 2 CPUs! SMP on Linux was a new thing! Nowadays you easily have 32 cores on a machine, and each core is significantly faster than it was back then (probably at least 10x). That is a compute cluster by the definition of 1999. So for certain "big data" tasks (really "medium data" but not everyone knows the difference), I just use a single machine and shell scri…

> Common languages like node.js, Python, R, OCaml, etc. do NOT let you use all your cores "by default" If the code is written in a distributed fashion from the start then it can be designed so it's one python/node/R process per core. And that makes the transition to distributed servers simpler anyway.

Or you could use a language that supports threads, like Go, Java, C, C++, C#... This gives you much more flexibility.

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

#227

Post by threeseed »

peterwwillis wrote: post #46

Distributed databases are like systems of government. Some are worse than others, but all of them suck. I'm not aware of any study that shows that X type of database reduces bugs, increases availability, and makes customers happier. Pick one that fits your application and deal with the suckiness.

Distributed databases underpin every major web app today e.g. Facebook, Instagram, Google, Apple, Spotify etc.

So clearly they are helping to increase availability and make customers happy.

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

#228

Post by qaq »

paulddraper wrote: post #179
qaq wrote: post #170

Earlier quoted context omitted.

https://lenovopress.com/lp0647-thinksystem-sr950-server

Interesting, though I don't see the price or any other purchasing details (at least on that page).

here's online configurator for Supermicro 8-way box https://www.rackmountpro.com/product/2570/7089P-TR4T.html

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

#229

Post by toast0 »

how_gauche wrote: post #182
Serow225 wrote: post #117

Earlier quoted context omitted.

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

A rational way of explaining it is -- what is my service level objective? If my SLO is for two nines of uptime, then I can be down for 3.65 days a year, and I can get away with single-homing something, or going with a simple hot-failover replicated setup. I just need to be pretty confident that I can fix it if it breaks within a few hours. If I need more nines of uptime than a single system could provide (and think a…

> If I need more nines of uptime than a single system could provide (and think about the MTBF numbers for the various parts in a computer, a single machine is not going to give you even three nines of uptime).

Three nines is 8 hours and 45 minutes. In my experience with quality hardware, at a facility with onsite spares, that gives you two to three hardware faults, assuming your software and network is perfect, which I think is a fair assumption :)

Definitely the hardest problem when you switch to a distributed database is you have to contemplate failure. When your SPOF database is down, it's easy to handle, nothing works. When your distributed database partially fails, chances are you have a weird UX problem.

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

#230

Post by qaq »

jandrese wrote: post #192
paulddraper wrote: post #179

Earlier quoted context omitted.

Interesting, though I don't see the price or any other purchasing details (at least on that page).

Pretty sure once you're talking about 12TB of memory it goes to "call for pricing".

I am guessing that it would be in 250-270K range
Post reply on HN