Database Reference
In-Depth Information
It is known that the eventual consistent read of Datastore reads from a secondary
replica only when a primary replica is unavailable. Therefore, it is expected that
customers see consistent data in most reads, regardless of the consistency option
they choose.
The benchmark application for Google App Engine Datastore is coded in Java
and deployed in Google App Engine. Applications deployed in App Engine are not
allowed to create threads; a thread automatically starts upon an HTTP request and
it can run for no more than 30 s. Therefore, each measurement on App Engine runs
for 27 s and measurements are executed every 10 min for 12 days. The same set of
measurements was performed with strong consistent read and eventual consistent
read. App Engine also offers no option to control the geographical location of
applications. Therefore, only two configurations are examined: a writer and a reader
are run in the same application, and a writer and a reader are run in different
applications. Each measurement consists of 9:4 writes and 2787:9 reads on average,
and in total 3;727;798 reads and 12;791 writes are recorded on average for each
configuration.
With strong consistent read no stale value was observed. With eventual consistent
read and both roles in the same application, no stale value was observed. However
11 out of 3;311;081 readings, approximately 3:3
10
4
%, observed stale values
when a writer and an eventual consistent reader are run in different applications.
It is hard to conclude for certain whether stale values might sometimes be observed
when a writer and a reader are run in the same application. However, it suggests
the possibility that Google App Engine offers read-your-writes level of eventual
consistency. In any case, it is also clear that consistency errors are very rare.
5.3
Trade-Off Analysis of Amazon SimpleDB
In the hope of assisting the customer to make a well-informed decision about
consistency options for reading data, the trade-off analysis could be made by
considering consistency levels against response time and throughput, monetary cost,
and implementation ideas, respectively. The benchmark architecture described in
Sect.
5.1
is reused for the analysis. The measurement ran between 1 and 25 instances
in
us-west
region to read and write one attribute, which is a 14 bytes string data,
from an item in Amazon SimpleDB. Each instance runs 100 threads, acting as
emulated end-users, each of which executes one read or write request every second
in a synchronous manner. Thus, if all requests' response time is below 1:000 ms,
the throughput of SimpleDB can be reported as 100% of the potential load. Three
different read/write ratios were studied, including 99/1, 75/25, and 50/50 cases. Each
measurement runs for 5 min with a set number of virtual machines, once every hour
for 1 day.
