Michael 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

Michael Soffner Motivation Variability Approach System Analysis Unified Variability Model Outline

Michael 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

Michael 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

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

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

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

Michael 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)

Michael 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

Michael 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

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

Michael 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

Michael 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

Michael Soffner Variability Model

Michael 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

Michael 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, [Jarke84] M. Jarke and J. Koch. Query optimization in database systems. ACM Computing Surveys (CSUR), 16: , June ACM ID: References

Michael Soffner Thanks for your attention!

Michael 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)