
Scalable ACID - ithkuil
http://dbmsmusings.blogspot.com/2010/08/problems-with-acid-and-how-to-fix-them.html
======
jlgbecom
From a development standpoint, I don't quite understand the advantages of
NoSQL over SQL. I get that you don't have to have a rigidly defined table
structure, and that your data structure can change when your application
changes, but I guess I'm one of those curmudgeons that prefers rigidity over
permissiveness. I like that I have to think hard about my table structure and
models before and as I code. I also rarely feel bogged down by SQL, although
I've been using it for over a decade, so that helps.

As for scalability, as this post shows, I think the best thing to come out of
NoSQL is the race for greater scalability it has and will continue to inspire
in SQL solutions.

~~~
steveklabnik
There are some times when the standard normal form is a real pain, for
example, and your data fits better as a document or a simple key-value. I
mentioned one such instance for me here:
<http://news.ycombinator.com/item?id=1637903>

~~~
davidmathers
I think you're making the common mistake of confusing relational databases
with entity-relationship modeling.

I can't really figure out your foo example though, needs to be a bit more
specific.

------
ekidd
This looks interesting, but I still can't tell how it relates to the CAP
theorem. Are they sacrificing global consistency? Availability? Partition-
tolerance? Or do they have a subtle reformulation of these constraints which
allows them to "get around" the restrictions imposed by the CAP theorem?

Most of the popular NoSQL solutions were designed to run as large server
clusters, possibly distributed across multiple data centers. They're designed
to handle such problems as, "Our fiber backbone is down, and our database has
split into a 5,000 machine cluster and a 7,000 machine cluster! And it's three
days before Christmas!" (This is more or less the problem Amazon's database is
designed to survive.)

For any given "NoSQL" database, you want to figure out how they handle this
problem: Do they allow the 5,000 and 7,000 node datacenters to become
temporarily inconsistent? Do they block writes to the entire database? Do they
block writes to the 5,000 node database (because it doesn't have a quorum)?

Any of these options are valid—you just need to know what tradeoffs you're
choosing.

~~~
joe_the_user
The author basically doesn't believe CAP represents a good model of the
database tradeoffs;

 _"Over the past few weeks, in my advanced database system implementation
class I teach at Yale, I’ve been covering the CAP theorem, its implications,
and various scalable NoSQL systems that would appear to be influenced in their
design by the constraints of CAP. Over the course of my coverage of this
topic, I am convinced that CAP falls far short of giving a complete picture of
the engineering tradeoffs behind building scalable, distributed systems."_

[http://dbmsmusings.blogspot.com/2010/04/problems-with-cap-
an...](http://dbmsmusings.blogspot.com/2010/04/problems-with-cap-and-yahoos-
little.html)

------
michael_dorfman
_Our view (and yes, this may seem counterintuitive at first), is that the
problem with ACID is not that its guarantees are too strong (and that
therefore scaling these guarantees in a shared-nothing cluster of machines is
too hard), but rather that its guarantees are too weak, and that this weakness
is hindering scalability._

That is indeed counter-intuitive at first, but they make a good case. I'm
impressed with the idea, and hope to follow this more closely. Anyone know any
other research on the subject?

------
jleader
I only skimmed the paper pointed to by the blog post, but one quote jumped out
at me:

"Hence, in an era where disk reads caused wild variation in transaction
length, allowing nondeterministic reordering was the only viable option."

In other words, when all your data is in ram (possibly distributed across a
cluster of machines connected by a relatively fast network), the performance
tradeoffs are very different than when your data is on rotating mechanical
disks.

I don't know that I'm convinced that their approach is better, but they've
certainly given me something to think about (and re-read in more detail
later).

------
prodigal_erik
This sounds a lot like optimistic vs. pessimistic concurrency control, but
over the set of _all_ transactions in flight. You proceed assuming none of
them are going to fail, but if any of them do, you're really screwed--you have
to abort all of them and roll back to the last valid state to accept any more.
Still, if we can stop rolling our own half-assed transactions over a set of
feature-poor data stores, we'll avoid a lot of ugly problems.

~~~
btilly
If I read the article correctly, one requirement of their system is that
transactions have to be defined in such a way that all transactions succeed
for some definition of success.

------
richchan
The idea does sound interesting - so it looks like they are trying to reduce
the amount of network handshaking by imposing a stricter isolation.

I am not sure I am convinced by their results though. They say their
deterministic system seems viable when comparing its performance to
traditional systems under short in-memory transactions. That is a special case
that is clearly in their favor though. In that situation, the amount of time
spent in processing data is greatly reduced so the network overhead becomes
much more significant - so the system that does less network communications
will obviously win...

I guess it may potentially be good for in-memory database systems for stuff
like OLTP apps (e.g. VoltDB and TimesTen), but then I think most OLTP apps are
okay with a more relaxed isolation...

~~~
ora600
Daniel Abadi is one of the authors of the HStore paper that VoltDB is based
on. It looks like the deterministic order system is using similar requirements
and assumptions.

------
steveklabnik
I think this would be better without the adversity. Nobody has to 'win' or
'lose' on 'either side' of 'the debate.' The whole way this is framed (by
everyone, not just this) irks me.

Different tools for different cases. Polyglot persistence is the way forward.

~~~
zacharypinter
Odd... I didn't find the tone of the article to be at all confrontational. The
author gave a great summary of the NoSQL movement, its goals, and how his team
has an idea that might accomplish many of those goals in a different way.

~~~
steveklabnik
If there weren't so many "ZOMG NOSQL SUCKS" articles recently, I might agree
with you, but "The poorly kept secret is that it's all about scale, if RDBMS-s
would scale, nobody would NoSQL, and by the way, it's a lazy solution anyway!"
in the first few paragraphs triggered my "I'm really getting sick of this"
reaction.

------
richardmarr
"In our opinion, the NoSQL decision to give up on ACID is the lazy solution to
these scalability and replication issues."

They had me up until they called NoSQL "lazy" and claimed NoSQL solutions
"give up on ACID". They aren't lazy and a lot of them support ACID, or most of
it.

From that point on this veers away from logic and moves towards a self-
justified argument. Tools are just tools. If you need immediate consistency
then go for an immediately consistent solution, if you don't then you should
feel free to take advantage of the performance gain of eventual consistency.

~~~
lemming
The thing is that implementing ACID is, well, atomic - you either support it
or you don't. Anything else is one of a series of different types of
compromise. All currently available NoSQL systems I'm aware of compromise it
very heavily, resulting in greatly increased programmer complexity for the
types of applications that really require something that looks like ACID. I'd
be interested to know which ones you think support ACID - as far as I'm aware
none of them claim to support anything like it (with the possible exception of
VoltDB, which has its own set of problems).

~~~
jbellis
Scalaris has supported ACID transactions for years, but it never caught on
because at scale you care more about availability than about having
transactions: <http://twitter.com/Werner/status/1008722501>

~~~
jhugg
If you're counting important things (money, inventory, etc), being up with the
wrong answer can be worse than not being up.

------
azim
_In summary, it is really hard to guarantee ACID across scalable, highly
available, shared-nothing systems due to complex and high overhead commit
protocols, and difficult tradeoffs in available replication schemes._

It's hard, but it's doable. I find it quite striking that no one ever seems to
mention the two leading high performance parallel databases, HP Neoview and
Teradata. Is it that people don't realize they exist?

~~~
aweisberg
Neoview and Teradata are OLAP databases. OLTP is a different problem.

~~~
gaius
I can tell you a hilarious story about a former employer who bought a Teradata
to run a trading system on...

------
runT1ME
Who uses serializable isolation level? I find that claim dubious, and I don't
think ordering the way he talks about is better than read committed.

------
rit
Academics writing papers is not the same thing as people actually solving
problems in production.

Not to be ornery about this or anything.

~~~
swannodette
Great production implementations can start from coders reading papers on a
rigorously explored idea.

