Database Reference
In-Depth Information
ACID, CAP, and BASE
Before we get too deep into Cassandra, it is important to understand some of
the basic concepts that surround databases so you know what concessions you may
have to make when choosing a system. There are three main sets of properties that
define what database systems are capable of. Those are ACID, CAP, and BASE.
ACID comprises some of the general properties of database systems. CAP covers
a little more about distributed systems. BASE is a little newer theory and includes
the practical considerations of implementing a distributed system.
Understanding these theories will help you to understand where some of the
design decisions come in, not only for Cassandra but also for your application
and how it is developed. The idea of building distributed applications and distrib-
uted systems often comes down to give and take. You may give up consistency for
availability. You may find it's wiser for your application's needs to give a little on
availability in favor of consistency. ACID, CAP, and BASE are the driving tech-
nical theories behind many of these decisions. It is important to understand the
trade-offs made in the design of the underlying systems (Cassandra) so you can
ensure that your application performs the way you expect it to perform.
ACID
ACID stands for
A
tomicity,
C
onsistency,
I
solation, and
D
urability. In order to un-
derstand ACID and how it relates to databases, we need to talk about transactions.
When it comes to databases, a transaction is defined as a single logical operation.
For example, if you are shopping online, every time you add an item to your shop-
ping cart, that item and its quantity make up the database transaction. Even if you
add multiple items or multiple quantities of the same item with a single click, that
entire shopping cart addition is just a single transaction.
Atomicity
means that each transaction either works or it doesn't. This is to say
that if any single part of the transaction fails, the entire transaction fails. This
should hold true for every situation related to a transaction that could cause a fail-
ure. Network failure, power outage, or even a node outage occurring at transaction
time should cause a complete transaction failure in an atomic system.
Consistency
ensures that when a transaction is complete, whether it is success-
ful or not, the database is still in a valid state. This means that any data written
to the database must also be valid. When writing data to the database, you also
need to include any database application-level rules such as constraints, cascades,
