SLA Definition for Multi-tenant DBMS and its Impact on Query Optimization

Abstract

In the cloud context, users are often called tenants. A cloud DBMS shared by many tenants is called a multi-tenant DBMS. The resource consolidation in such a DBMS allows the tenants to only pay for the resources that they consume, while providing the opportunity for the provider to increase its economic gain. For this, a Service Level Agreement (SLA) is usually established between the provider and a tenant. However, in the current systems, the SLA is often defined by the provider, while the tenant should agree with it before using the service. In addition, only the availability objective is described in the SLA, but not the performance objective. In this paper, an SLA negotiation framework is proposed, in which the provider and the tenant define the performance objective together in a fair way. To demonstrate the feasibility and the advantage of this framework, we evaluate its impact on query optimization. We formally define the problem by including the cost-efficiency aspect, we design a cost model and study the plan search space for this problem, we revise two search methods to adapt to the new context, and we propose a heuristic to solve the resource contention problem caused by concurrent queries of multiple tenants. We also conduct a performance evaluation to show that, our optimization approach (i.e., driven by the SLA) can be much more cost-effective than the traditional approach which always minimizes the query completion time.

Cost-Effective Dynamic Optimisation for Multi-Cloud Queries

“…The second method [17] generates SLA using query templates according to a user-defined expected query completion time and a tolerance threshold. The idea is that users are fine with waiting a bit more for the query to be executed, granted that they will pay less, hence a price function is defined according to the users expectations.…”

“…Quotations are a necessity given the monetary implications of cloud computing and the variety of billing models. Indeed, while some providers, such as Google 4 , charge per query input relations size, more complex policies defined into Service-Level Agreements (SLA) may exist [17] (e.g. based on the complexity of the query or the computational resources used during its processing).…”

Resource auto-scaling for SQL-like queries in the cloud based on parallel reinforcement learning

“…For example, let's consider a stage Si that performs a selection on a relation 1 R then a Map Join between the result of the selection and a relation 2 R . The duration ( ET ) of an elementary task of the stage Si is estimated as follows (Yin et al, 2018): 3 Auto-scaling method…”