1 / 25

ActiveSLA : A Profit-Oriented Admission Control Framework for Database-as-a-Service Providers

ActiveSLA : A Profit-Oriented Admission Control Framework for Database-as-a-Service Providers. Pengcheng Xiong (Georgia Tech); Yun Chi; Shenghuo Zhu; Junichi Tatemura ; Calton Pu ; Hakan Hacigumus Presented by Yu Li. Outline. Introduction Related work Prediction module design

Download Presentation

ActiveSLA : A Profit-Oriented Admission Control Framework for Database-as-a-Service Providers

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. ActiveSLA: A Profit-Oriented Admission Control Framework for Database-as-a-Service Providers PengchengXiong (Georgia Tech); Yun Chi; ShenghuoZhu; Junichi Tatemura; CaltonPu; HakanHacigumus Presented by Yu Li

  2. Outline • Introduction • Related work • Prediction module design • Prediction module evaluation • Decision module design • Decision module evaluation • Conclusions

  3. Introduction • DaaS provider consolidates multiple clients in shared infrastructures (multi-tenancy) • greater economies of scale • fixed cost distribution • Problem: system overload due to unpredictable and more bursty workloads • dynamic provisioning, • queuing and scheduling, and • admission control

  4. Introduction • Macro level (feedback based): keep the mean query execution time at a specific level by tuning the best multiple programming level (MPL) for a given workload, e.g., ICDE2006 • Micro level (query-by-query based): estimate every single query’s execution time by query type and query mix, e.g., WWW2004, ICDE2010 • None of them has well addressed the problem to directly maximize DaaS provider’s profits by satisfying different SLAs for their clients!

  5. Introduction • Merely estimating the query execution time is not enough to make profit-oriented decisions. We need to know the probabilities of a query meeting and missing its deadline.

  6. Introduction • We may have to make different admission control decisions even when the queries have the same deadline and the same probability of meeting the deadline due to different SLAs.

  7. System architecture of ActiveSLA

  8. Prediction module design • What kind of models to use? • The model selection between linear and nonlinear models, between regression and classification models • What features to use? • The rich set of features for DaaS providers

  9. Model selection • Linear vs. Nonlinear • The execution time of a query depends on many factors in a non-linear fashion, i.e., isolation levels and available buffer size • Regression vs. Classification • From the machine learning point of view, a direct model of classification usually outperforms a two-step regression based approach.

  10. Feature collection • Query Type and Mix (TYPE, Q-Cop, ActiveSLA) • Query Features (ActiveSLA) • E.g., the estimated number of sequential I/O • Database and System Conditions (ActiveSLA) • Buffer cache: the fraction of pages of each table that are currently in the database buffer pool. • System cache: the fraction of pages of each table that are currently in the operating system cache. • Transaction isolation level: Read Committed(FALSE) or Serializable(TRUE). • CPU, memory, and disk status: the current status of CPU, memory, and disk in the operating system.

  11. Description of the data and Environment

  12. Prediction module evaluation • Query Sets with PostgreSQL server • TPC-W1 (browsing queries) • TPC-W2 (mixture of browsing and administrative queries) • TPC-W3 (mixture of browsing, administrative, and updating queries) • Prediction error False positive False negative Total number

  13. Prediction module evaluation

  14. Details on the Machine Learning Model • Positive value->more likely to miss deadline • Negative value->unlikely to miss deadline

  15. Details on the Machine Learning Model

  16. Overhead and feature sensitivity • Overhead • Training overhead. 72ms to build an initial model by using 12,000 samples. • Evaluation overhead. 8ms • Feature sensitivity • The more features, the better • The gain by using more features is less than the gain by using a better model.

  17. Decision module design

  18. Multiple Query Decision • Admitting q into the database server may slow down the execution of other queries that are currently running in the server and make them miss deadline. • Admitting q will consume system resources and change the system status. This may result in the rejection of the next query, which may otherwise be admitted and bring in a higher profit. • Model this as opportunity cost o.

  19. Decision module design • Result with stationary workload (static Poisson arrival rate) • Result with non-stationary workload (dynamic Poisson arrival rate according to 1998 World Cup Trace) • Single SLA • Multiple SLAs(service differentiation)

  20. Decision module design • Result with stationary workload (static Poisson arrival rate) • Result with non-stationary workload (dynamic Poisson arrival rate according to 1998 World Cup Trace) • Single SLA • Multiple SLAs(service differentiation)

  21. Result with stationary workload

  22. Result with non-stationary workload

  23. Profit-oriented service differentiation

  24. Conclusion • We proposed a framework, ActiveSLA, for admission control in cloud database systems. • Prediction module to predict the possibility that a query can meet/miss deadline. • Decision module to make the profit-oriented decision. • Future work • Improve the inaccuracy for the query features such as the number of sequential I/O due to the incorrect statistics and cardinality estimates of a query execution plan. • Extend our prediction module by including the level of replication as one of the system variables. • Extend our ActiveSLA to deal with different types of database systems to manage data and serve queries, e.g., NoSQL databases.

  25. Thank you!

More Related