Graph Databases for Beginners: ACID vs. BASE Explained

When it comes to NoSQL databases, data consistency models can sometimes be strikingly different than those used by relational databases (as well as quite different from other NoSQL stores). The two most common consistency models are known by the acronyms ACID and BASE. While they’re often pitted against each other in a battle for ultimate victory, the fact remains that both consistency models come with advantages – and disadvantages – and neither is always a perfect fit. In this “Graph Databases for Beginners” blog series, I’ll take you through the basics of graph technology assuming you have little (or no) background in the space. In past weeks, we’ve tackled why graphs are the future, why data relationships matter, the basics (and pitfalls) of data modeling, why a query language matters and why we need NoSQL databases. This week, we’ll discuss the key differences between ACID and BASE data consistency models and what their various trade-offs and advantages mean for your database transactions.

The ACID Consistency Model

Many 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.

Consistent

• On the completion of a transaction, the database is structurally sound.

Isolated

• Transactions do not contend with one another. Contentious access to data is moderated by the database so that transactions appear to run sequentially.

Durable

• The results of applying a transaction are permanent, even in the presence of failures.

ACID properties mean that once a transaction is complete, its data is consistent (tech lingo: write consistency) and stable on disk, which may involve multiple distinct memory locations. Write consistency can be a wonderful thing for application developers, but it also requires sophisticated locking which is typically a heavyweight pattern for most use cases. When it comes to NoSQL technologies, most graph databases (including Neo4j) use an ACID consistency model to ensure data is safe and consistently stored.

The BASE Consistency Model

For 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.

Soft-state

• Stores don’t have to be write-consistent, nor do different replicas have to be mutually consistent all the time.

Eventual consistency

• Stores exhibit consistency at some later point (e.g., lazily at read time).

BASE properties are much looser than ACID guarantees, but there isn’t a direct one-for-one mapping between the two consistency models. A BASE datastore values availability (since that’s important for scale), but it doesn’t offer guaranteed consistency of replicated data at write time. Overall, the BASE consistency model provides a less strict assurance than ACID: data will be consistent in the future, either at read time (e.g., Riak) or it will always be consistent, but only for certain processed past snapshots (e.g., Datomic). The BASE consistency model is primarily used by aggregate stores, including column family, key-value and document stores.

Navigating ACID vs. BASE Trade-offs

There’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. Catch up with the rest of the Graph Databases for Beginners series:

• Graph Databases for Beginners: Why Graphs Are the Future
• Graph Databases for Beginners: Why Data Relationships Matter
• Graph Databases for Beginners: The Basics of Data Modeling
• Graph Databases for Beginners: Data Modeling Pitfalls to Avoid
• Graph Databases for Beginners: Why a Database Query Language Matters
• Graph Databases for Beginners: Why We Need NoSQL Databases
• Graph Databases for Beginners: A Tour of Aggregate Stores
• Graph Databases for Beginners: Other Graph Data Technologies

The post Graph Databases for Beginners: ACID vs. BASE Explained appeared first on Neo4j Graph Database.