By Zak Croft

This week we continue with a look at data centric models.

Data centric models

Strong or strict consistency

The strong or sometimes called strict consistency model specifies that any write operation on a data item would need to be finalised on that replica and then propagated throughout all the other replicas before any further read could take place on that data item. This guarantees that any read on the data item will return the most recent write and that the these reads will be seen in the order in which the operations were carried out. This second clause is in fact impossible as temporal synchronisation on a global scale is not possible as latency issues due to distance of each replica from each other do not allow for absolute synchronisation. Therefore the ordering of the operations may be different than how they are executed in absolute time, but still the reads will be seen in this strict order of execution that they are applied to the data. Applicability of this model could be a banking system. If money is withdrawn from the bank and a replica updated with the new balance then other globally placed replicas would need to be updated before transactions could take place. This ensures that the unavailable money could not be withdrawn around the globe all at once. The disadvantages of this model are that the system suffers from performance issues as some data is not available during some update. In order to combat this weaker consistency models are needed.

Sequential consistency

The sequential consistency model can be defined as the result of any execution is the same as if the operations of all the processors were executed in some sequential order, and the operations of each individual processor appear in this sequence in the order specified by its program. What this means is that that instead of the reads having to be read in the strict ordering of the way the writes were executed, the reads can be read in a uniform sequential manner by all processes that is not necessarily the way in which the writes were carried out. This allows for inconsistencies in the actual absolute ordering of the data returned so reduces the reliability of the data, in this way. Saying this there is an increase in performance in the system as this less strict model does not need as long and as much process power to obtain a state ready for further reads after a write. An example of a type of system that could use sequential consistency would be any system that did not require a critical and definitive data set to be viewed. This could be for example a reservation system where the criticality of a double booking, not being performed, could be relaxed in order to boost overall system performance. Sequential consistency brings greater performance but still has performance issues. A weaker model that boast a greater amount of performance, but again the trade off with reliability is present, is the causally consistency model.

Causal consistency

The causal consistency model can be defined as the sequential model with the difference being that instead of all reads by all processors seeing the same ordering of all operations, only operation that are causally related are seen by all processes in a consistent order.  This then says that if a data item is read by a process A and then is written to by process B. Then subsequent reads by A will return the write performed by B. If a process C reads the data item then it can read either the data item prior to or after process B's write. The reason it can be either is that firstly it is not causally related so does not have to read the post operated data and secondly it would choose the replica to read based on a different algorithm .i.e. which is the closest to the process reading the data.  Casual consistency, as mentioned, brings even greater performance but again the trade off is with a further reduction in the reliability of the data. The degree that this trade-off affects the system again depends on the type of system in question. An example could be a bidding system. In bidding systems users must see bids in the order they are bid and the last write is the present bidding amount. Other unrelated data, not associated with the bid, does not need to be seen in any order with regards to these bids, they will be separately ordered together if they are casually related. This then shows a weaker form of consistency, but there is one more that needs to be discussed as it is possibly the weakest model and thus boast the highest performance available for a system. This is eventual consistency.

Eventual consistency

The eventual consistency model can be defined as when no updates occur for a long period of time, eventually all updates will propagate through the system and all the replicas will be consistent.  This basically allows for the updates in the system that pertains to a data item to eventually propagate through the system and thus eventually all the replicas will become up to date, when and only when no other update occurs on that data item. Another definition uses a concept called the consistency window in the definition, where the consistency window is open between the time the update is initiated and when all replicas are up to date. It states that the storage system guarantees that if no new updates are made to the object eventually (after the consistency window closes) all access will return the last updated value. This kind of weak consistency can be popular with systems that do not need to enforce any kind of stricter views of the data. The popular example is the Domain Name System (DNS) as when a domain name is changed the central body propagates this new update to the replicas. Eventually all the replicas reflect this new update. Here a strict view of the data is not necessary as updates are rare and only a centralised body can make update to the system.  Eventual consistency is a weaker form and a cheaper model to implement.

Next week week we look at client centric models.