Skip to main content

What is CAP Theorem?

CAP Theorem states that a Distributed Database System can only have 2 out of 3 properties from Availability, Consistency, and Partition Tolerance. This means that every Big Data Engineer needs to do a trade-off between these three based on the use-case and Business requirements. It is very important for any Data engineer to understand the CAP Theorem and apply it when deciding the appropriate tools for the task in the hand. Let's discuss each of the properties in detail.



1. Availability 

This condition states that every request (read/write) will get a response on Success or Failure. That means every node in the system must return a response in a reasonable amount of time. This could be only possible if the system remains operational all the time. Hence, the databases are time-independent as they should be available all the time. Therefore if any two records are added to the database we don't know which one was added first and the output could be either one of them. Now let's take an example of Real-Time Streaming Data where the order and time of the events are important for the use case. High Availability condition is not appropriate in this case.

2. Consistency

This condition states that all the nodes in the system must have the same copy of the data, so for all the read requests all the nodes return the most recent write and same data. Therefore if any two records are added to the database, each of them will come with a certain timestamp and whenever the read request is generated then the most recent record will be returned. At the start or end of the transaction, the system should be in a consistent state, although during the transaction process the system can be in an inconsistent state any error would lead to a rollback of the transaction. 

3. Partition Tolerance

This condition states that the system continues to operate despite the network failure or network partition (a situation where two nodes are up and running but cannot communicate with each other) this is because the data is replicated across different nodes to keep the system fault-tolerant during the network failure. For most of the distributed system partition tolerance is a must and you must always do a trade-off between Consistency and Availability. Let's understand it better with the below case

Consider you have two nodes A and B in the master-master setup. Now, during the network partition i.e. when A and B can't communicate with each other and they can't sync updates, you have two choices

1. Either allow the nodes to get out of sync - Give up Consistency
2. Or make your cluster non-operational or make it unavailable when the node goes down - Give up Availability

Now let's look at the combination of these properties 

1. CA 

In these systems, the data is consistent between all the nodes, and also the system remains operational all the time (high Availability). So as long as all the nodes are up and available, and if you do read/write from any node, it will return the same data. But, if you ever develop a partition between the nodes then the data will be out of sync and it won't re-sync ever when the network partition is resolved (you can't achieve Partition Tolerance).

2. CP

In these systems, the data is consistent between all the nodes, and during a network partition, the system continues to run as it has Partition Tolerance. But you have to give up Availability.

3. AP

All the nodes remain online even if there is a partition (communication break) between the nodes and it will re-sync whenever the partition is resolved, but there is no guarantee that all the nodes will return the same data (high Consistency)

NOTE: The Consistency in CAP Theorem and Consistency in ACID properties are a totally different concepts. 

In ACID, it refers to the fact that any transaction should not violate the integrity constraints in the database.





Comments

Post a Comment

Popular posts from this blog

How to migrate the data between AWS and Google Cloud Platform

There are several ways to migrate data between Amazon Web Services (AWS) and Google Cloud Platform (GCP). Here are three common approaches: Use a Cloud Data Integration Tool: Both AWS and GCP offer a range of tools that can help you move data between the two platforms. For example, AWS Data Pipeline is a fully-managed data integration service that can extract data from various sources, transform the data as needed, and load the data into a destination system. On GCP, Cloud Data Fusion is a similar tool that can help you build, execute, and monitor data pipelines between various data sources and destinations. You can use these tools to create a data pipeline that moves data between AWS and GCP. Use a Command-Line Tool: Another option is to use a command-line tool, such as aws s3 cp or gsutil, to transfer data between AWS S3 and GCP Cloud Storage. For example, you can use aws s3 cp to copy data from an S3 bucket to your local machine, and then use gsutil cp to upload the data to Cloud ...
Post a Comment
Read more

Difference between Union and Union All in SQL

You might be using Union or Union All in your SQL code while doing Data Analysis or building Data Pipelines. Ever wondered what is the difference between them and how using one over another can be more efficient? Yes, there is a small yet significant difference between Union and Union All. Let's look at that by understanding each of them individually. 1. Union All  Union All basically allows you to concatenate the table that has a similar structure of tables. The important condition to have Union All of the tables is that both the tables should have the same number of columns. So when you take Union All of two tables what it does in the background is it directly joins the tables without removing duplicates or redundant records.   2. Union  Union is also similar to Union All except one difference that it removes the duplicates records before taking the Union of the tables.  There is one disadvantage of Union over Union All, that since it removes duplicated records bef...
Post a Comment
Read more

What is Shuffling in Spark

Shuffling in Spark is a mechanism that Re-Distributes the data across different executors or workers in the clusters.  Why do we need to Re-Distribute the data?    A) Re-Distribution is needed when there is a need of increasing or decreasing the data partitions in the situations below: When the partitions are not sufficient enough to process the data load in the cluster When the partitions are too high in numbers that it creates task scheduling overhead and it becomes the bottleneck in the processing time. Re-Distribution can also be achieved by executing the shuffling on existing distributed data collection like RDD, DataFrames, etc by using the "Repartition" and "Coalesce" APIs in Spark. B) During Aggregation and Joins on data collection in Spark, all the data records belonging to aggregation or join should reside in the single partition and when the existing partitioning scheme doesn't satisfy this condition there is a need to re-distributing the data in in...
Post a Comment
Read more