Database Reference
In-Depth Information
delay is represented as the difference between two average replication delays on the
same slave. One average replication delay represents the average of delays without
running workloads while another represents the average of delays under a number
of concurrent users. Both average is sampled with the top 5% and the bottom 5%
data removed as outliers, because of network fluctuation. As both average delays
come with stable time differences with NTP protocol enabled every second, the
time difference can then be eliminated subtracting the difference. In experiments,
the NTP is set to synchronize with multiple time servers every second for a more
stable time difference.
6.2
Implementation of Benchmark Application
As the Fig.
6.1
illustrated, the replication experiments are conducted in
Amazon EC2. The experiment setup is a three-layer implementation. The
Cloudstone benchmark in the first layer controls the read/write ratio and
the workload by separately adjusting the number of read and write operations and
the number of concurrent users. As a large number of concurrent users emulated by
the benchmark could be very resource-consuming, the benchmark is deployed in a
large instance to avoid any overload on the application tier. The master database in
the second layer receives the write operations from the benchmark and is responsible
for propagating the writesets to the slaves. The master database runs in a small
instance so that saturation is expected to be observed early. Both the master database
server and the application benchmark are deployed in location of
us-east-1a
.The
slaves in the third layer are responsible for processing read operations and updating
writesets. The number of slaves in a group varies from one to the number where
throughput limitation is hit. Several options for the deployment locations of the
slaves have been used, namely, the same zone as the master in
us-east-1a
, different
zones in
us-east-1b
and four possible different regions, ranging among
us-west
,
eu-west
,
ap-southeast
and
ap-northeast
. All slaves run in small instances for the
same reason of provisioning the master instance.
Several sets of experiments have been implemented in order to investigate the
end-to-end throughput and the replication delay. Each of these sets is designed
to target a specific configuration regarding the geographical locations of the
slave databases and the read/write ratio. Multiple runs are conducted by compound-
ing different workloads and numbers of slaves. The benchmark is able to push the
database system to a limit where no more throughput can be obtained by increasing
the workload and the number of virtualized database replica servers. Every run lasts
35 m, including 10 m for ramp-up, 20 m for steady stage and 5 m for ramp-down.
Moreover, for each run, both the master and slaves should start with a preloaded,
fully-synchronized database.
