Whats wrong with RDBMS & its ACID properties?

My last blog post claimed the downfall of the Relational Databases. Most Database Management systems in the market promise ACID properties out of the box. ACID stands for

• Atomic: A transaction as a whole atomic unit succeeds or fails.
  
• Consistent: A transaction cannot leave the database in an inconsistent state.
• Isolated: Transactions cannot interfere with each other.
• Durable: Completed transactions persist, even when servers restart etc.

At the outset these properties seem indisputable and all databases seem to have it; atleast that is what we all have been believing for so long!

But todays' highly scalable internet applications have different set of demands that is at odds with these ACID properties. For example,

• distributing a database to more than one machine becomes inevitable as your website gets more and more traffic; It becomes impossible to get an acceptable response time given problems like network delays & failures.
• Scaling-up one database node endlessly is an impossible task because hardware failure can never be ruled out(atleast for now). Downtime is simply unacceptable.
  
• providing caching mechanisms will be conflicting with the 'Consistent' property, due to the existence of a possibility that the database can be updated without the cache updates getting completed.

This conflict is explained in a simple way by Brewer's CAP Theorem, which says that in a distributed system(which most internet scale applications are) if you want consistency, availability, and partition tolerance, you have to settle for two out of these three properties. Find a bit more detailed discussion on the CAP theorem here.

CAP theoram says that ONLY ACID properties will have problems with scalable distributed systems; Thankfully, we have an alternative called BASE!
BASE is an acronym for

• Basic Availability
• Soft-state
• Eventual consistency

Rather than requiring consistency after every transaction, it is enough for the database to eventually be in a consistent state. (Accounting systems do this all the time. It’s called “closing out the books.”) It’s OK to use stale data, and it’s OK to give approximate answers.

It’s harder to develop software in the fault-tolerant BASE world compared to the fastidious ACID world, but Brewer’s CAP theorem says you have no choice if you want to scale up. However, as Brewer points out in this presentation, there is a continuum between ACID and BASE. You can decide how close you want to be to one end of the continuum or the other according to your priorities.

Source: http://www.johndcook.com/blog/2009/07/06/brewer-cap-theorem-base/

Bookmark/Share this post with: