The ACID Consistency ModelMany developers are familiar with ACID transactions from working with relational databases. As such, the ACID consistency model has been the norm for some time. The key ACID guarantee is that it provides a safe environment in which to operate on your data. The ACID acronym stands for: Atomic
- All operations in a transaction succeed or every operation is rolled back.
- On the completion of a transaction, the database is structurally sound.
- Transactions do not contend with one another. Contentious access to data is moderated by the database so that transactions appear to run sequentially.
- The results of applying a transaction are permanent, even in the presence of failures.
The BASE Consistency ModelFor many domains and use cases, ACID transactions are far more pessimistic (i.e., they’re more worried about data safety) than the domain actually requires. In the NoSQL world, ACID transactions are less fashionable as some databases have loosened the requirements for immediate consistency, data freshness and accuracy in order to gain other benefits, like scale and resilience. (Notably, the .NET-based RavenDB has bucked the trend among aggregate stores in supporting ACID transactions.) Here’s how the BASE acronym breaks down: Basic Availability
- The database appears to work most of the time.
- Stores don’t have to be write-consistent, nor do different replicas have to be mutually consistent all the time.
- Stores exhibit consistency at some later point (e.g., lazily at read time).
Navigating ACID vs. BASE Trade-offsThere’s no right answer to whether your application needs an ACID versus BASE consistency model. Developers and data architects should select their data consistency trade-offs on a case-by-case basis – not based just on what’s trending or what model was used previously. Given BASE’s loose consistency, developers need to be more knowledgeable and rigorous about consistent data if they choose a BASE store for their application. It’s essential to be familiar with the BASE behavior of your chosen aggregate store and work within those constraints. On the other hand, planning around BASE limitations can sometimes be a major disadvantage when compared to the simplicity of ACID transactions. A fully ACID database is the perfect fit for use cases where data reliability and consistency are essential. In the next two weeks we’ll dive into more ACID/BASE specifics when it comes to aggregate stores and other graph technologies. Want to learn more about graph databases? Click below to get your free copy of the O’Reilly Graph Databases ebook and discover how to apply graph solutions to mission-critical problems at your enterprise.
About the Author
Bryce Merkl Sasaki, Editor-in-Chief, Neo4j
Bryce Merkl Sasaki is the Editor-in-Chief at Neo4j. He studied professional and creative writing for undergrad and has been freelancing for 7 years. Recently, he worked at an inbound marketing agency in Philadelphia as a copywriter before moving to California. When not working, he likes to spend his time working on his novel, looking for pickup soccer games and reading voraciously.
From the CEO
Have a Graph Question?
Reach out and connect with the Neo4j staff.Stackoverflow
Share your Graph Story?
Email us: email@example.com