Database Technology for SaaS (Software as a Service)

Transkript

1 Database Technology for SaaS (Software as a Service) Multi-Tenant Database Enhancements Quality of Service Enabled Databases Prof. Alfons Kemper, Ph.D. Fakultät für Informatik Technische Universität München Alfons Kemper Fakultät für Informatik TUM

2 Co-Authors and Papers Stefan Aulbach, Torsten Grust, Dean Jacobs, Alfons Kemper, and Jan Rittinger Multi-Tenant Databases for Software as a Service Accepted for publication at ACM SIGMOD 2008 (SIGMOD 2008), June 9-12, 2008, Vancouver, BC, Canada Daniel Gmach, Stefan Krompass, Andreas Scholz, Martin Wimmer, and Alfons Kemper Adaptive Quality of Service Management for Enterprise Services ACM Transactions on the Web (TWEB), Vol. 2, No. 1, Article 8, February 2008 Stefan Krompass, Daniel Gmach, Andreas Scholz, Stefan Seltzsam, and Alfons Kemper Quality of Service Enabled Database Applications Service Oriented Computing - ICSOC 2006: Fourth International Conference on Service Oriented Computing December 4-7, 2006, Chicago, Illinois, USA Lecture Notes in Computer Science (LNCS), Vol. 4294, pages Alfons Kemper Fakultät für Informatik TUM 1

3 Outline Overview of SaaS Applications & Market Multi-Tenant Database Enhancements Schema Design Performance Characteristics Quality of Service Enabled Databases SLA Basics Dynamic Prioritization of Requests Alfons Kemper Fakultät für Informatik TUM 2

4 Application Complexity As application complexity increases Cost/user increases (CapEx, OpEx) Fee/user increases but flattens out (market reality) # users decreases Applies equally to the extensibility mechanisms More powerful extensibility means more complexity Profit = # users * (Fee/user Cost/user) Alfons Kemper Fakultät für Informatik TUM 3

5 Software Design Priorities On-Premises Software Software as a Service Decrease OpEx Add Features Decrease CapEx Add Features Decrease OpEx Decrease CapEx To add features, may increase CapEx/OpEx To decrease CapEx, may increase OpEx To decrease CapEx/OpEx, may sacrifice features To decrease OpEx, may increase CapEx Alfons Kemper Fakultät für Informatik TUM 4

6 Multi-Tenant Databases for Software as a Service Dealing with Highly Varied Data Alfons Kemper Fakultät für Informatik TUM

7 Multi-Tenancy in Practice Mainframe Size of Machine Blade # tenants per database Small Proj Mgmt CRM ERP Complexity of Application Banking Large Economy of scale decreases with application complexity At the sweet spot, compare TCO of 1 versus 100 databases Alfons Kemper Fakultät für Informatik TUM 6

8 Multi-Tenant Databases (MTD) Consolidating multiple businesses onto same operational system Consolidation factor dependent on size of the application and the host machine Support for schema extensibility Support atop of the database layer Non-intrusive implementation Query transformation engine maps logical tenant-specific tables to physical tables Various problems, for example: Various table utilization ( hot spots ) Metadata management when handling lots of tables Alfons Kemper Fakultät für Informatik TUM 7

9 MTD Implementation Approaches Naïve approach: Handling lots of tables Each tenant gets its own individual schema Depending on schema size, database has to handle many tables Sharing approach: Allow for Schema Extensibility Multiple tenants share tables Need for tenant-specific schema extensibility Alfons Kemper Fakultät für Informatik TUM 8

10 Schema Extensibility Essential for core enterprise applications (e.g., ERP, CRM) Benefits: Tremendously increased value of applications Anticipation of schema changes Space for future tenant data Drawbacks: Has heavy impact on table utilization Alfons Kemper Fakultät für Informatik TUM 9

11 Schema Mapping Goals: Tenant consolidation Extensibility Table sharing among tenants Need for a tenant id column Logical tenant-specific tables separated from physical layout Different physical layouts for different schema utilization Leverages table popularity Schema extensibility capabilities Alfons Kemper Fakultät für Informatik TUM 10

12 Classic Web Application Pack multiple tenants into the same tables by adding a tenant id column Great consolidation but no extensibility Account TenId AcctId Name Acme 17 2 Gump 35 1 Ball 42 1 Big Alfons Kemper Fakultät für Informatik TUM 11

13 Private Table Each tenant gets his/her own private schema No sharing SQL transformation: Renaming only High meta-data/data ratio Follows previously presented results Alfons Kemper Fakultät für Informatik TUM 12

14 Handling Lots of Tables Simplifying assumption: No extensibility Testbed setup: CRM schema with 10 tables 10,000 tenants are packed onto one (classic) DBMS Data set size remains constant Parameter: Schema Variability Number of tenants per schema instance Metrics: Baseline Compliance: 95% percentile of classic Web Application configuration (SV 0.0) Throughput [1/min] Alfons Kemper Fakultät für Informatik TUM 13

15 Schema Variability Alfons Kemper Fakultät für Informatik TUM 14

16 Handling Lots of Tables Results Alfons Kemper Fakultät für Informatik TUM 15

17 Benchmark Operations Weighted Operations SELECT Lightweight: Browser displays details page, for example Heavyweight: Reports with roll-ups, aggregation functions and sorting INSERT Lightweight: Insert single tuple Heavyweight: Batch insertion via Web Service interface UPDATE Lightweight: Update single tuple, e.g., from details page Heavyweight: Batch update with filter Alfons Kemper Fakultät für Informatik TUM 16

18 Handling Lots of Tables Conclusion Baseline Compliance gets worse with increasing number of tables DBMS must handle lots of metadata Each individual table eats up 4 KB of main memory! Indexes etc. increase that amount of memory Need for a better Data/Meta-data ratio Decrease number of tables Sharing approach Share tables among tenants Schema extensibility Alfons Kemper Fakultät für Informatik TUM 17

19 Extension Table Split off the extensions into separate tables Additional join at runtime Row column for reconstructing the row Better consolidation than Private Table layout Number of tables still grows in proportion to number of tenants Alfons Kemper Fakultät für Informatik TUM 18

20 Universal Table Generic structure with VARCHAR value columns n-th column of a logical table is mapped to ColN in an universal table Extensibility Disadvantages Very wide rows Many NULL values Not type-safe Casting necessary No index support Alfons Kemper Fakultät für Informatik TUM 19

21 Pivot Table Row: 0 Generic type-safe structure Each field of a row in logical table is given its own row. Multiple pivot tables for each type (int, string, e.g.) Eliminates handling many NULL values Performance Depends on the column selectivity of the query (number of reconstructing joins) Alfons Kemper Fakultät für Informatik TUM 20

22 Row Fragmentation Possible solution for addressing table utilization issues Various storage techniques for individual fragments Hunt for densely populated tables Idea: Split rows according to their popularity Alfons Kemper Fakultät für Informatik TUM 21

23 Chunk Table Row: 0 Generic structure Suitable if dataset can be partitioned into dense subsets Derived from Pivot table Performance Fewer joins for reconstruction if densely populated subsets can be extracted Indexable Reduced meta-data/data ratio dependant on chunk size Chunk 0 Chunk 1 Alfons Kemper Fakultät für Informatik TUM 22

24 Row Fragmentation Combine different schema mappings for getting a best fit Mixes Extension and Chunk Tables Each fragment can be stored in an optimal schema layout Optimal row fragmentation depends on, e.g. Workload Data distribution Data popularity Alfons Kemper Fakultät für Informatik TUM 23

25 Querying Chunk Tables Query Transformation Row reconstruction needs many self- and equi-joins Can be automatically translated Compilation Scheme: 1. Collect all table names and their corresponding columns from the logical source query 2. For each table, obtain the Chunk Tables and the meta-data identifiers representing the used columns 3. For each table, generate a query that filters the correct columns (based on the meta-data identifiers) and aligns the different chunk relations on their ROW column. 4. Each table reference in the logical source query is extended by its generated table definition query Alfons Kemper Fakultät für Informatik TUM 24

26 Query Transformation Example Source query: SELECT Beds FROM Account 17 WHERE Hospital = State 1. Collect table and column names Account 17 : Beds, Hospital 2. Obtain chunk tables and meta-data Chunk int str Account 17 : Table = 0, Tenant = 17 Beds, Hospital: Chunk = 1 Alfons Kemper Fakultät für Informatik TUM 25

27 Query Transformation Example 2. Obtain chunk tables and meta-data Chunk int str Account 17 : Table = 0 Beds, Hospital: Chunk = 1 3. Generate filter query SELECT Str1 as Hospital, Int1 as Beds FROM Chunk int str WHERE Tenant = 17 AND Table = 0 AND Chunk = 1 Alfons Kemper Fakultät für Informatik TUM 26

28 Query Transformation Example 3. Generate filter query SELECT FROM Str1 as Hospital, Int1 as Beds Chunk int str WHERE Tenant = 17 AND Table = 0 AND Chunk = 1 4. Replace reference in source query SELECT Beds FROM ( SELECT Str1 as Hospital, Int1 as Beds FROM Chunk int str WHERE Tenant = 17 AND Table = 0 AND Chunk = 1) AS Account 17 WHERE Hospital = State Alfons Kemper Fakultät für Informatik TUM 27

29 Query Transformation Structural changes Additional nesting due to the expansion of the table definitions All table references are expanded into join chains on the base tables All base table accesses refer to the meta-data colums Impact on Performance Introduced additional nesting can always be flattened. (Fegaras and Maier) Join Chains might be much cheaper, as long as the costs for loading the chunks and applying the index-supported join are cheaper than reading the wider conventional relations Meta-data columns on base tables have sophisticated indexes to support fast querying (Partitioned B-tree index) Alfons Kemper Fakultät für Informatik TUM 28

30 Query Evaluation Experiments Show good nature of this transformation Scalability issues Evaluate impact of Nesting Join Overhead Meta-data Overhead Test Query SELECT p.id,... FROM parent p, child c WHERE p.id = c.parent AND p.id =? Alfons Kemper Fakultät für Informatik TUM 29

31 Query Evaluation Experiments Conventional Schema Chunk Schema Alfons Kemper Fakultät für Informatik TUM 30

32 Query Un-nesting Optimizer Test Can the database optimizer flatten the query? MySQL Unable to un-nest query Factor 5 performance increase when manually unnesting the queries DB2 Generated fully un-nested query evaluation plan Pushed predicates to base table access Alfons Kemper Fakultät für Informatik TUM 31

33 Query Un-nesting Regions: 1. Lookup foreign key for child relation, selection based on? parameter. 2. ID column of parent relation with same selection as for the foreign key. 3. Hash-Join implements foreign key join 4. Lookup for all data columns from parent table, chain of aligning joins 5. Lookup for all data columns from child table, chain of aligning joins Alfons Kemper Fakultät für Informatik TUM 32

34 Join Overhead Costs Join Overhead No aligning joins Alfons Kemper Fakultät für Informatik TUM 33

35 Meta-Data Costs Number of logical data and index reads Run-time Meta-Data Interpretation Compile-time Meta-Data interpretation Alfons Kemper Fakultät für Informatik TUM 34

36 Quality of Service Enabled Database Applications Stefan Krompass, Daniel Gmach, Andreas Scholz, Stefan Seltzsam, Alfons Kemper Alfons Kemper Fakultät für Informatik TUM

37 Outline Introduction Quality of Service Model System Architecture and Implementation Request Scheduling Performance Evaluation Conclusion and Ongoing Work Alfons Kemper Fakultät für Informatik TUM 36

38 Outline Introduction Quality of Service Model System Architecture and Implementation Request Scheduling Performance Evaluation Conclusion and Ongoing Work Alfons Kemper Fakultät für Informatik TUM 37

39 Introduction Web Service Web Service Web Service Web Service Web Service Database Alfons Kemper Fakultät für Informatik TUM 38

40 Service Level Agreements (SLAs) SLA SLA SLA Web Contracts Servicebetween service Web provider Service and client for the service directly invoked by the client Challenge: provide end-to-end quality of service control Web Service Web Service Web Service Database Alfons Kemper Fakultät für Informatik TUM 39

41 Static Prioritization Priority Customer A high Customer B medium Web Service Scheduling Database SLA Conformance Customer A Customer B Alfons Kemper Fakultät für Informatik TUM 40

42 Limitations of the Static Prioritization SLA (taken from TPC-C) 90% of all transactions have to be processed in less than 5 seconds Static prioritization no longer sufficient High priority customers overachieve their SLAs Alfons Kemper Fakultät für Informatik TUM 41

43 Adaptive Penalties Priority Customer A medium high Customer B medium high Web Service Scheduling Database Customer B with higher priority than A SLA Conformance Customer A Customer B Alfons Kemper Fakultät für Informatik TUM 42

44 Outline Introduction Quality of Service Model System Architecture and Implementation Request Scheduling Performance Evaluation Conclusion and Ongoing Work Alfons Kemper Fakultät für Informatik TUM 43

45 Terminology Service Level Agreements (SLA) Percentile constraints SLA penalty Deadline constraints Metric: SLA conformance Ratio between number of timely transaction invocations and number of total transaction invocations Alfons Kemper Fakultät für Informatik TUM 44

46 SLA Penalty Process 90% of all requests in less than 5 seconds Penalty $900 for each 10% of underfulfillment Maximum penalty: $1800 Evaluation period: one month Alfons Kemper Fakultät für Informatik TUM 45

47 Quality of Service Model SLA Two-steps Compute penalty for an individual request Opportunity costs Marginal gain Compute deadline constraints for individual request Alfons Kemper Fakultät für Informatik TUM 46

48 Opportunity Costs Model the danger of falling to a lower service level Alfons Kemper Fakultät für Informatik TUM 47

49 Marginal Gain Models the chance of re-achieving a higher service level Alfons Kemper Fakultät für Informatik TUM 48

50 Adaptive Penalty Maximum of opportunity costs and marginal gain Alfons Kemper Fakultät für Informatik TUM 49

51 Penalty for Individual Requests Penalty for request Current SLA conformance Alfons Kemper Fakultät für Informatik TUM 50

52 Time Constraints for Individual Requests Deadline constraint for query q Deadline constraint for query q 2 1 Deadline constraint for the transaction q 11 q 2 q 2 q 3 q 4 Average Monitored running timedeadline for q 2 monitored processing from previous transaction time invocations Deadline for q 1 Alfons Kemper Fakultät für Informatik TUM 51

53 Outline Introduction Quality of Service Model System Architecture and Implementation Request Scheduling Performance Evaluation Conclusion and Ongoing Work Alfons Kemper Fakultät für Informatik TUM 52

54 Architecture Alfons Kemper Fakultät für Informatik TUM 53

55 Outline Introduction Quality of Service Model System Architecture and Implementation Request Scheduling Performance Evaluation Conclusion and Ongoing Work Alfons Kemper Fakultät für Informatik TUM 54

56 Admission Control and Scheduling Admission control limits the multi programming level (MPL) Queuing of requests (dual queue scheduling) Scheduler reorders the requests by their priority prior to de-queuing a request Objective function: Minimization of incurred penalties Alfons Kemper Fakultät für Informatik TUM 55

57 Dual Queue Scheduling Alfons Kemper Fakultät für Informatik TUM 56

58 Outline Introduction Quality of Service Model System Architecture and Implementation Request Scheduling Performance Evaluation Conclusion and Ongoing Work Alfons Kemper Fakultät für Informatik TUM 57

59 SLA Conformance Static Prioritization Alfons Kemper Fakultät für Informatik TUM 58

60 SLA Conformance Dynamic Penalization Alfons Kemper Fakultät für Informatik TUM 59

61 Outline Introduction Quality of Service Model System Architecture and Implementation Request Scheduling Performance Evaluation Conclusion and Ongoing Work Alfons Kemper Fakultät für Informatik TUM 60

62 Conclusion We presented an economic model for adaptively penalizing individual database requests the architecture and implementation for the QoS management our admission control and scheduling approach the effectiveness of our approach using the TPC-C benchmark Alfons Kemper Fakultät für Informatik TUM 61

63 Ongoing Work Exploit time constraints for penalties more sophisticated algorithms Extend the scheduling for multi-level service infrastructures Alfons Kemper Fakultät für Informatik TUM 62