Skip to main content

CAP & ACID

CAP and ACID are two distinct terms that are used often in database world, where ACID is used to define properties of a database and CAP is actually used to determine distributed systems nature.
ACID stands for
  • Atomicity
  • Consistency
  • Isolation
  • Durability
Before going into the meaning of these terms one should be fairly aware of transactions. A transaction is like a unit of work which may comprise of multiple write operations or just a single operation. Treating a set of operations like this actually enables databases to maintain ACID properties.
Atomicity - Either all statements/queries inside a transaction happen or none of it does. In layman terms, if you start a transaction saying I want these 5 queries to be run. The database will make sure that either all of 5 queries are successful or none of them is. So if 5th query fails automatically the previous 4 queries effect will be wiped off.
Consistency - This ensures that whatever data you put into your database does not violate the rules that you have set for that type of data structure. This also includes the rules for related data and so forth.
Isolation - Every transactions run independent of other transactions. No transaction can refer to the data which is being manipulated by other transaction until it finishes.
Durability - Once a transaction has been committed it is stored in a durable medium (hard disk). This ensures even after crashes or restarts the database will have its state preserved.

CAP stands for
  • Consistency
  • Availability
  • Partition Tolerance
CAP is basically applied to a distributed system architecture where database is not just a single machine but is a set of nodes over a network, say 5 different machines running same database connected through network.
Consistency - Although some confuse CAP's consistency with ACID's one, it is entirely of different meaning when it comes to distributed system. It means that all the nodes will always have latest data, so it doesn't matter from which node you read, you will always get the latest copy.
Availability - This means that a system will always be available i.e. respond to requests even if a node goes down. Although this does not guarantee that other nodes will be in sync with unavailable node.
Partition Tolerance - This means system should be able to tolerate a failure in internal network i.e. communication between nodes. This means that nodes are individually able to serve the clients but are unable to communicate with each other.
This theorem is actually used to describe a system as either CP or AP, there cannot be a practical CA distributed system. In a cluster the nodes transmit the data to each other to maintain its consistency. When does this happen is the question.
In an AP system, the system still functions even if a single node is down. This does not ensure consistency since the failed node might have not updated other nodes with its operations. In this case the running nodes will give outdated data to the clients.
In an CP system, the consistency is of priority. So if a node goes down though the system can run, it chooses to stop responding to requests so that other nodes do not get ahead of failed node in terms of data. When the failed node is restored the system will be back up.

Comments

Popular posts from this blog

Guide : Spring Boot with Apache CXF for REST services

In this series of guide, we are going to explore writing REST services with Apache CXF using Spring Boot. The project is build using maven. I assume that you already know how to use maven. Step 1 : Adding dependencies for Spring Boot By default you have to inherit the parent pom of spring boot, but that cannot be followed everytime, so I use an alternative to that. I basically add spring boot pom as dependency so that it brings all the dependencies. <properties> <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding> <project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding> <java.version>1.8</java.version> <spring.version>1.4.3.RELEASE</spring.version> <cxf.version>3.1.10</cxf.version> </properties> <dependencies> <dependency> <!-- Alternative to inheriting from parent spring pom --> <groupId>org.springframework.boot&l

OOPs simply explained

What is OOPs ? It is Object Oriented Programming. It comprises of Polymorphism Encapsulation Inheritance Abstraction Already lost me ? Now here it is read about OOPs as if you deal with it every day. Let's take at OOPs from a Corporate world point of view. There is an organization which comprises of several employees which form a hierarchy. Now every employee has their way of working, some work hard, some like to delegate and some are smart. Though everyone does work in office, they do it in their own way. This is Polymorphism (implementing a function differently while keeping the semantics of function same). Employees are after all humans, we all have secrets. We have our own perspective which we may or may not share with everyone i.e. we have state and behavior only accessible to us. We share some of our secrets with our closest friends, some of our perspective to a group of people depending upon our status. In the end we do keep everything close and private, nothing

Enabling CXF goodies in Spring Boot

In this post we are going to add some of the CXF features to our existing app that we developed in  previous post . These features are : ID Logging Jackson Provider for POJO to JSON conversion Swagger 2 documentation Step 1: Configuration class Create a RestServer class in config package as shown below package org . blog . config ; import com.fasterxml.jackson.jaxrs.json.JacksonJsonProvider ; import org.apache.cxf.feature.LoggingFeature ; import org.apache.cxf.jaxrs.swagger.Swagger2Feature ; import org.springframework.context.annotation.Bean ; import org.springframework.context.annotation.Configuration ; /** * Created by Anand_Rajneesh on 3/23/2017. */ @Configuration public class RestServer { @Bean public JacksonJsonProvider jsonProvider (){ return new JacksonJsonProvider (); } @Bean public LoggingFeature loggingFeature (){ return new LoggingFeature (); } @Bean public Swagger2Featur