Acid And Base – Graph Databases for Beginners

Acid And Base  – 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).

For upon | 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 (please someone make a video of that), both consistency models come with advantages – and disadvantages – and neither is always a perfect fit.

Let’s take a closer look at the trade-offs of both database consistency models.

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 graph technology is the future, why connected data matters, the basics (and pitfalls) of data modeling, why a database query language matters, the differences between imperative and declarative query languages, predictive modeling using graph theory, the basics of graph search algorithms and why we need NoSQL databases.

This week, we’ll take a closer look at the key differences between ACID and BASE database consistency models and what their trade-offs mean for your data 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 are 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 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 is 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 database world, ACID transactions are less fashionable as some databases have loosened the requirements for immediate consistency, data freshness, and accuracy 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 the reading time).

BASE properties, much looser than ACID guarantees, but they’re not 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 the reading 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 a 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, the perfect fit for use cases where data reliability and consistency are essential (banking, anyone?).

In the coming weeks, we’ll dive into more ACID/BASE specifics when it comes to aggregate stores and other graph technologies.

Catch up with the rest of the Graph Databases for Beginners series:

• • Why Graph Technology Is the Future
  • Why Connected Data Matters
  • The Basics of Data Modeling
  • Data Modeling Pitfalls to Avoid
  • Why a Database Query Language Matters (More Than You Think)
  • Imperative vs. Declarative Query Languages: What’s the Difference?
  • Graph Theory & Predictive Modeling
  • Graph Search Algorithm Basics
  • Why We Need NoSQL Databases
  • A Tour of Aggregate Stores
  • Other Graph Data Technologies
  • Native vs. Non-Native Graph Technology