Live data from Hacker News

NewSQL databases fail to guarantee consistency and I blame Spanner

dbmsmusings.blogspot.com

141–150 of 319 posts

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

#141
post #40

Earlier quoted context omitted.

"This is a good read" is a statement of opinion. You're free to assign whatever value you like to the op's opinion, but that opinion is "content" in and of itself. "The article has false claim" is a statement of fact. A vague statement of fact about a non-obvious topic that puts no effort into providing concrete examples and reasoning is pretty much worthless.

Adding qualifiers makes a statement have less content? Please try to imagine using this questionable argument in any other context... It's a controversial topic and TFA was written by someone with a commercial interest. Everything is opinion. The level of comment-policing I see here makes me quite suspicious of everything in TFA. [EDIT:] aargh I'll never learn every discussion that starts with "content-free" cliche g…

If you're suspicious about me, it's not very well-founded, considering my main comment thread on this story takes issue with the blog's claims: https://news.ycombinator.com/item?id=18039801

I just prefer to have discussions about specific things, not posturing and innuendo.

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

#142
Consistency is a requirement that holds us back deeply. Implementing constency with eventually voted know-all masters are also holding us back. Looking at this makes an engineers heart cringe. In fact the current architecture is only slightly better than what we had in 2005, more than 10 years ago. And if it runs not on google or amazon clouds, and therefore on UNRELIABLE networks, the voting itself can fail and you have a centralized system without center. And while we claim that we need a central point of knowledge that is at sync throughout the whole system, the whole world AROUND the IT works completely without being in sync and completely without knowing it all (sometimes even having no knowledge or assumed but wrong knowledge), at a scale that IT systems only to some degree come close to nowadays.

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

#143
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 think it would be helpful to move the disclaimer to the top of the post, just for clarity's sake. Is there a forecasted date on the release of the independent Jepsen study? Who is performing it? Thanks!!

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

#144
post #78

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

Also an "old fart", I would recommend postgresql first over any of these other databases. Solve the big data scaling problems when you actually have them. One database server with replication and failover is going to still solve 95-98% or more of the use cases on the web.

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

#145
> With 10ms batches, Calvin was able to achieve a throughput of over 500,000 transactions per second. For comparison, Amazon.com and NASDAQ likely process no more than 10,000 orders/trades per second even during peak workloads.

I haven’t worked with NASDAQ stream directly, but knowing how fast equities tick I find this “10,000 orders/sec” estimate quite low.

Not to mention that 10ms delay in confirming an order would be really terrible.

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

#146
post #104

Earlier quoted context omitted.

Spanner's approach requires help from hardware and several full time employees maintaining and ensuring the uncertainty guarantees. This increases the cost of the maintaining the system, which for Cloud Spanner is partially passed on to the end users. If you can build a system that doesn't require time synchronization, yet doesn't have any significant drawbacks relative to what Spanner provides, you'd be better off u…

> If you can build a system that doesn't require time synchronization, yet doesn't have any significant drawbacks relative to what Spanner provides, you'd be better off using this alternative system. But you describe exactly the drawbacks of giving up time synchronization: > The main downside of the first category is scalability. A server can process a fixed number of messages per second. If every transaction in the…

You beat me to it. Also, per

> Calvin was able to achieve a throughput of over 500,000 transactions per second. For comparison, Amazon.com and NASDAQ likely process no more than 10,000 orders/trades per second even during peak workloads.

Maybe if you are only considering the small scope of just the order transactions, but they are actually writing way more data to their databases such as logs, metrics, current state for things like shopping carts. In my experience, what teams have done is split their data off into their own siloed database to minimize scaling problems, but this becomes super painful when you want to join your data with others. If spanner can hold all of our data, scale, and handle joining across all of it, that sounds like a huge win.

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

#147
post #78

Earlier quoted context omitted.

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

It's a struggle for me, too. People sometimes rest on their assumptions even though new technologies and paradigms can invalidate old rules (I'm sure everyone has lots of examples).

I found that constant communication and scenarios help bridge the gap between how they think things work and how you do. It doesn't always work - a lot of time people don't care to discuss things in detail.

But sometimes it worked and the other person came to realize a new way of thinking. Sometimes the discussion made me realize I was the person using invalid assumptions :)

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

#148
post #101
post #78

Earlier quoted context omitted.

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 think part of this is that most of the common knowledge about scaling is hard fought from the 90s/2000 era. eBay got bigger and bigger Sun boxes to run Oracle, until they couldn't get anything bigger -- then they had a problem and had to shard their listings into categories, etc. In the last few Intel cpu generations, computation performance has had small gains, but addressable memory has doubled about every other…

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 scripts / xargs -P instead of messing with cluster configs.

You can crunch a lot of data on those machines as long as you use all the cores. 32x is the difference between a day and less than an hour, so we should all make sure we are using it!

Common languages like node.js, Python, R, OCaml, etc. do NOT let you use all your cores "by default" (due to GILs / event loop concurrency). You have to do some extra work, and not everyone does.

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

#149
post #52

Earlier quoted context omitted.

So yes, Google can be very impressed with Google. But I'm not sure that's the issue here. 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? I think it's a very common pattern that a product has some set of trailblazer users who find issues before the people who make the product. Also, I think you're over-i…

If some condition existed that exceeded GPS intended design, you most certainly wouldn't learn of it first from some random anecdote on HN.. more likely the front page of the BBC as the transportation system instantly collapses So the anecdote itself is noise, it's intended to show how seriously intractable a problem accurate time is, but it doesn't do that, instead it only demonstrates OP's lack of familiarity with…

A single satellite mildly misbehaving on occasion won't necessarily cause catastrophe. You're normally connected to more than the requisite 3 satellites anyway, so you might notice less accuracy, but not anything terrible.

Most of these systems are designed to work if you lose GPS entirely, so they fail gracefully.

Planes won't actually fall out of the sky if GPS makes mistakes. That's y2k fearmongering.

Why is it hard to believe that a group using GPS for a unique purpose has unique needs and detect unique issues?

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

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

Great read, thank you for sharing. Do you have any opinion on the design of Eris[0]? Consistency is achieved with extra hardware, but that hardware is a network-level sequencer.

[0]: https://syslab.cs.washington.edu/papers/eris-sosp17.pdf

Post reply on HN