Database Reference
In-Depth Information
Additionally, there are other particular issues when measuring cloud computing
platforms. The cloud service provider moves on quickly and might change any
aspect of hardware or software without providing sufficient advance notice to
the customers. For example, even if the algorithm used by a platform currently
provides read-your-writes, the cloud service provider could shift to a different
implementation that does not provide the current guarantee. As another example,
a cloud service provider that currently places all replicas within a single data
center might implement geographical distribution, with replicas stored across data
centers for better reliability. Such a change could happen without awareness of the
customers, but it might lead to a situation where eventual consistent reads have
observably better performance than consistent reads. Similarly, the background
load on the cloud computing platforms might have a large impact, on latency or
availability or consistency, but the customer cannot control or even measure what
that load is at any time [
208
]. For all these reasons, our current observations that
eventual consistent reads are no better for the customer, might not hold true in the
future.
Also taking the observations reported in this chapter as an example, The reported
results are mainly obtained during October and November in 2011. Before that a
similar experiments were conducted in May 2011 as well. By doing the comparison,
most aspects were similar between the two sets of experiments, in particular the
500 ms latency till Amazon SimpleDB reached 99% chance for a fresh response
to a read, the high chance of fresh data in eventual consistent reads in Amazon
S3, Microsoft Windows Azure Blob Storage, and Google App Engine Datastore,
and the lack of performance difference between SimpleDB for reads with different
consistency. Other aspects had changed, for example in the earlier measurements
there was less variation in the response time seen by reads on SimpleDB.
In order to achieve high availability and low latency, many NoSQL storage
platforms drop the guarantee of strong consistency, by avoiding two-phase commit
or synchronous access to a quorum of sites. Therefore, it is commonly said that
developers should work around this by designing applications that can work with
eventual consistency or similar weaker models. This chapter also examined the
experience of the customer of NoSQL storage, in regard to weak consistency
and possible performance trade-offs to justify its use, specifically by focusing on
Amazon SimpleDB. This information should help a developer who is seeking to
understand the new NoSQL storage platforms, and who needs to make sensible
choices about choosing the right storage platform.
This chapter found that platforms differed widely in how much weak consistency
is seen by customers. On some platforms, the customer is not able to observe any
inconsistency or staleness in the data, over several million reads through a week.
It seems that inconsistency is presumably possible, but are very rare. It might only
happen if there is a failure of the NoSQL storage platforms. Therefore, the risk
of inconsistency seems less important when compared to other sources of data
corruption, such as bad data entry, operator error, customers repeating input, fraud
by insiders, and etc. Any system design needs to have recourse to manual processes
to fix the mistakes and errors from these other sources, and the same processes
