CloudDB AutoAdmin - Large Scale and Big Data: Processing and Management - page 383

In general, the results of our experiments show that the adaptive replication con-
troller can play an effective role on reducing the replication delay of the underly-
ing replicas by adding new replicas when necessary. It is also observed that with
more replicas added, the replication delay for the overloaded replicas can dramati-
cally drop. Moreover, it is more cost-effective in comparison to the overprovisioning
approach for the number of database replicas that can ensure low replication delay
because it adds new replicas only when necessary based on the application-defined
SLA of data freshness for the different underlying database replicas.
11.7 PROVISIONING THE DATABASE TIER BASED ON
SLA OF TRANSACTION RESPONSE TIMES
Another consumer-centric SLA metric that we consider in our framework is the total
execution times of database transactions (response time). In practice, this metric
has a great impact on the user experience and thus satisfaction of the underlying
services. In other words, individual users are generally more concerned about when
their transaction will complete rather than how many transactions the system will
be able to execute in a second (system throughput) [11]. To illustrate, assuming a
transaction ( T ) with an associated SLA for its execution time ( S ) is presented to the
system at time 0, if the system is able to finish the execution of the transaction at
time ( t ≤ S ) then the service provider has achieved his target otherwise if ( t > S ), then
the transaction response cannot be delivered within the defined SLA, and hence,
a penalty p is incurred. In practice, the SLA requirements can vary between the
different types of application transactions (for example, a login application request
may have an SLA of 100 ms execution time, a search request may have an SLA of
600 ms while a request of submitting an order information would have 1500 ms).
Obviously, the variations in the SLA of different applications transactions is due to
their different natures and their differences in the consumption behavior of system
resources (e.g., disk I/O, CPU time). In practice, each application transaction can
send one or more operations to the underlying database system. Therefore, in our
framework, consumer applications can define each transaction as pattern(s) of SQL
commands where the transaction execution time is computed as the total execution
time of these individual operations in the described pattern. Thus, the monitoring
module is responsible for correlating the received database operations based on their
sender to detect the transaction patterns [16]. Our framework also enables the con-
sumer application to declaratively define application-specific action rules to adap-
tively scale out or scale in according to the monitored status of the response times
of application transactions. For example, an application can define to scale out the
underlying database tier if the average percentage of SLA violation for transactions
T 1 and T 2 exceeds 10% (of the total number of T 1 and T 2 transactions) for a continuous
period of more than 8 minutes. Similarly, the application can define to scale in the
database tier if the average percentage of SLA violation for transactions T 1 and T 2
is less than 2% for a continuous period that is more than 8 minutes and the average
number of concurrent users per database replica is less than 25.
We conducted our experiments with 4 different rules for achieving elasticity and
dynamic provisioning for the database tier in the cloud. Two rules are defined based