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

2. 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

3. 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

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

5. 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)

6. 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

7. 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

8. 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)

9. 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.

10. 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

11. 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!

12. 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!

13. 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

14. 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.

15. 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.