Yale Researchers Prove That ACID Is Scalable

An anonymous reader writes "The has been a lot of buzz in the industry lately about NoSQL databases helping Twitter, Amazon, and Digg scale their transactional workloads. But there has been some recent pushback from database luminaries such as Michael Stonebraker. Now, a couple of researchers at Yale University claim that NoSQL is no longer necessary now that they have scaled traditional ACID compliant database systems."

Comments

Re:I hate SQL and Databases in General...

[poet]

Spoken with proud ignorance.

Anyone who has properly scaled an application knows the database isn't the problem. If it was, it wouldn't take 12 applications servers to bring the thing to its knees. That said, most of your gripes equate to:

I am not a DBA and therefore I do not understand DBA and therefore I must complain.

Further SQL has nothing to do with ACID. AT ALL!

Re:Pfah.

[Trieuvan]

It is if you use innodb .

Just in case anybody else doesn't know...

[elwin_windleaf]

From the Wikipedia Article (http://en.wikipedia.org/wiki/ACID)

"In computer science, ACID (atomicity, consistency, isolation, durability) is a set of properties that guarantee database transactions are processed reliably. In the context of databases, a single logical operation on the data is called a transaction."

Re:I hate SQL and Databases in General...

[Just Some Guy]

And don't get me started on stored procedures and the difficulty of using source code management with stored procedures.

That's easily solvable:

1. Create a subdirectory called "storedprocs" inside your SCM directory.
2. Inside that subdirectory, make files with names like "checkinvoice.sql" that store the sequence of commands required to create a stored procedure - one per file. Start each one with a statement like CREATE OR REPLACE FUNCTION myschema.checkinvoice([...]).
3. Manage those files with your SCM system. Group them by database, or by project, or by phase of the moon, or by whatever else makes sense to you.
4. To update every stored procedure you've ever written, or to build out a new database: cd storedprocs; psql < *.sql

Stored procedures don't have to be any more difficult to manage than any other code.

Summary

[azmodean 1]

Short Summary:
We make some claims about scaling ACID databases, but then don't support them.

Longer summary:
We don't like NoSQL and enjoy making baseless cracks about it such as it being a "lazy" approach.
In our paper we demonstrate that our unconventional version of an ACID database scales better than a traditional ACID database in a specific environment, while merely throwing away some robustness guarantees and changing how transaction ordering works.
No direct comparison to any NoSQL implementation is made.

So yea, I'm not holding my breath for companies to start migrating away from NoSQL.

Re:Pfah.

[DragonWriter]

Doesn't work so well if you've got a graph structure or a tree. If in a family tree, you want to find all 5'th descendants or all descendants of some guy, SQL won't make you happy.

A decade plus ago, and that would be true.

Standard SQL from SQL-99 on will, in fact, do this quite easily with via recursive Common Table Expressions. Now, some SQL-based DBMSs don't support enough of the standard to use this, but, current versions of, I believe, DB2, Firebird, PostgreSQL, and SQL Server all implement standard CTEs well enough to do those examples in SQL fairly directly, and Oracle has its own proprietary syntax (CONNECT BY) that works for the examples that you pose, though its less general than SQL-99 recursive CTEs.

Re:Pfah.

[QuoteMstr]

An ACID compliant RDBMS can't even get read access to the user, car, friend, picture and pet_survey_answer table set as long as any of the million users of the system is making a change to his data, even if the application only locks one table at a time for write access, let alone the problem of a million users trying to gain write access to the same table at the same time.

You have no idea what you're talking about, probably because your brain has been irreversibly warped by MySQL. Concurrent writing is widely-supported.

Hint: MVCC.

Re:Pfah.

[LurkerXXX]

An ACID compliant RDBMS can't even get read access to the user, car, friend, picture and pet_survey_answer table set as long as any of the million users of the system is making a change to his data, even if the application only locks one table at a time for write access, let alone the problem of a million users trying to gain write access to the same table at the same time.

Wow. Just wow. Any serious ACID complient RDBMS can do that with no problem.