Consistency models provide knowledge about assumptions that can be made over data availability post transaction. There are different variations of read-after-write consistency in addition to eventual consistency. These are considered as the most regular variations of consistency models.
Consistency models – a brief overview
Cloud storage services stick to one or combination of different consistency models while storing files in cloud. If you want the data to be available for reading instantly after the data is written, then read-after-write consistency is required while uploading a file to the storage service. The file can be also immediately downloaded or moved.
In contrast, eventual consistency does not provide any assertion about when the data would be available for reading after it is written. This can result in delayed availability or staleness of the data. Such files are not able to be moved or downloaded immediately after uploading. This can also lead to the file not being accessible even if it is updated as part of content of the folder. The system can even express inability to access the file or inability to delete the same by saying that the file does not exist.
It is relatively easy to implement read after write but can involve higher costs. It should be noted that maintenance of read-after-write consistency across multiple locations can be a daunting task because of the waiting period involved in allowing successful propagation of previous requests and confirmation by the system regarding successful implementation of previous writes. It is often observed that failure of a single data node can freeze the reads till the time the same node is available.
It is extremely difficult to deal with eventual consistency since one needs to make sure that it is programmed more defensively and requires repetitive checking whether there has been any change made on the cloud while executing a read operation. There is another option to wait till the time a change is evident. This explains the reason for use of different consistency models by various cloud storage services.
Implementation in cloud storage services
Major operators of cloud storage including Google, Amazon, and Microsoft Azure follow data replication processes for ensuring higher availability. These services also reflect specific models of data consistency.
The extremely simple and key based object storage solution is offered by Amazon S3. The buckets used by Amazon cloud storage service exhibit remarkable consistency.
AWS provides DynamoDB as a service for storage, which is much different than Amazon cloud storage service. Users are allowed to select between eventually consistent and highly consistent read, according to their requirements. In terms of resource consumption, strongly consistent read scores over eventually consistent.
In case of cloud storage offered by Google, one can expect remarkable read-after-write consistency that covers all operations associated with uploading and deleting. One should also note that Goggle’s upload operations are atomic.
In spite of the observations of CAP theorem that confirms difficulty of achieving three properties at same time, Windows Azure claims to provide three properties including high availability, partition tolerance, and strong consistency.
Ideal API provides ease of integrating various cloud storage services into your code with user friendly features and abstracted interfaces for allowing use of similar methods to target groups of those services.
If you assess different services such as Amazon S3, Google Cloud Storage Services, and Windows Azure, you will notice that these are distinctively different in terms of consistency models. Therefore you will find that all cloud storage services are not exactly identical. The difference of consistency model can significantly influence the way you write the code. This must be borne in mind by every developer.