AbstractIn the Year 2000, Dr.
Eric Brewer gave a speech entitled ‘Towards Robust Distributed Systems’ in a conference at the University of Carlifornia. This is where he posed his ‘CAP Theorem’ which states that it is not possible to build a performance of a Distributed System that satisfies Consistency, Availability and Partition tolerance at the same time- one has to be sacrificed. Twelve years later, Seth Gilbert and Professor Nancy Lynch situated the CAP theorem showing that it is one example of the most common tradeoff between Liveliness and safety in systems that are unreliable. Looking at the CAP in this state enables us to have a clear view of these tradeoffs and the way in which they can be put into practice. In this paper, I shall highlight the misconceptions about the CAP Theorem, criticism and alternative models to CAP theorem and future evolving systems in relation to CAP.IntroductionThe CAP theorem puts together three properties that are desirable C (consistency), A (availability), and P (partition-tolerance).
The CAP theorem states that in any distributed system where data from different locations is used, it is only possible to have not more than two of the three desirable properties (Lars, Rasmus, Christian, & N., 2014).More casually, the CAP theorem says that it is not possible to build a distributed database that is able to respond to each and every request and is able to return the results as expected each time. It is an impossibility output whereby something we may want to do is completely out of reach. This is very important because it is applicable to many distributed systems that have been recently built.
It doesn’t mean that it is not possible to build systems that are useful even though we work within these constraints. In fact Dr Eric Brewer, shed more light on the CAP theorem stating that the 2 out of 3 justification is not partitioned. Choosing between consistency and availability can happen several times within the same system at very detailed aspects of granularity. Subsystems can not only make choices differently but the changes can occur according to how data operations are being performed or even as per the user involvement in the operations that take place in the system. Also, all the three properties are uninterrupted because Availability is always up to 100 percent, several degrees of Consistency exist and Partitions too have variations, including divergence in the systems to show whether they exist or not. (Brewer, 2012)Greiner (2014) in his study states that In today’s technical background, there exists a strong growing desire to scale out when resources such as computers, storage are added in order to complete workloads successfully within the appropriate time. This is made possible by adding more hardware into the system to handle the workload that is increasing. Due to this strategy of scaling, the additional penalty comes up whereby complexity is i As a result of this scaling strategy, an additional penalty of complexity is experienced and this is where the CAP theorem is explained.
The CAP Theorem is mostly shown as an impossible outcome in distributed systems, mostly in NoSQL distributed databases. (Mehra, 2017)In his article explored more on vital thoughts in the in the Data Engineering field and where it is today. CAP is applied in systems that are distributed and are able to store state. This tool enables practitioners to have adequate knowledge of the trade-offs when they are designing shared Data systems that are networked hence influencing the design of most Distributed Data Systems. Abadi (2012) has beforehand provided an explanation of how CAP is actually not about making a choice between two of the three states by providing the answer whether the system can give up consistency or availability if a partition exists. The same way systems which give up consistency always maintain a degree of consistency as well as those which sacrifice availability do not do it in totality as well.The use of relaxed ACID properties in the CAP process will help improve optimization methods using techniques that are preffered in the optimization literature.This will help to bridge the gap between the traditional ACID theory and the CAP theorem.
Traditional ACID properties not dropped but instead weakened so as to ensure optimization of the CAP properties. All systems should work as if both CAP properties and ACID properties are implemented. This optimization process is mostly important in mobile databases where disconnections are more frequent. It is most appropriate in distributed databases such as Electronic Health Records which are based in different hospital locations because the risk of disconnection increases when the participating locations are many. (Lars, Rasmus, Christian, & N., 2014)Distributed systems enable people to achieve greater heights of computing power as well as availability that was never in the past. Current systems have achieved advanced performance, lesser latency and almost 100% up-time in all the data centres across the entire globe.
These systems are more complex as compared to the single networked ones. Being able to understand the complexity in these systems and making an appropriate trade off is very important. (Nazrul, 2018)Misconceptions about the CAP theoremWhile looking for the deliberations of the CAP theorem, there is an exceptional article by Eric Brewer, the father of the CAP theorem: CAP Twelve Years Later: How the “Rules” Have Changed. (Brewer, 2012)To begin with, misinterpretations about CAP that says that you can only have 2 out of 3 is consistent and now there is a partition of the same system that could be a genuiune network wait for that partition to come to ana end so as to ensure that the system is always in a consistent state hence sacrificing availability or you could do partial updates therefore carifing consistency. So you can only have consistency or availability in the case of partition-tolerance but not both.
On that note there is actually no way in which one could opt for “P” but it was always about how partitions should be handled and that focuses on the way of detecting partitions and how to behave while in a partition state and finally how the system should be brought back to its consistent state after an occurrence of a partition.These are not double decisions but rather an entire range of possible actions to choose from. It is about saying, in case of any failure , availability becomes more important hence choosing to accept temporary inconsistencies and putting strategies for cleaning up afterwards. Looking at it that way gives a clear picture on how databases like Cassandra fit into this and how features like read/repair work to bring back consistency. There are also ways of trying to minimize the impact of partitions on consistency and availability and how to bring back consistency after a partition.
Kleppmann ( 2015) in his paper reviewed some misunderstandings about what CAP means, including implications, irregularities and inexactness in how it is being defined, as he brings into light some challenges on how it is being formalized. CAP is frequently interpreted as a confirmation that Databases that are consistent are more available but this requires a more careful reasoning in terms of trade-offs particularly in systems that are practically being used. Kleppmann also proposed an alternative to cap by using a delay-sensitivity framework which analyses how operational latency is sensitive to network delays and hence enabling designers to have a better reasoning about trade-offs between consistency guarantees and fault tolerance in networks.
Criticism and an Alternative Model to the CAP Theorem However, the CAP theorem is often criticized for being too simple and mostly deceptive. More than a decade after its release, Eric Brewer acknowledges that the CAP theorem oversimplified the available options in the occasion of a network partition. According to Brewer, the CAP theorem prohibits only minute parts of the design space: perfect availability and also consistency in the occurrence of partitions, which are always uncommon. System designers have a large of options for dealing and improving from network partitions. The goal of every system must be to take full advantage of both consistency and availability that are sensible to specific applications.The fundamental thought is that if a client does write on to one side of the partition, any of the reads that are taken to the other side of the same partition cannot perhaps be able to identify the write that was recently done. That is how one is faced with the option of either responding to the reads which have potentially stale data or keep waiting (maybe forever) so as to get response from the other side hence causing a big compromise on availability.
While the majority of distributed systems are extensively operational, and may get millions of requests in their lifespan, CAP expresses the need for us to be careful because there is a possibility of hitting one of the three critical conditions and it is sensible to understand the way in which the system will not be able to meet either Consistency or Availability.It is possible to relax both consistency and availability from the strong requirements imposed by CAP in order to get systems that are useful. In fact, the main aim of CAP is to ensure that any systems designed relaxes on one or both of the guarantees and the responsibility is on the designer to outline when and how these guarantees should occur. Nosql databasesIn the last few years, there has been a revolution in the way of storing data because the relational databases were not the best because there was increased storage in the large volumes of unstructured data. That is how NoSQL Databases came into existence. In this world of NoSQL Databases, the system was broken down and started focusing on concepts like “Eventual Consistency”, which explains that that consistency has changed from being absolute to relative up to the extent of the application’s requirement, and the CAP theorem.Hexata-Acritecture-Team ( 2016) also explained that in the world of NoSQL Databases, the system was broken down and started focusing on concepts like “Eventual Consistency”, which explains that consistency has changed from being absolute relative up to the extent of the application’s requirement, and the CAP theorem.In this NoSQL community, the CAP theorem has been used as the explanation for giving up consistency.
Since most NoSQL systems usually don’t allow transactions that are crossing the node’s border line, then consistency is used only in replicas. For that reason, the CAP theorem provides a reason for giving up consistent replicas, replacing this objective with “eventual consistency.” With the relaxed concept, one only guarantees that all replicas will eventually come to the same state when connectivity to the network has been re-established .
At least, that’s the predictable wisdom. Many current distributed databases, including the ones that are mostly trapped under the ‘NoSQL’ net, find pleasure in offering availability and partition tolerance over strong consistency the reason behind it being that short periods of application not functioning well are not so problematic as compared to short periods of being unavailable.The NoSQL movement has used the CAP theorem as an argument in opposing traditional ACID (atomicity, consistency, isolation, and durability) databases, which always put into priority consistency and partition tolerance at the outlay of a potentially low availability. Recently, Brewer (2012) modified the CAP theorem outlining that all the CAP properties are truly more or less continuous with the possibility of being optimized, bringing them down against each other.
Practically, there is a possibility of an application area to both high availability and consistency despite being in the presence of network partitions. With the start of the NoSQL community, and growth of interest in consistent Data Stores, the CAP theorem has faced some criticism. The main issue is that CAP theorem is as a result of the errors that target network failures only.
It is mostly the premature sacrifice of consistency as a solution to network errors that has brought up questions by database community members such as Stonebraker.CAP assures that there are some situations whereby the system has to either give up consistency or availability. This situation is called a critical condition. It does not explain further how likely this condition is since both consistency and availability are very strong guarantees and they only hold if the requirements are met in all of the operations.
A single read that is inconsistent or a write that is unavailable make consistency or availability invalid until that critical condition is eventually met.Most NoSQL systems have all used the CAP theorem to give an explanation for why they make all the decisions they have to make either correctly or incorrectly.Amazon’s dynamo-eventual consistencyMost Real-time systems decide to relax availability in the case where consistency is of the highest significance like ZooKeeper. Other systems such as Amazon’s Dynamo, relax consistency so as to maintain the highest degree of availability.In order to appreciate the modern Distributed Database System design, it is vital to know the circumstance in which the system was built. Amazon initially designed the Dynamo in order to serve data to the main functions of its electronic commerce shopping cart.
The CAP theorem is not purely a case of “pick two”, since while Amazon’s Dynamo always sacrifices consistency for availability; it does it using eventual consistency and not the entire non-existence of consistency. It is achievable to have the systems which are highly available, partition tolerant and provide a degree of consistency depending on whether the degree is appropriate for that specific workload is another affair. Partition tolerance is not something that can be assumed because it is compulsory in distributed systems –it is not possible to choose it.
CAP Theorem is very significant in the field of Big Data mostly where there is need to make a trade-off based on a specific case. These concepts are different and each has a reason as to why there shall be a tradeoff. How Facebook and Google relate to CAP theorem.
The trade-off that is selected often depends on the requirements of a specific product. Google’s main focus is availability hence relaxing consistency. The output always depends on which state the server is while responding to the request since there are different inconsistent states on differentservers. Facebook normally implements eventual consistency only.
Messages take quite some time to move between servers hence these servers may have inconsistent outputs temporarily depending on the messages they see at that very moment. On the other hand, all servers will ultimately get into consistent states because the correct state is always defined by the interpretation of the messages in the order of the global timestamps instead of using the order whichtheyarrived. Facebook exampleAirline reservationBank ATMFuture evolving systemsBrewer, now being the vice president dealing with infrastructure at Google, explained why the work he is doing on the application containers is as big as cloud computing and the way the CAP theorem is still holding up ever since its inception.
Google is presently running a project called Kubernetes which is open source. Kubernetes has simplified the process used to build applications on top of clusters of containers including those using the docker format which t is very popular. (Harris, 2015)It’s about developers and datacenters.The original significance of containers is that they can be run on the laptop they deploy the same on the cloud. A fleet of containers are run where there is a controlled way of upgrading them, sending traffic to them, and scaling services depending on the number of containers that are used for running it so as to increase the capability as the load increases. The final outcome is fundamentally higher speed for the whole industry, which for users means more choices, more services, and more attractive things every day.
