News for hackers. Stuff that matters.
Re:Scalable ACID by ekidd on Wednesday September 01, 2010 @03:53PM (#1654017)
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.

Re:Scalable ACID by joe_the_user on Wednesday September 01, 2010 @07:03PM (#1654637)
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...

Re:Scalable ACID by amalcon on Wednesday September 01, 2010 @04:19PM (#1654112)
Basically, it doesn't relate to the CAP theorem. ACID is largely orthogonal to CAP, the C notwithstanding. It sounds like the proof-of-concept sacrifices consistency (in the CAP sense): the model is one in which each node executes commands independently, but in a deterministic fashion, so they eventually look the same anyway.
Re:Scalable ACID by stuhood on Wednesday September 01, 2010 @08:05PM (#1654770)
I'm fairly certain they are talking about a CA system, since locks must be acquired for the tuples involved in a transaction (even if only long enough to determine an ordering id for the transaction). In the presence of a partition, it wouldn't be safe to acquire these locks.
Re:Scalable ACID by tbrownaw on Thursday September 02, 2010 @10:35AM (#1656258)
It's based on fully logically serializing all transactions, therefore it cannot tolerate partitions.