MySQL with FaCE Optimizes Database Performance
•
0 j'aime•547 vues
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.
Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à MySQL with FaCE Optimizes Database Performance
Similaire à MySQL with FaCE Optimizes Database Performance (20)
Dernier
Dernier (20)
MySQL with FaCE Optimizes Database Performance
- 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
Notes de l'éditeur
- 지금부터 제가 지금까지 MySQL에 FaCE를 어떻게 구현했고, 앞으로 할 일이 무엇인지에 대해 발표하겠습니다.
- SSD의 용량당 가격은 크게 감소했지만, HDD와 SSD 사이 에는 여전히 큰 가격 차이가 존재한다. 그래서 HDD를 SSD로 완전히 대체하 는 것보다 HDD의 성능을 보완하기 위해 SSD를 추가하여 사용하는 것이 더 경제적이다.
- 이러한 맥락으로 제안된 Flash-aware Cache Extension(FaCE)은 낮은 오버헤드로 플래시메모리를 DRAM 버퍼의 확장으로 사용하는 캐싱 전략이다.