Welcome to our whiteboard series. In these videos we'll dive into database basics and talk a bit about FoundationDB. Just so we're on the same page, FoundationDB is a NoSQL database that combines scalability, fault-tolerance, and high performance with incredibly powerful multi-key ACID transactions.
This is Part 1 of a 4-Part series explaining a bit about the "ACID" properties of database transactions. Every application needs a way of taking higher-level business tasks and converting them into lower-level operations that a database can understand, and that's what transactions let you do.
A transaction is a group of reads and writes that go back and forth between a client and a database and work together to change the data that's stored. Lots of things can go wrong here, but ACID makes sure that the database is always in a correct state. Today we'll start a group of videos by talking about the "A" in ACID, which stands for Atomicity. If a transaction has this property, it means that all the work gets done or none of it does. This is a crucial property of a database.
Suppose you've booked a long flight to LA, and you find out that the guy in the seat next to you has a carry-on full of snakes. Not cool. You need to switch seats. Switching seats requires two things: you have to both free up the seat you already have and get a new seat. If your database doesn't have Atomicity, you have two choices:
In the first option, you give up the seat you already have and then try to get the seat you want. But if someone else is also trying to switch to that seat, you could have already given up the old seat and not be able to get a new one. No seat is not good; you need to get to LA. The second option is to take the free seat you want and then try and give up the seat that you don't need anymore. But if boarding starts in the middle of the process, you might end up with two seats and the bill to go along with it. Not good.
If you have transactions with Atomicity, you can both give up the old seat and take the new one as if this were one single operation. There's no way to get stuck with no seats or with two: either you were able to change to a new seat or you're stuck with your old one. This is a crucial property for real-world operations.
Does your database have Atomicity? Maybe, but even some databases that claim to be ACID don't allow more than one row or document in a transaction. If your database documentation doesn't make it crystal clear, check out our website for a list of databases and their ACID claims. Maybe you're running a system without real ACID and your testing makes it seem like things are OK. The real problems lie when you have many clients at once: think of hundreds of travelers trying to change their seats all at once. And what about when there's a failure during production? You need Atomicity for real-world operations.
Why is this something that the classic databases have but most of the newer players don't support? It's not because it isn't important. It's just really hard to get right, especially when you're building a distributed database on a cluster.
When there's more than one computer working together to host the database, and there are many clients all at once, doing transactions reliably and fast is difficult. Hope you learned a bit about Atomicity in this video. Make sure to check back for our next video in this series on ACID properties!