Cache-Aware Query Optimization, Scheduling, and Partitioning for Multicore (A Research Proposal for Optimizing DBMS on CMP) (Focusing on Decision Support Queries) Rubao Lee

Moore’s Law in 37 Years (IEEE Spectrum, May 2008) However, all proposed schemes were evaluated by simulation, there are several limitations in simulation-based study: First, the simulation time is extremely long, for example, it would take several weeks or months to complete a single SPEC CPU2006 application. As the number of cores continues to increase, simulation ability becomes more limited. Second, by simulation, it is hard to observe long-term OS activities The interactions between process/OS may affect performance significantly. Without whole program execution and without OS iterations, how much do we trust the accuracy? Last, Simulation is prone to simulation bugs and it is impossible to model many dynamics and details of the system. 2 2

The Development of Relational DBMS Now, what should we do when DBMS meets CMP? Architecture-optimized DBMS (MonetDB): Database Architecture Optimized for the New Bottleneck: memory Access (VLDB’99) 1977 – 1997: Parallel DBMS DIRECT, Gamma, Paradise UW-MADISON 1976: DBMS: System R and Ingres (IBM, UC Berkeley) 3 1970: Relational data model (E. F. Codd) 3

An Overview of Multicore System Shared Last Level Cache Main Memory Disk

Current Efforts Reducing IO overhead by exploiting column store and data compression C-Store: A Column Oriented DBMS (VLDB’05) Increasing parallelism with new algorithms and architectures to exploit multi-cores QPipe: Operator-level parallelism (SIGMOD ’05) Exploiting data partitioning to create concurrent subtasks (Adaptive Aggregation on CMP, VLDB’07, DaMon’08) Exploiting shared cache to reduce off-chip accesses Coordinating concurrent main-memory scans (VLDB’08) Scheduling threads for sharing (SPAA’07, EuroSys’07)

Cache Contention Problem Intuitively, concurrent queries will access common dataset, So, there is a good opportunity for multi-cores to exploit constructive data sharing in the last-level cache. However, that is not all. Private data structures created during query execution will cause cache contention in LLC. For example: Private hash table during hash join Private hash table during hash aggregation Private sorted result during sort-merge join

Consider: select * from ta, tb where ta.x = tb.y A Case of Hash Join Consider: select * from ta, tb where ta.x = tb.y Query1 Core 1 Query2 Core 2 HJ HJ Conflict! LLC H H tb Benefit! ta Mem H H ta tb Shared cache is two-fold constructive data sharing and cache contention

Cache Contention During concurrent query executions, cache contention in LLC will cause the following issues: A: Suboptimal Query Plan (Unbalanced Resource usage) B: Incorrect Scheduling Policy (Unnecessary cache conflict) C: Wasted Cache Space (Ineffective cache allocation)

A: Suboptimal Query Plan Query optimizer selects the best plan for a query. Query optimizer is not shared cache aware. A best plan may be suboptimal when concurrent such plans are co-running. Query optimizer doesn’t consider potential cache contention and performance degradation on multicores.

A: Suboptimal Query Plan (cont.) Consider: select * from ta, tb where ta.x = tb.y Cache Sensitive! H ta tb HJ Build a hashtable on ta probe it by tb’s each tuple ta tb IJ tb index For ta’s each tuple lookup tb via index Performance Degradation Reducing allocated cache

B: Incorrect Scheduling Policy (1) Default scheduling is not shared cache aware. (2) We need to co-schedule queries for minimizing cache contentions. Two hashjoins and two table scans on dual cores. Worst scheduling: co-schedule hashjoins (conflict!) Smart scheduling: co-schedule hashjoin and tablescan 30% Improvement!

C: Wasted Cache Space (1) Different queries have different cache utilization. (2) Cache allocation is demand-based by default. But, we should allocate more cache to queries which can best benefit from large cache size. When co-schedule hashjoin and tablescan, allocate more cache to hashjoin! ( ts will pollute cache) 16% Improvement!

Shared Last Level Cache Our Objectives Queries Query Optimizer (1) Query Optimization: To let query optimizer generate optimal query plans based on usage of shared cache (2) Query Scheduling: To pair queries for co-running on multi-cores to minimize cache contentions in shared cache (3) Cache Partitioning: To allocate cache space to maximize cache utilization for co-scheduled queries Query Scheduler Core Shared Last Level Cache Cache Partitioning

Challenges and Opportunities Challenges to design shared cache optimized query execution engine on multicore platforms DBMS is running on user space and is not able to directly control cache allocation in CPU Scheduling Policy: Predict potential cache conflicts among co-running queries Partitioning Policy: Predict cache utilization for different query operations (join, scan , aggregation, sorting,…) Opportunities: Query optimizer can provide hints of data access patterns and estimate working set size during query executions Operation system can manage cache allocation by using page coloring during virtual-physical address mapping.

Summary Optimizing DBMS on CMP is an important research issue. No prior work considers how to reduce cache contention for concurrent query executions. We propose a solution framework containing query optimization, scheduling and cache partitioning. Our solution combines the application knowledge by DBMS and the cache control ability by OS.