A Fully ACID NoSQL Database System
RavenDB is an ACID database that matches its counterpart’s performance on their non-ACID transactions and surpasses them when ACIDity is required.
RavenDB is a fully ACID NoSQL database system. While ACID compliance in NoSQL databases is generally synonymous with reduced performance, RavenDB is unique in that it suffers from no such penalty. The way it achieves this in large part comes back to its original design philosophy.
Table of contents
RavenDB’s ACID Origins
Back in the day data was stored on floppy disks, and the small quantities available were easily organized into structured segments suitable for relational SQL databases.
Now, unstructured data accounts for 98% of the information that flows in terabytes across a worldwide web of twenty billion interconnected devices.
To meet the world’s changing data needs, most database designers sacrificed the Atomicity, Consistency, Integrity, and Durability (ACIDity) of traditional relational databases to achieve functional performance in their new NoSQL counterparts.
RavenDB opted not to make this trade-off and instead insisted on fully ACID multi-document transactions from its beginnings in 2010. With this ideological design choice, there was necessarily a strong focus on optimization to keep its performance in line with its non-ACID competitors.
Built From the Ground up for ACID Performance
Today, ACID compliance is becoming an expected (and often essential) feature of modern NoSQL databases. Those who abandoned it initially have been forced to pick it back up – at least as an option. MongoDB, for example, finally introduced ACID multi-document transactions in 2018 (with a dire warning that such transactions would incur a significant performance cost.)
In contrast, RavenDB has been focused on optimizing its ACID transactions for over a decade and has long since overcome the associated performance hurdles.
One example of RavenDB’s performance optimization is in the way it conducts transactions.
Traditional databases require at least four calls from the application to the server per transaction; one to start, one at the end, and at least two in between depending on the task. RavenDB does things a little differently using its custom-made storage engine ‘Voron’. Transactions are simplified by rolling all the calls into one package and delivering them in a single trip. Fewer trips mean faster transactions and less bandwidth use, and a custom storage engine means perfect integration and even better performance.
The results of such optimizations are a fully ACID database that matches its counterpart’s performance on their non-ACID transactions and surpasses them when ACIDity is required. In practical terms, RavenDB can achieve over 150,000 writes and 1 million reads per second on your average $1,000 server. (Or over thirteen thousand reads and one thousand writes per second on a Raspberry Pi.)
Support for Distributed ACIDity
In the past, a database was considered ACID if its nodes were individually ACID. But as traffic volume and user numbers increased, so too did the problems associated with simultaneous transactions targeting the same data on different nodes.
RavenDB was one of the first NoSQL databases to address the issue and provide ACIDity across an entire cluster.
Like many other databases, RavenDB uses the consensus algorithm ‘Raft’ to conduct its distributed transactions in an ACID manner. The algorithm requires that every call in a transaction be approved by the majority of nodes. If any aren’t, the entire transaction will fail.
Imagine if a government had to vote on each line of a budget separately, with a disagreement at any point causing the whole long process to be abandoned. RavenDB sidesteps this bureaucracy; the all-in-one transactions mentioned earlier conveniently apply to Raft transactions as well.
A Future-Proof ACID Database
With a high standard of fully-ACID performance and functionality and an inherent commitment to its improvement, RavenDB does something it’s very hard to give up on; It lets you take ACIDity for granted.