1. 109.07.2012Michael Soffner A Variability Model for Query Optimizers Michael Soffner 1, Norbert Siegmund 1, Marko Rosenmüller 1, Janet Siegmund 1, Thomas Leich 2, Gunter Saake 1 1 University of Magdeburg, Germany 2 METOP GmbH, Germany

2. 209.07.2012Michael Soffner Motivation Variability Approach System Analysis Unified Variability Model Outline

3. 309.07.2012Michael Soffner Database vendors continuously extend functionality to fit to new application domains Leads to over bloated systems that have decreased performance and manageability Specialized systems outperform RDBMS, e.g., Sensor Networks and Data Warehouses (Stonebraker2005) Driving factors for Query Optimizer extensions SQL  conformity to standard New indexes, operations, statistics Result: Increased search space and reduced performance Motivation

4. 409.07.2012Michael Soffner Goal: Specialized query processors by introducing variability Selection of only needed functionality and omitting the rest Variability through Software Product Lines (SPLs) Our Approach Fig.1 Benefits of tailored Query Optimizers

5. 509.07.2012Michael Soffner Software Product Lines (SPLs) Use Features to describe a concept in a domain model

6. 609.07.2012Michael Soffner Product Derivation Configuration Feature Model Reusable Implementation Artifacts Program GeneratorFinal Product Domain Engineering Application Engineering

7. 709.07.2012Michael Soffner 3 Steps to a unified model Overall Process Course Model System Analysis Unification Classification by Jarke (1984) Oracle, PostgreSQL, SQLite Unified Model

8. 809.07.2012Michael Soffner Generally distinguishes logical and physical optimization Optimizer Functionality Classification (Jarke) LogicalPhysical Standardization Transformation into a standardized representation (e.g. predicate normalization) Evaluation Algorithm General algorithm that generates the program to a given query (e.g. recursive search) Simplification Elimination of redundancies, (e.g. idempotency rules) Operations Physical implementations of logical operations (e.g. nested loop join) Amelioration Generating semantically equal queries with better performance (e.g. heuristics) Strategy Concepts to find best query plan (e.g. cost-based approach)

9. 909.07.2012Michael Soffner Customizable through #ifdef compiler flags  static configuration All logical optimization features are optional Only B-Tree indexes Allows statistics to be omitted statically SQLite

10. 1009.07.2012Michael Soffner Most logical optimization feature aim to standardize the input query No features for special heuristics Includes inline set returning functions Two evaluation algorithms: exhaustive search, genetic algorithm Four index types: b-tree, hash-based and multi-dimension-based indexes (GIS support) PostgreSQL

11. 1109.07.2012Michael Soffner Special feature: predicates pushing, rewrite materialized views Most Access Paths Configuration through Hints Oracle

12. 1209.07.2012Michael Soffner Goal: System-independent Variability Model Identification of feature that implement same functionality 1. Integration A1: Same functionality but different names A2: Same names but different functionality Only semantic descriptions allow a decision Basis: Documentation and Source Code Example: Nested Loop Variability Model: Unification Process SQLitePostgreSQL NameNested LoopNestpath SourceSource-code Comment typedef definition and cost calculation algorithm

13. 1309.07.2012Michael Soffner 2. Unification 1:1 Mapping (Mapping of one Features into one unified Feature) 1:n Mapping (Compose multiple system-dependent Features into one unified Feature) Variability Model: Unification Process 2 FeatureSQLitePostgreSQLOracle No. of Table Entries N/ANo. of Table EntriesNo. of Rows Pull Up Subqueries Subquery Flattening Pull Up SubqueriesSubquery Unnesting From ClauseN/AFrom Clause N/A Where Clause N/APull Up SublinksN/A

14. 1409.07.2012Michael Soffner Variability Model

15. 1509.07.2012Michael Soffner Provide a basis for implementing configurable query optimizer Unified semantic description of query optimizer functionality (Taxonomy/Ontology) Provides a foundation for a (semi-)automatic configuration of query optimizers based on application requirements Provide a basis for modeling dependencies between query optimizers and deeper layers of DBMSs, e.g., Storage Engine Conclusion

16. 1609.07.2012Michael Soffner [Stonebraker2005] M. Stonebraker and U. Cetintemel. One Size Fits All: An Idea Whose Time Has Come and Gone. In Proceedings of the International Conference on Data Engineering (ICDE),pages 2-11, 2005. [Jarke84] M. Jarke and J. Koch. Query optimization in database systems. ACM Computing Surveys (CSUR), 16:111-152, June 1984. ACM ID: 356928. References

17. 1709.07.2012Michael Soffner Thanks for your attention!

18. 1809.07.2012Michael Soffner Specialized Systems outperform RDBMS DBMS originally designed to support Business Data Other Application Domains need different paradigms Argued that the One Size Fits all is not applicable in future DBMS Mentioned Domains: Sensor Networks (Streaming Applications) Textdatabase (Google  BigData) Data Warehouses ? One Size Fits All? (Stonebreaker)