Slashdot Mirror
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."
... because on every application I have ever worked on, the Database has always been the performance bottleneck. Testing of DB applications is always a problem, because the running of tests generally changes the database, rendering tests unrepeatable without reseting the database. Configuring applications to use this database or that database also ends up being a problem for most applications.
Furthermore, while programming in general has continued to progress through many languages, exploring many different ways to describe problems, SQL is still SQL. SQL is fixed in a syntax and written with naming conventions and styles that can best be described as neo-Cobal.
Bottom line: SQL is tedious, ugly, slow, and difficult to test. And don't get me started on stored procedures and the difficulty of using source code management with stored procedures.
Last gripe: A traditional Relational database imposes ACID overhead on every application, even if you don't really need it or use it. This is like a programming language that imposes a SORT overhead on all your data structures even if you rarely or never need to sort them.
Why is it that we continue to use a technology based on a 1960's view of a problem when clearly there ARE other solutions and ways to approach said problem?
I've never been sure why it is, but SQL (and the relational model it can be used to implement if you know what you're doing) attracts more wild-eyed fanatics than the Amiga and Ruby. Nowhere else will you find so many people so confidently and aggressively certain that the have the One True Way to do things, at least not without getting into actual religion. That anyone, anywhere does things differently (or even thinks about it) seems to deeply threaten them and provoke the sort of contempt that normal people reserve for child pornography. It frankly baffles me. DBA compensation isn't that good, and certainly not all DBAs can be such one-trick ponies.
The simple fact of the matter is that the relational model is probably the best general purpose data storage model we have, and it has the advantage of logical rigor and, as a result, the advantage of being extremely well-understood. But this in no way changes the fact that any general purpose approach, at least in some (but probably many if not most) cases, will be outperformed by a well-designed application-specific method. This remains the case no matter what your methodological hobby horse is, except in the tiny minority of cases where a truly optimal method can be rigorously proven.
Worse -- and this is true of all kinds of fanaticism, computer science-related and otherwise -- it tends to discourage research into unexplored areas that might yield new and better methods. E.F. Codd developed the relational model through precisely such an expedition into the mathematical unknown, and someday, the model that surpasses it (at least for certain cases) will be produced in the same way. It might be a descendant of one of the current so-called NoSQL approaches. It could be a reaction to their shortcomings. It might come from a completely unexpected corner. But wherever it comes from, you can be certain that we will enjoy its benefits later than we had to because it will have to push through the reactionary resistance of people who've stared at the relational model for so long that they can conceive of nothing else.
Proud member of the Weirdo-American community.
NoSQL is not really about scalability, it is about modelling your data the same way your application does.
There is a strong disconnect between the way SQL represents data and the way traditional programming languages do. While we've come up with some clever solutions like ORM to alleviate the problem, why not just store the data directly without any mapping?
I am not suggesting that SQL is never the right tool for the job, but it most certainly is not the right tool for every job. It is good to have many different kinds of hammers, and perhaps even a screwdriver or two.
In short, NeXT/Apple Enterprise Objects Framework. http://en.wikipedia.org/wiki/Enterprise_Objects_Framework