Big Data and CAP Theorem

In the world of NoSQL Databases, the scheme breaks down and begins to speak of concepts such as “Eventual Consistency” and “Theorem CAP”. Here, we will focus in this theorem.

In the last 10 years there was a revolution in the way of storing information. The Relational Databases weren’t the best solution for any application, because the volume of unstructured data increased, and added to this is the fact that the storage cost was exponentially reduced. That’s how NoSQL Databases were born, design to be scaled and distributed.

Recall that relational Databases are based on the concept of transaction, which consists in fulfilling 4 ACID properties:

  • Atomicity: if the transaction is a set of steps, they form a whole, they aren’t divisible into sub-steps.
  • Consistency and Integrity: only starts what can be finished. Data starts being a valid or consistent state and after executing the transaction they pass to another coherent state.
  • Isolation: two or more transactions made at the same time must be independent and do not affect each other.
  • Durability: If a transaction is successful, it will persist in the system.

In the world of NoSQL Databases, the scheme breaks down and begins to speak of concepts such as “Eventual Consistency”, which means that the consistency changes from being absolute to be relative to the degree of the application’s need, and “Theorem CAP”. We will focus in this theorem.

Introduction to CAP Theorem

Cap Theorem was developed by Eric Brewer in Berkeley University in the 2000’s.

He argues that it’s impossible that a distributed computer system can provide the 3 following properties at a time:

  • Consistency: When performing an operation you always have to receive the same information, regardless the node that process the order. It means that no matter which node that forms our Database receives an order, everyone must respond to the operation equally and must be transparent to us who effected it. All clients see the same version of data.
  • Availability: the system provides answers for all requests it receives, even if one or more nodes are down.
  • Tolerance to divisions:the system still Works even though it has been divided by a network failure.

CAP Theorem

Said in other words, CAP Theorem defines that a distributed system can guarantee no more than two of three properties mentioned before.

This graphic defines the theorem:

Best nearshore software company

Spaces defined by the CAP

From the graphic we can appreciate that four possible spaces are arising which can be categorized in any Databases:

  • ND Space:doesn’t get any Databases engine, is an empty set. This contradicts the CAP Theorem because with the latest technology it can’t accomplish with three of the Theorem properties.
  • CD Space: the engines of this space emphasize in the consistency and availability, data distribution doesn’t exist. It is the place that Relational Databases are positioned, although we can also find some NoSQL engines graph oriented.
  • CT Space:in this space, engines will favor the availability and tolerance of divisions, but that doesn’t mean they don’t offer any consistency, since this is relative and can’t guarantee between nodes.
  • DT Space:In this space tolerance of divisions and consistency are privileged, leaving aside certain level of availability. Facing a network division, these Databases couldn not get to respond certain types of enquires.

Although we are not presenting examples of NoSQL engines, it would be wrong to assume that all NoSQL Databases of the same type (to learn: key value, columnar, documentary, oriented graphs) will fall into the same space. Even many of them can be configured and be part of a different category from which comes from default (for example, an engine initially belongs to space by setting CD but then passes to CT).

Finally, it is important to highlight that the CAP theorem is not absolute but, like everything in the NoSQL world, is relative. This can be illustrated with the following scenario: consistency and availability don’t go together but they are not mutually exclusive either, so we could put both in grey, resigning some consistency or some of availability, to allow a greater degree of another attribute.

This was the first article from a series that we will publish about Big Data. We hope it have been useful. We will continue with more concepts, tools and other themes related to future publications.

Share this articleShare on LinkedInTweet about this on TwitterShare on FacebookShare on Google+Email this to someone
Go Back