This document discusses using solid state drives (SSDs) as a cache to supplement hard disk drives (HDDs) in MySQL databases. It presents Flash as Cache Extension (FaCE), which caches MySQL pages in SSDs to provide faster random reads and writes compared to HDDs. FaCE uses optimizations like group replacement and second chance to improve SSD throughput and caching hit rates. The document evaluates FaCE and finds it provides 40-50% higher transactions per minute than MySQL without caching. It identifies opportunities to further optimize FaCE through techniques like group second chance and multi-stream SSD implementation.

1. MySQL with FaCE
안미진
7/4/2016 1

2. Contents
7/4/2016 2
• Introduction
• Flash as Cache Extension (FaCE)
– Design Choices
– Two Optimizations
• MySQL Buffer Management
• MySQL with FaCE
• Performance Evaluation
• Current Issue & Future Work

3. Introduction
7/4/2016 3
• IOPS/$: SSDs >> HDDs
• GB/$: HDDs >> SSDs
• Therefore, it is more sensible to use SSDs to supplement HDDs,
rather than to replace them
– SSD as cache between RAM and HDDs
– To provide both the performance of SSDs and the capacity of HDDs as
little cost as possible

4. Flash as Cache Extension (FaCE)
7/4/2016 4
Storage (HDD)
FaCE (SSD)
RAM Buffer (LRU)
Random
Read
Random Read
 Low cost
Sequential Write
 High throughput
Random
Write
 Faster recovery

5. FaCE: Design Choices
7/4/2016 5
1. When to cache pages in SSD?
: on entry vs. on exit
2. What pages to cache in SSD?
: clean vs. dirty vs. both
3. Sync policy between SSD and HDD
: write-thru vs. write-back
4. SSD Cache Replacement Policy
: LRU vs. FIFO

6. Design Choices: SSD Cache Replacement Policy
7/4/2016 6
• LRU vs. FIFO (First-In-First-Out)
– Write miss: LRU‐based victim selection, write‐back if dirty victim, and
overwrite the old victim page with the new page being evicted
– Write hit: overwrite the old copy in flash cache with the updated
page being evicted
RAM Buffer (LRU) Flash as Cache Extension
Storage (HDD)
Evict
SSD cache is full!
Random writes
against SSD

7. Design Choices: SSD Cache Replacement Policy
7/4/2016 7
• LRU vs. FIFO (First-In-First-Out)
– Victims are chosen from the rear end of flash cache
 “Sequential writes” against SSD
– Write hit : no additional action is taken in order not to incur random
writes
– Multi-Version FIFO (mvFIFO)
SSD cache is full!
RAM Buffer (LRU)
A
Flash as Cache Extension
Storage (HDD)
B
Evict
A
Old version
Latest version
A

8. Design Choices: SSD Cache Replacement Policy
7/4/2016 8
• LRU vs. FIFO (First-In-First-Out)
– Write reduction in mvFIFO
– Reduce three writes to HDD to one
RAM Buffer (LRU) Flash as Cache Extension
Storage (HDD)
A
Evict
A A
V3 V1 V2
Old version
Latest version

9. mvFIFO: Two Optimizations
7/4/2016 9
• Group Replacement (GR)
– Multiple pages are replaced in a group in order to exploit the internal
parallelism in modern SSDs
– GR can improve SSD I/O throughput
• Group Second Chance (GSC)
– GR + Second chance
– if a victim candidate page is valid and referenced, will re-enque the
victim to SSD cache
– GSC can achieve higher hit ratio and more write reductions

10. Group Replacement (GR)
7/4/2016 10
1. Single group read from SSD (64/128 pages)
2. Batch random writes to HDD
3. Single group write to SSD
RAM Buffer (LRU) Flash as Cache Extension
Storage (HDD)
Evict
Fetch on miss
RAM
Check valid
and dirty flag
SSD cache
is full!

11. Group Second Chance (GSC)
7/4/2016 11
• GR + Second Chance
RAM Buffer (LRU) Flash as Cache Extension
Storage (HDD)
Evict
RAM
Check reference bit,
If true, give them 2nd chance
SSD cache
is full!
Reference bit is ON
Fetch on miss

12. DB Files
MySQL Buffer Management
7/4/2016 12
RAM Buffer (LRU)
Evict & Stage out dirty pages
Fetch on miss
Doublewrite Buffer
pp
Storage (HDD/SSD)

13. MySQL with FaCE
7/4/2016 13
• FaCE turns small random writes to large sequential ones
– Maximize the I/O throughput of a flash caching device
• FaCE can be used to recover the system more quickly
• We don’t need to use double write buffer for recovery
• Reduce two writes to HDD to one

14. Dirty Page in FaCE
7/4/2016 14
DB Files
RAM Buffer (LRU) Flash as Cache Extension
Evict
Fetch on miss
Stage out
dirty pages
Doublewrite Buffer
SSD cache is full!
Storage (HDD/SSD)
p

15. Clean Page in FaCE (1)
7/4/2016 15
DB Files
RAM Buffer (LRU) Flash as Cache Extension
Evict
Fetch on miss
Stage out
dirty pages
Doublewrite Buffer
p
SSD cache is full!
Storage (HDD/SSD)
p p

16. Clean Page in FaCE (2)
7/4/2016 16
DB Files
RAM Buffer (LRU) Flash as Cache Extension
Evict
Fetch on miss
Stage out
dirty pages
Doublewrite Buffer
SSD cache is full!
Storage (HDD/SSD)
p

17. Performance Evaluation
7/4/2016 17
Database Size Flash cache size
Transaction per minute Count (TpmC)
Original FaCE Dirty-Only
100G 20G 5637 8168
50G 10G 5758 8347
10G 2G 5812 8708
• MySQL with FaCE Dirty-Only shows about 40~50% higher
TpmC than original MySQL
• No GR, No GSC

18. Current Issue & Future work
7/4/2016 18
• Current Issue
– Implementation of Group Second Chance (GSC)
• Future Work
– Implementation of FaCE on Multi-stream SSD
– Copy-back victims when evictions occur in RAM buffer and flush
them using background flusher (for mixed version of FaCE)

19. Future Work (1)
7/4/2016 19
DB Files
RAM Buffer (LRU) Flash as Cache Extension
Evict
Fetch on miss
Stage out
dirty pages
Doublewrite Buffer
Storage (HDD/SSD)
Temporary Buffer
Background Flusher
Memory
p