Database Reference
In-Depth Information
Fig. 5.1
The architecture of NoSQL database as a service benchmark applications
is observed in a read. In most of the experiments that are reported, writing happens
once every 3 s. A reader role repeatedly reads the contents from the data element and
also notes the time at which the read occurs; in most experiments reading happens
50 times every second. Comparing read values reveals the probability of reading
stale values over time. Assume a writer invokes a write operation at time t and a
reader invokes a read operation at time t
C
x. “A period of time” to make replicas
consistent is obtained by finding x when no stale value is observed.
In some experiments, the writer and reader roles are deployed as a single thread
for the writer role, and single or multiple threads for the reader role, while in other
experiments, a single thread takes both roles. For one experiment measurement,
the writing and reading operations are run for 5 min, doing 100 writes and 15:000
reads. The measurement is repeated once every hour, for at least 1 week, in October
and November 2010. It must be noted that each measurement includes not only
the processing time on NoSQL databases but also that of applications and network
latency. In all measurement studies, it is confirmed that benchmark applications and
networks are not performance bottlenecks.
In a post-processing data analysis phase, each read is determined to be either
fresh or stale, depending on whether the value observed has a timestamp from
the closest preceding write operation, based on the times of occurrence; also each
read is placed in a bucket based on how much clock-time has elapsed since the
most recent write operation. By examining all the reads within a bucket, from a
single measurement run, or indeed aggregating over many runs, the probability
of observing the freshest value by a read is calculated. Repeating the experiment
through a week ensures that we will notice any daily or weekly variation in behavior.
