Dude, is your database on acid?
If you walk by a group of developers chatting and hear something like that - take a moment before channeling your inner Nancy Reagan.
Acid, in this case, isn't a drug but an acronym more correctly written as ACID.
It stands for:
Let's dig into each of those a bit deeper:
Databases are often in a state of change. In database language a group of related smaller changes is called a transaction.
An example transaction is "take $500 out of my checking account and add it to my savings account".
Atomicity is saying that a transactions should either succeed or fail as a whole. If an internet connection goes down or power is lost half-way through the example transaction the $500 should show back up in the checking account.
Databases are usually created with rules around what makes the data valid. Simple data validation rules would be:
- No half-entered phone numbers
- No missing or made up zip codes
- No email addresses without a "@" and a known top level domain (.com, .edu. .net etc)
In a consistent database you would find no database records with exceptions to these rules. Attempting to complete a transaction with invalid data would result in the entire transaction being "rolled back" or undone.
Have you ever gotten into a bidding war on eBay?
You and 30 other people all trying to "snipe" that rare PEZ dispenser at the last possible second in the auction is a great example of why databases need to isolate transactions.
Isolation means each of those last-minute bids are unaware of each other. Ebay's servers will assign a sequential order to them, and if the slower bid needs data from the faster bid (like the newly updated selling price) it will have to wait until the faster bid is done processing.
Hard drives crash. Servers go down. Databases get corrupt.
But end users and customers shouldn't suffer because of that. Durability is the guarantee that once a transaction is complete it will be saved and recoverable.
MarkLogic and ACID
MarkLogic is a No-SQL database that we're getting pretty handy with here at Omni.
Reading up on the differences of SQL vs NoSQL databases, you might think that a NoSQL database wouldn't be ACID compliant.
The MarkLogic Developer Blog has all of the gory details, but key takeaways are that MarkLogic achieves ACID compliance by a combination of features including:
- Document Locks
- Commit Process
Relational databases usually have record locking, but a NoSQL database doesn't have records. It has documents. MarkLogic has document locks that keep data saved during updates and isolate transactions from each other.
In MarkLogic, when a document is updated it's actually copied and the updates are applied to the new version of the document. MarkLogic adds timestamps to documents so queries run only against the state of documents when the query started. If an update happens to the document while a query is running the query doesn't see that newest version - it's still looking at what was most recent when the query started.
Much like you would keep a personal journal to remember what happened throughout your day, MarkLogic keeps a journal of updates. The journaling happens before changes are committed. If the system fails, transactions can be rebuilt by looking at the journal.
MarkLogic has a commit process that happens at the end of a transaction. MarkLogic ensures that the entire transaction succeeds or fails, even when the data is stored across multiple hosts.
Need a Hit of ACID?
If you think your application needs both a NoSQL database and ACID compliance, give us a call. We can talk through how MarkLogic might just be the solution you are looking for.