When Is “ACID” ACID? Rarely (2013)(bailis.org)
bailis.org
When Is “ACID” ACID? Rarely (2013)
http://www.bailis.org/blog/when-is-acid-acid-rarely/
27 comments
I've heard VoltDB has had a lot of problems with this, actually: https://forum.voltdb.com/showthread.php?552-Nodes-stop-talki...
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?
Unless you're speaking of something else you heard about on a more recent version?
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.
[deleted]
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.
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.
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.
Not really: https://en.wikipedia.org/wiki/ACID
He confuses ACID and isolation levels. Typical internet FUD.
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.
That sounds awfully close to the definition of serializability he's using.
Agreed.
Also, Microsoft SQL Server does support snapshot isolation. See: https://msdn.microsoft.com/en-us/library/tcbchxcb(v=vs.110)....
Also, Microsoft SQL Server does support snapshot isolation. See: https://msdn.microsoft.com/en-us/library/tcbchxcb(v=vs.110)....
But not for indexes...
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.
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).
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.
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.
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.
[deleted]
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?
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.
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.
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.
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.
[deleted]
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...