Weaving Relations for Cache Performance - PowerPoint PPT Presentation

About This Presentation
Title:

Weaving Relations for Cache Performance

Description:

Selectivity doesn't matter for PAX data stalls. Effect on Accessing Cache Data ... Lower selectivity = reads dominate speedup. High selectivity = speedup ... – PowerPoint PPT presentation

Number of Views:59
Avg rating:3.0/5.0
Slides: 24
Provided by: anastassi1
Category:

less

Transcript and Presenter's Notes

Title: Weaving Relations for Cache Performance


1
Weaving Relations for Cache Performance
  • Anastassia Ailamaki
  • Carnegie Mellon

David DeWitt, Mark Hill, and Marios
Skounakis University of Wisconsin-Madison
2
Memory Hierarchies
PROCESSOR EXECUTION PIPELINE
MAIN MEMORY
3
Processor/Memory Speed Gap
1 access to memory ? 1000 instruction
opportunities
4
Breakdown of Memory Delays
  • PII Xeon running NT 4.0, 4 commercial DBMSs
    A,B,C,D
  • Memory-related delays 40-80 of execution time

Data accesses on caches 19-86 of memory stalls
5
Data Placement on Disk Pages
  • Slotted Pages Used by all commercial DBMSs
  • Store table records sequentially
  • Intra-record locality (attributes of record r
    together)
  • Doesnt work well on todays memory hierarchies
  • Alternative Vertical partitioning Copeland85
  • Store n-attribute table as n single-attribute
    tables
  • Inter-record locality, saves unnecessary I/O
  • Destroys intra-record locality gt expensive to
    reconstruct record
  • Contribution Partition Attributes Across
  • have the cake and eat it, too

Inter-record locality low record reconstruction
cost
6
Outline
  • The memory/processor speed gap
  • Whats wrong with slotted pages?
  • Partition Attributes Across (PAX)
  • Performance results
  • Summary

7
Current Scheme Slotted Pages
Formal name NSM (N-ary Storage Model)
1237
RH1
PAGE HEADER
R
30
Jane
RH2
4322
John
RID SSN Name Age
1 1237 Jane 30
2 4322 John 45
3 1563 Jim 20
4 7658 Susan 52
5 2534 Leon 43
6 8791 Dan 37
45
RH3
Jim
20
RH4
1563
7658
Susan
52
?
?
?
?
  • Records are stored sequentially
  • Offsets to start of each record at end of page

8
Predicate Evaluation using NSM
1237
RH1
PAGE HEADER
30
Jane
RH2
4322
John
45
RH3
Jim
20
RH4
1563
7658
52
2534
Leon
Susan
CACHE
?
?
?
?
select name from R where age gt 50
MAIN MEMORY
NSM pushes non-referenced data to the cache
9
Need New Data Page Layout
  • Eliminates unnecessary memory accesses
  • Improves inter-record locality
  • Keeps a records fields together
  • Does not affect I/O performance
  • and, most importantly, is

low-implementation-cost, high-impact
10
Partition Attributes Across (PAX)
NSM PAGE
PAX PAGE
1237
RH1
PAGE HEADER
PAGE HEADER
1237
4322
30
Jane
RH2
4322
John
1563
7658
45
RH3
Jim
20
RH4
1563
7658
Susan
52
Jane
John
Jim
Susan
?
?
?
?
30
45
20
52
?
?
?
?
Partition data within the page for spatial
locality
11
Predicate Evaluation using PAX
PAGE HEADER
1237
4322
1563
7658
Jane
John
Jim
Suzan
CACHE
?
?
?
?
30
45
20
52
select name from R where age gt 50
MAIN MEMORY
Fewer cache misses, low reconstruction cost
12
A Real NSM Record
FIXED-LENGTH VALUES
VARIABLE-LENGTH VALUES
HEADER
offsets to variable- length fields
null bitmap, record length, etc
NSM All fields of record stored together slots
13
PAX Detailed Design
free space
records
attribute sizes
attributes

Page Header
pid
3
2
f

F - Minipage
presence bits

V - Minipage
v-offsets

F - Minipage
presence bits
PAX Group fields amortizes record headers
14
Outline
  • The memory/processor speed gap
  • Whats wrong with slotted pages?
  • Partition Attributes Across (PAX)
  • Performance results
  • Summary

15
Sanity Check Basic Evaluation
  • Main-memory resident R, numeric fields
  • Query
  • select avg (ai)
  • from R
  • where aj gt Lo and aj lt Hi
  • PII Xeon running Windows NT 4
  • 16KB L1-I, 16KB L1-D, 512 KB L2, 512 MB RAM
  • Used processor counters
  • Implemented schemes on Shore Storage Manager
  • Similar behavior to commercial Database Systems

16
Why Use Shore?
  • Compare Shore query behavior with commercial DBMS
  • Execution time memory delays (range selection)

We can use Shore to evaluate DSS workload behavior
17
Effect on Accessing Cache Data
  • PAX saves 70 of NSMs data cache penalty
  • PAX reduces cache misses at both L1 and L2
  • Selectivity doesnt matter for PAX data stalls

18
Time and Sensitivity Analysis
  • PAX 75 less memory penalty than NSM (10 of
    time)
  • Execution times converge as number of attrs
    increases

19
Evaluation Using a DSS Benchmark
  • 100M, 200M, and 500M TPC-H DBs
  • Queries
  • Range Selections w/ variable parameters (RS)
  • TPC-H Q1 and Q6
  • sequential scans
  • lots of aggregates (sum, avg, count)
  • grouping/ordering of results
  • TPC-H Q12 and Q14
  • (Adaptive Hybrid) Hash Join
  • complex where clause, conditional aggregates
  • 128MB buffer pool

20
TPC-H Queries Speedup
  • PAX improves performance even with I/O
  • Speedup differs across DB sizes

21
Updates
  • Policy Update in-place
  • Variable-length Shift when needed
  • PAX only needs shift minipage data
  • Update statement
  • update R
  • set apap b
  • where aq gt Lo and aq lt Hi

22
Updates Speedup
  • PAX always speeds queries up (7-17)
  • Lower selectivity gt reads dominate speedup
  • High selectivity gt speedup dominated by
    write-backs

23
Summary
  • PAX a low-cost, high-impact DP technique
  • Performance
  • Eliminates unnecessary memory references
  • High utilization of cache space/bandwidth
  • Faster than NSM (does not affect I/O)
  • Usability
  • Orthogonal to other storage decisions
  • Easy to implement in large existing DBMSs
Write a Comment
User Comments (0)
About PowerShow.com