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 Backfill the Data in Airflow

In Apache Airflow, backfilling is the process of running a DAG or a subset of its tasks for a specific date range in the past. This can be useful if you need to fill in missing data, or if you want to re-run a DAG for a specific period of time to test or debug it. Here are the steps to backfill a DAG in Airflow: Navigate to the Airflow web UI and select the DAG that you want to backfill. In the DAG detail view, click on the "Graph View" tab. Click on the "Backfill" button in the top right corner of the page. In the "Backfill Job" form that appears, specify the date range that you want to backfill. You can use the "From" and "To" fields to set the start and end dates, or you can use the "Last X" field to backfill a certain number of days. Optional: If you want to backfill only a subset of the tasks in the DAG, you can use the "Task Instances" field to specify a comma-separated list of task IDs. Click on the "Star...
Post a Comment
Read more

What is BigQuery?

BigQuery is a fully-managed, cloud-native data warehouse from Google Cloud that allows organizations to store, query, and analyze large and complex datasets in real-time. It's a popular choice for companies that need to perform fast and accurate analysis of petabyte-scale datasets. One of the key advantages of BigQuery is its speed. It uses a columnar storage format and a Massively Parallel Processing (MPP) architecture, which allows it to process queries much faster than traditional row-based warehouses. It also has a highly optimized query engine that can handle complex queries and aggregations quickly. BigQuery is also fully integrated with other Google Cloud products, making it easy to build end-to-end data pipelines using tools like Google Cloud Storage, Google Cloud Data Fusion, and Google Cloud Dataproc. It can also be used to power dashboards and reports in tools like Google Data Studio. In addition to its speed and integration capabilities, BigQuery has a number of advance...
Post a Comment
Read more

Difference between ETL and ELT Pipelines

ETL (Extract, Transform, Load) and ELT (Extract, Load, Transform) are two common architectures for data pipelines. Both involve extracting data from one or more sources, loading the data into a destination system, and possibly transforming the data in some way. The main difference between the two approaches is the order in which the transform and load steps are performed. In an ETL pipeline, the transform step is typically performed before the data is loaded into the destination system. This means that the data is cleaned, transformed, and structured into a form that is optimized for the destination system before it is loaded. The advantage of this approach is that it can be more efficient, since the data is transformed once and then loaded into the destination system, rather than being transformed multiple times as it is queried. However, ETL pipelines can be inflexible, since the data must be transformed in a specific way before it is loaded, and it can be difficult to modify the pip...
Post a Comment
Read more