Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Consistency in Databases

DZone's Guide to

Consistency in Databases

How will you know if a database is strong or eventual consistent?

Free Resource

MariaDB TX, proven in production and driven by the community, is a complete database solution for any and every enterprise — a modern database for modern applications.

How will you know if a database is strong or eventual consistent?

The Rules

R + W > N

Ensures strong consistency. Read will always reflect the most recent write.

R=W= [Local_] QUORUM — Strong Consistency.

W + R <= N — Eventual Consistency.

W=1 — Good for fire-and-forget writes: logs, traces, metrics, page views, etc.

Definitions:

N= Replication Factor (number of replicas)

R= Number of Replicas read from (before the response is returned)

W= Number of replicas written to (before the write is considered a success)

QUORUM = (N/2 + 1) replicas read from before the response is a Return, and the same number of replicas written to before the write is considered a Success.

E.g. Suppose N = 2

Write one Read one = Weak

Write one Read All = Strong

Write All Read one = Strong

Write Quorum Read Quorum = Strong

E.g. Consistency Level in Cassandra

Consistency Level Write Read Consistency
Any 1 replica (including HH) - Weak
ONE 1 replica 1 replica Strong if N < 2, Else Weak as per R + W > N rule
TWO 2 replica 2 replica Strong if N < 4, Else Weak as per R + W > N rule
THREE 3 replica 3 replica Strong if N < 6, Else Weak as per R + W > N rule
QUORUM N/2 + 1 N/2 + 1 Strong
LOCAL_QUORUM
(to avoid latency issues
(dc_replicas)/2 + 1 (local Datacentre) (dc_replicas)/2 + 1 (local Datacentre) Strong
EACH_QUORUM
(useful in backup scenarios)
(dc_replicas)/2 + 1 (each Datacentre) (dc_replicas)/2 + 1 (each Datacentre) Strong
ALL N N

Strong


Consistency in MongoDB:

Below are write and read concerns in MongoDB.

Write Concern levels Description
0 Requests no acknowledgement of the write operation
1 Requests acknowledgement from the standalone mongod or the primary in a replica set.
number >1 valid only for replica sets to request acknowledgement from specified number of members, including the primary.
majority

Requests acknowledgement from the majority of voting nodes, including the primary.

Read Concern Levels Description
local reads against primary

reads against secondaries if the reads are associated with causally consistent sessions.
available reads against secondaries if the reads are not associated with causally consistent sessions.

unavailable for use with causally consistent sessions.
majority returns data that has been acknowledged by a majority of the replica set members
linearizable

returns data that reflects all successful majority-acknowledged writes that completed prior to the start of the read operation


linearizable is unavailable for use with causally consistent sessions.


Causal Consistency Session

Causal relationship means that an operation logically depends on a preceding operation. MongoDB executes causal operations in an order that respects their causal relationships, and clients observe results that are consistent with the causal relationships.

Consistency Levels and Guarantees

Consistency Level Guarantees
Strong Reads are guaranteed to return the most recent write
Bounded Staleness Consistent Prefix. Reads lag behind writes by at most k prefixes or t interval
Session Consistent Prefix. Monotonic reads, monotonic writes, read-your-writes, write-follows-reads
Consistent Prefix Updates returned are some prefix of all the updates, with no gaps
Eventual

Out of order reads

Causal Consistency Guarantees Description
Read your writes Read operations reflect the results of write operations that precede them.
Monotonic reads Read operation do not return results that corresponds to an earlier state of the data than a preceding read operation.
Monotonic writes Write operations that must precede other writes are executed before those other writes.
Writes follow reads

Write operations that must occur after read operations are executed after those read operations.

Image title

If we see the consistency in MongoDB implementation, it will be something like below:

Consideration Write Concern Read Concern Consistency
Real Time Order majority linearizable Strong
Read Your Own Writes causally consistent session causally consistent session Weak
Read Your Own Writes majority majority / linearizable

Strong


CAP Theorem

Image title

PACELC Theorem

If there is Partition:

Then system trade-offs between Availability and Consistency

Else system trade-offs between Latency and Consistency

Image title


Database can be configured in one of below way as mentioned as per PACELC theorem :

DDBS ( one of these --> )  P+A P+C E+L E+C
DynamoDB Yes Yes
Cassandra Yes Yes
Cosmos DB Yes Yes
Riak Yes Yes
VoltDB/H-Store Yes Yes
Megastore Yes Yes
BigTable/HBase Yes Yes
MongoDB Yes Yes
PNUTS Yes Yes
Hazelcast IMDG Yes Yes

Yes

ACID

Atomic: Atomic means “all or nothing;” that is, when a statement is executed, every update within the transaction must succeed in order to be called successful. There is no partial failure where one update was successful and another related update failed. The common example here is with monetary transfers at an ATM: the transfer requires subtracting money from one account and adding it to another account. This operation cannot be subdivided; they must both succeed.

Consistent:
Consistent means that data moves from one correct state to another correct state, with no possibility that readers could view different values that don’t make sense together. For example, if a transaction attempts to delete a Customer and her Order history, it cannot leave Order rows that reference the deleted customer’s primary key; this is an inconsistent state that would cause errors if someone tried to read those Order records.

Isolated:
Isolated means that transactions executing concurrently will not become entangled with each other; they each execute in their own space. That is, if two different transactions attempt to modify the same data at the same time, then one of them will have to wait for the other to complete.

Durable:
Once a transaction has succeeded, the changes will not be lost. This doesn’t imply another transaction won’t later modify the same data; it just means that writers can be confident that the changes are available for the next transaction to work with as necessary.

Image title

BASE

How do the vast data systems of the world such as Google’s BigTable and Amazon’s Dynamo and Facebook’s Cassandra deal with a loss of consistency and still maintain system reliability? The answer is BASE (Basically Available, Soft state, Eventual consistency). The BASE system gives up on the consistency of a distributed system.

Image title


Tunable Consistency is a term used in Cassandra for tuning the consistency levels.

Based on System requirement, it should be tuned accordingly for consistency.


Next Steps :

You may further explore on it, here are some related links :

https://www.mongodb.com/mongodb-architecture

http://cassandra.apache.org/doc/latest/architecture/dynamo.html#tunable-consistency

https://hbase.apache.org/acid-semantics.html

https://hadoop.apache.org/docs/stable/hadoop-project-dist/hadoop-common/filesystem/introduction.html#Consistency



MariaDB AX is an open source database for modern analytics: distributed, columnar and easy to use.

Topics:
consistency ,database ,rules ,mongodb ,cassandra ,cap theorem

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}