ACID 2020: The Next Generation of Data Consistency
by Oren Eini
For decades, ACID and the relational database went hand in hand. As the pace and scope of data broke the mold of relational solutions, a new way had to be developed.
Nonrelational databases historically worked for things like a CMS or newsfeed, but for operations like financial transactions, its inability to insure data consistency made it useless to those who needed it most.
Until RavenDB came up with a solution by becoming the pioneer database to offer ACID in a nonrelational context. In 2010, RavenDB offered ACID consistency across multiple documents.
In doing so, large enterprises were able to attach an instance of RavenDB to millions of points of sale systems and enjoy the scale that is possible with NoSQL while holding on to the data safety they needed.
That was almost 10 years ago. In 2010, there were 1.8 billion internet users, mostly accessing the internet from their desktops. Times have changed.
The explosion of smartphones and other mobile devices have tripled the number of internet users to over 4 billion by 2020.
Traffic has increased over 100-fold. Unstructured data accounts for 98% of all information being passed along in the world. The need for databases to handle this tsunami wave of terabytes with nonrelational solutions has only intensified.
Include over 20 billion connected “things”, all moving data back and forth and you have a lot of data that needs to be processed in a nonrelational way.
The Challenge to the Old ACID Model
A database was considered ACID if it could be ACID by the individual node. The challenge comes in when waves of traffic hit your applications and multiple users try to do the same thing on different nodes.
Say 2 people want to book a plane ticket from London to Singapore. They both log onto a travel site that supports a 5-node data cluster with replication ability.
The user in London books his flight at the same time another user in Liverpool books hers. Two different nodes in the data cluster write the transaction.
What happens when you replicate to the cluster? One write will be committed to the database, and the other will be discarded in its entirety, likely frustrating a customer.
Imagine what happens when they reserve a night at a hotel or front row seats to a play.
ACID 2020: Clusterwide Consistency with Distributed ACID
To solve this problem, RavenDB has expanded its ACID feature from being ACID over multiple documents to being ACID over your entire cluster, enabling distributed ACID, the next step in data consistency.
Find out what RavenDB can do for you
The idea is simple: You can take a set of changes and send them to the entire cluster. Your set of changes will be applied, in atomic fashion, to all the nodes in the cluster only if they have been accepted by a majority of nodes. If not, then the entire transaction will be rejected and the user will be notified that the transaction didn’t go through.
This resolves the concurrency issue.
Only when a plane ticket order has been committed throughout the entire cluster will it be considered completed. Even use of inventory. If customer A purchases the last blood pressure machine, only when the majority of the cluster agrees that inventory is now zero will it be committed to the database and the user get a confirmation of purchase. If another user makes the same buy at the same time and it doesn’t replicate to the majority of nodes, he will get a notification that there are no more in stock.
Only when the entire cluster confirms that your write was committed to the majority of nodes, guaranteeing that it won't be overruled, do you get the confirmation that it was processed. No longer will you get the call from the travel agent telling you that due to "technical difficulties," you were bumped from your 5AM flight and got up in the middle of the night for nothing.
This is the next generation of ACID, a fully transactional solution that works in a NoSQL distributed data system to accommodate todays speed and scale of Big Data.