When Is “ACID” ACID? Rarely (2013) | Hacker News Reader

When Is “ACID” ACID? Rarely (2013)

bailis.org

54 pointsnstart24 comments

One of my favorite things about VoltDB, as one of the people who built it, is that its serializable isolation is actually a fundimental part of the architecture.

Many of these systems get slower as you turn up the isolation. VoltDB is faster because of isolation.

More here: http://voltdb.com/products/featuresbenefits/reasons-behind-v...

I've heard VoltDB has had a lot of problems with this, actually: https://forum.voltdb.com/showthread.php?552-Nodes-stop-talki...

As mentioned in my reply to that forum post, VoltDB includes a fault resolution protocol to prevent split brain (VoltDB will trade availability for consistency if required.) a couple of years ago, we decided to to enable that feature by default to maintain the serializability contract as the default choice.

Yeah, as Ryan said, no split brains possible in VoltDB for quite some time. We originally had split brain protection something you could enable for cloud deployments, but figured it wouldn't be worth the tradeoff if you had 5 machines in a rack connected directly. It turns out we made a bad choice and we fixed it.

Unless you're speaking of something else you heard about on a more recent version?

It would be more accurate to say, several SQL databases (that you may or may not have heard) of don't provide full ACID in the strongest sense, while MySQL, Postgres, and MS SQL Server all do if you pass the right flags.

In a world plagued by NoDBs, it seems like a very small point.

I found the article pretty poor in general. It equates use of lower isolation levels with use of NoSQL, despite the fact that RC still provides dramatically higher guarantees than a typical NoSQL DB - particularly when you add in the ability to use foreign keys.

Further, it counts 'well understood and quantifiable' consistency flaws as a negative, where in fact the whole point is that you can trade off isolation for performance in ways that are easy to mitigate for certain applications. By contrast, the consistency tradeoffs you make when using a NoSQL DBs are clearly rather poorly understood by the community at large.

> The textbook definition of ACID Isolation is serializability

Not really: https://en.wikipedia.org/wiki/ACID

He confuses ACID and isolation levels. Typical internet FUD.

Agreed.

Also, Microsoft SQL Server does support snapshot isolation. See: https://msdn.microsoft.com/en-us/library/tcbchxcb(v=vs.110)....

But not for indexes...

The link you give defines isolation like this: "The isolation property ensures that the concurrent execution of transactions results in a system state that would be obtained if transactions were executed serially, i.e., one after the other."

That sounds awfully close to the definition of serializability he's using.

You know you're being sold something solid if the vendor start talking about multi-phase commit and/or multi-version currency control.

If they just splash you ACID all over as a mantra to tell you their database is reliable, be wary.

For databases that persist to disk, it is for example not possible to do that asynchronously and be ACID. You need, at the very least, to journal every write before confirming the write.

Last but not least, it is not possible to have 100% bulletproof transactions. Even with 2PC, or 3PC. There is always a windows of opportunity for a failure to screw your transaction.

PostgreSQL uses serializable snapshot isolation (SSI) for the SERIALIZABLE level, which is a relatively new technique that doesn't have much of a performance penalty.

READ COMMITTED will probably remain the default forever though, because many applications aren't prepared for serialization failures (which should normally be retried).

Junk article. The important vendors are ACID. Just because the default isolation level isn't serializable doesn't warrant the conclusion.

One amusing thing is that every now and then there is an article stating that certain relational dbs aren't webscale because the default isolation level is too high.

You have to consider the capabilities in addition to the performance/guarantees trade-off.

A key/value store with SERIALIZABLE transactions isn't as useful as a system that allows multiple-statement transactions but only offers REPEATABLE READ.

Even though some anomalies are possible, SQL does a great job of eliminating some of the trickiest bugs, particularly on the error paths.

Did anyone else expect this to be an article about the drug LSD and the unreliability of its composition when being purchased at the street level?

I have to admit, for a brief moment when clicking the link, I did expect that.

No, but that does sound like it could be an interesting article.

Yes because this is a big issue. Many research chemicals are sold as being LSD. Though the effects can be similar, some of them have unknown side effects and a much lower 'overdose' level. It's practically impossible to overdose on LSD but something like NBOME can be dangerous in as little as 10 hits.

NBOME can be dangerous in two hits. And at smaller doses then you've taken previously.

It's an interesting series though, very visual.

Was incredibly disappointed when this turned out to not be the case. If I Could type out melting letters, this would be the right time.

Wow why does what you say melt and change colors then?... Anyhow, that's what I expected too

Dddddffffffssshhaawaaaaasoooooobuuuuuuu ch-ch-ch-ch-changes...

I definitely expected an article about Acid and the other research chemicals commonly masqueraded as "acid", when in fact they are dangerous research chemicals or hints of all sorts of drugs mixed together.

Reply on news.ycombinator.com