Zum Einsatz von SSDs in DBMS: Festplattenersatz oder Herausforderung an neue Speicherstrukturen?!

Transkript

1 Zum Einsatz von SSDs in DBMS: Festplattenersatz oder Herausforderung an neue Speicherstrukturen?! Kai-Uwe Sattler Database & Information Systems Group Ilmenau University of Technology, Germany

2 Überblick Einführung & Motivation Funktionsweise & Eigenschaften von SSDs Performance-Erwartungen Micro-Benchmarking SSDs für DBMS Konsequenzen Fazit & Ausblick 2

3 Motivation Rasant wachsendes Datenvolumen: Google 29) 2 PB Daten täglich verarbeiten strukturierte Daten, Text, Bilder, Video 15 h Video-Upload jede Minute 2 PB von Disk lesen: bei 5 MB/s = 12 Jahre 1TB-Disks verfügbar (ab 17 ), aber (Gray 26): h bei sequentiellem Lesen d bei wahlfreiem Lesen nikclayton/ / heute SATA-I (15 MB/s), SAS-II 6 Gbit/s (5 MB/s) 3

4 Motivation 4

5 Kosten für Flash-Speicher 3 Kosten ($) pro GB Leventhal: Flash Storage Memory, CACM 51(7), 28 5

6 Motivation Tape is Dead, Disk is Tape, Flash is Disk, RAM Locality is King J. Gray 26 seit 1995 Verdopplung der Kapazität Preisverfall getrieben durch Bedarf im Consumer-Bereich (von $3 auf $3 pro Chip in 26) 5 IO-Operationen pro Chip Leserate 2 MB/s, Schreibrate 1 MB/s pro Chip - n-fach bei n Chips Intel X25-M: 27 MB/s (mit dd gemessen) Energiebedarf ( Intel X-25M WD5AAKS Lesen/Schreiben,15 W 8,77 W Leerlauf,6 W 8,4 W Ruhezustand,6 W,97 W 6

7 Was sind SSDs? Halbleiterlaufwerke meist auf Basis von Flash Memory NOR vs. NAND Single-Level Cell (SLC): nur 1 Bit pro Zelle Multi-Level Cell (MLC): mehrere Bits pro Zelle (meist 4) langsamer, kürzere Lebenszeit höhere Dichte = höhere Kapazität 7

8 Aufbau von SSDs N A N D Cache Buffer SATA Interface Controller N A N D n*1 Blöcke a Pages a 2/4 KB Daten+ 128 Byte ECC ECC N A N D 8

9 SSD: Operationen Zellen-Operationen Default-Wert einer Zelle = 1 Programmierung = Wert 1 Löschen (Erase): 1 Granularität Read/Write-Operationen auf Page-Ebene Read: ca. 6 μs, Write: ca. 9 μs Erase auf Block-Ebene Anzahl der Erase-Operationen: ca. 1 5 für MLC aber - bei 5 MB/s gleichmäßiges Beschreiben von 128 GB: ca. 8,5 Jahre 9

10 SSD-Organisation: Flash Translation Layer Block Mapping Abbildung zwischen logischen Blockadressen (LBA) und physischen Flash-Pages direkte Map + indirekte Map (für Recovery) Notwendigkeit: kein Write in Place möglich jede Write-Operation auf logischer Page geht zu anderer phys. Page Wear Leveling Vermeiden der Lokalität von Write-Operationen (Verkürzung der Lebenszeit) Garbage Collection Schreiben auf neue Blöcke erfordert Recycling alter Blöcke 1

11 SSD-Anbindung: SATA vs. PCIe Intel X25-M (MLC) SATA 1.5 Gbit/s und 3 Gbit/s Leselatenz: 85 μs Bandbreite: 25 MB/s Lesen, 7 MB/s Schreiben Leistungsaufnahme: 15 mw Preis: 22 für 8 GB FusionIO iodrive (SLC) PCIe X4 Leselatenz: 5 μs Bandbreite: 75 MB/s Lesen, 65 MB/s Schreiben Preis: ca. 19 für 8 GB 11

12 Erwartungen schnelle wahlfreie und sequenzielle Lesezugriffe kein Unterschied zwischen wahlfreien und sequenziellen Zugriffen geringe und konstante Latenz aufgrund fehlender mechanischer Teile kleine Blöckgrößen möglich schneller als HDDs Schreiben wesentlich langsamer als Lesen 12

13 Was passiert, wenn... MySQL 5.1, SQL-Bench und SysBench auf HDD und SSD (X-25m) 6 Queries Perfomed 6 sql-bech (secs.) read write other 22 Transactions per sec alter-table create insert select HDD SSD 13

14 DB-Beschleunigung durch SSDs? Ja, aber... auf welcher Speicherebene (extern, Cache,...)? für welche Workloads? große Unterschiede der SSDs (Softwareimplementierung, Cache,...) komplexes internes Design Performance-Tuning kompliziert Anpassung der DBMS-Datenstrukturen? Bechmarking auf Raw-Device-Ebene auf DB-Ebene Datenstrukturen und DB-Operationen 14

15 Micro-Bechmarking: Raw Device-Ebene Fragestellungen konstante Latenz für Leseoperationen? Bandbreite vs. Blockgröße? Effekte der Fragmentierung? Wie teuer ist Schreiben wirklich? Interferenzen zwischen Lese-/Schreiboperationen bzw. Hintergrundoperationen Quellen: uflip-benchmark: und Bouganim et al.: uflip: Understanding Flash IO Patterns, CIDR 29 Chen et al.: Understanding Intrinsic Characteristics and System Implications of Flash Memory based Solid State Drives, SIGMETRICS/Performance 29 Baumann et al.: Flashing Databases: Expectations and Limitations, DaMoN 21 15

16 Gleichmäßige Latenz bei Leseoperationen? Herstellerangabe (28): μs Experiment: 4KB Leseanforderung, Random, Sequential, Stride kumulative Verteilung 1 8 % Requests Random Stride Sequential,5,1,15,2,3,4 Lese-Latenz (ms) Erklärung: Readahead, Interleaving beim Lesen mehrerer Planes 16

17 Optimale Blockgröße 3, 3 Bandbreite MB/s 22,5 15, 7,5 Bandbreite MB/s KB 4 KB 8 KB 16 KB 64 KB 256 KB 1 MB 4 MB 16 MB 64 MB Blockgröße HDD random HDD sequential 2 KB 4 KB 8 KB 16 KB 64 KB 256 KB 1 MB Blockgröße SSD random SSD sequential 17

18 Sind Random Writes teuer? Herstellerangabe (28): Write = μs, Erase = μs Experiment: 4 KB Schreibanforderung kumulative Verteilung 1 8 % Requests Random Stride Sequential,5,1,15,2,3,4 Schreib-Latenz (ms) Erklärung: größere Puffer in High-End-Devices 18

19 Welchen Effekt hat Fragmentierung? Read-/Write-Workloads vor bzw. nach Fragmentierung 5, Bandbreite MB/secs. 37,5 25, 12,5 RND-RD SEQ-RD RND-WR SEQ-WR unfragmentiert fragmentiert kein Einfluss auf Random Reads signifikante Reduzierung bei Sequential Reads (43 MB/s 15 MB/s) 19

20 Interferenzen zwischen Lese- und Schreiboperationen? Workload aus 1 Requests (Read/Write) % Requests 6 4 % Requests read(n)-write(n+1) only-read write(n)-read(n) 2 read(n)-write(n+1) only-read write(n)-read(n),25,5,75 1, Latenz (ms) wenig Einfluss bei Write,25,5,75 1, Latenz (ms) write(n)-read(n): Leselatenz durch Flush der internen Caches 2

21 Zwischenfazit geringe Latenz durch komplexen Software-Layer größere IO-Einheiten Empfehlung für Blöckgröße: 32 KB (Vielfachs von Flash-Pages) Random Writes auf gewisse Größe begrenzen (für MB wie Sequential Write) konkurrierende IO-Zugriffe bis zu gewissem Maße ohne Einfluss Opimierung der Datenorganisation auf Disk weiterhin notwendig Scheduling der IO-Operationen dynamisches Block-Mapping kann mit der Zeit zu Performance- Änderungen führen 21

22 Einsatz in DBMS Device für spezielle Aufgaben: Transaction Log, Rollback Segment, Temporary Table Spaces Lee et al.: A Case for Flash Memory SSD in Enterprise Database Systems, SIGMOD 8 als Cache Flash Cache in Oracle Exadata, Flash Cache für MySQL spezialisierte Datenstrukturen: B-Tree-Varianten, Cluster-Strukturen Wu, Chang, Kuo: An Efficient B-Tree Layer for Flash-Memory Storage Systems, Real- Time and Embedded Computing Systems and Applications 23 Flash-Operationen: Joins, Scans,... Tsirogiannis et al.: Query Processing Techniques for Solid State Drives, SIGMOD 9 22

23 SSDs für Transaction Log Idee: geringe Schreiblatenz für Logging nutzen Experiment: kommerzielles DBMS mit SSD für Transaction Log HDD SSD 7 Transactions per second 9, CPU-Auslastung , , , Anz. paralleler Transaktionen Fazit: IO-Begrenzung kann zu CPU-Begrenzung führen! Anz. paralleler Transaktionen 23

24 SSDs für temporäre Tablespaces Nutzung für externes Sortieren, Hash Joins, Sort-Merge Joins,... IO-Muster Log. Sektoradresse 15 1 HDD Log. Sektoradresse 15 1 SSD Zeit Zeit 24

25 SSDs für temporäre Tablespaces /2 Sort-Performance 3 Aufwand für externes Sortieren HDD SSD 225 Laufzeit (secs.) Puffergröße (MB) 25

26 Flash Cache eingeführt mit Sun s ZFS: Level 2 ARC Flash Cache für Reads RAM Main Memory Cache (DRAM) SSD Layer L2ARC ZIL Log Device für Writes Disk Storage Pool 26

27 Oracle Exadata Vorkonfigurierte RAC Database Machine DBS: 64 Nehalem Cores, 576 GB RAM Netzwerk: InfiniBand 4 Gbit/s Exadata Storage Server: 112 Nehalem Cores, 336 GB RAM 1 TB SAS HDD 5 TB Flash Cache Flash Cache automatischer Write-through Cache von Hand: create table emp(... ) storage (flash_cache keep) 27

28 Oracle Exadata 28

29 Flash Cache für MySQL Secondary Bufferpool: aus Main-Memory-Bufferpool verdrängte Seiten werden auf SSD ausgelagert im Fall von MM-Bufferpool-Misses: Lookup im Flash Cache Implementiert von Facebook-Mitarbeitern: innodb_secondary_buffer_pool 18 Sysbench - tps 5 TPC-C (tpmc), 1.2 GB DB ohne FlashCache mit FlashCache MB 512 MB 92 MB 4 Disk RAID1, X25-M 4 GB Cache 29

30 B+-Baum auf SSDs Variante 1: SSDs als normales Block Device B+-Baum-Knoten werden in aufeinander folgenden Flash Pages gespeichert Vorteil: einfache Portierung Nachteil: teuere Updates, auch bei kleinen Änderungen ggf. Schreiben in neue physische Page + Garbage Collection Variante 2: Log-basierter Ansatz Änderungen im B+-Baum als Log-Eintrag in Main-Memory-Buffer; bei Überlauf auf Flash schreiben Vorteil: geringe Update-Kosten Nachteil: Lesen ist aufwendiger, da Rekonstruktion über Log-Einträge Variante 3: Kombination aus beiden = Self Tuning B+Tree Nath, Kansal: FlashDB: Dynamic Self-tuning Database for NAND Flash, IPSN 7 3

31 BFTL: B-Tree Layer for Flash Memory Wu, Chang, Kuo: An Efficient B-Tree Layer for Flash-Memory Storage Systems, Real-Time and Embedded Computing Systems and Applications 23. Logische Sicht auf B-Baum Inhalt Primärschlüssel Reservation Buffer Index Units Inhalte BFTL Sektor 1 Sektor 2 31 Flash Translation Layer

32 BFTL: Performance 8 MB-NAND-Prototyp, Anzahl Seiten nach 24. eingefügten Schlüsseln #Pages Write 2 1 #Pages Read 5 25,2,4,6,8 1,2,4,6,8 1 Anteil geordneter Schlüssel beim Einfügen Anteil geordneter Schlüssel beim Einfügen BFTL FTL 32

33 Anfrageoperationen: FlashScan Idee: Ausnutzung der kleineren möglichen Blockgrößen Page-Format: klassisches NSM vs. PAX Miniseitenverzeichnis Präsenzbits Miniseite für ProdNr Satzverzeichnis Arabica Black New York Espresso Miniseite für Bezeichnung Arabica Black Jamaica Blue Miniseite für Preis 11,99 16,95 14,95 17,99 33

34 Anfrageoperationen: FlashScan Reduzierung der Scans auf tatsächlich benötigte Spalten durch Verwendung von PAX-Seiten Tsirogiannis et al.: Query Processing Techniques for Solid State Drives, SIGMOD 9 15, 112,5 Laufzeit (sec) 75, 37,5 NSMScan FlashScan 1% SEL FlashScan.1% SEL % 2% 4% 6% 8% 1% Projektivität 34

35 Anfrageoperatoren: Standard Joins Performance von Standard-Join-Operationen Do, Patel: Join Processing for Flash SSDs: Remembering Past Lessons, DaMoN RPM HDD vs. OCZ SATA-II SSD 5, Speedup für SSD-Varianten gegenüber HDD (1 MB Bufferpool) 3,75 2,5 Join Time IO Time 1,25 Block Nested Loop Sort Merge Grace Hash Hybrid Hash 35

36 Fazit kleinere Blockgrößen möglich spezielle Scans, Seitengrößen für B-Baum-Indexe, multidimensionales Clustering Tendenz zu CPU-Begrenzung (im Vergleich zu IO-Begrenzung bei HDD) Random Reads für Random Writes Random Writes produzieren größere IO-Varianz, dadurch weniger vorhersagbar Blocked IO kann Performance signifikant verbessert: Latenz der Software-Layers größere IO-Einheiten generieren weniger Erase-Operationen 36

37 Einsatzszenarien für DBMS als schnellere Festplatte: teuer, Schreiblatenz bei Update-in-Place ermöglicht kleinere Blöckgrößen, erfordert Anpassung von Datenstrukturen als 2nd-Level-Cache (Write-through Cache): Beschleunigung der Leseoperationen kein Einfluss auf Schreiboperationen geringe Kosten im Vergleich zur reinen SSD-Nutzung als Medium für spezielle Zwecke (Logging, Rollback, temporäre Tabellen): Ausnutzung geringer Latenzen für Schreiboperationen eventuell Probleme durch begrenzte Anzahl von Schreibvorgängen 37

38 Zusammenfassung & Ausblick signifikante IO-Beschleunigung für DBMS durch SSDs permanente Weiterentwicklung komplexer Software-Layer IO-Begrenzung kann zur CPU-Begrenzung werden verschiedene Einsatzmöglichkeiten FlashCache - zusätzliche Speicherebene jedoch kein naiver Festplattenersatz (Preis vs. Nutzen) Einfluss auf DBMS-Architektur physische Datenorganisation: Indexe, Clustering Operatoren & Logging Kostenmodell Interface für SSDs: SATA / SAS vs. PCIe? 38

39 Literatur Leventhal: Flash Storage Memory, CACM 51(7), 28 Graefe: The five-minute rule 2 years later (and how flash memory changes the rules). CACM 52 (7), 29 Do, Patel: Join Processing for Flash SSDs: Remembering Past Lessons, DaMoN 29 Bouganim et al.: uflip: Understanding Flash IO Patterns, CIDR 29 Chen et al.: Understanding Intrinsic Characteristics and System Implications of Flash Memory based Solid State Drives, SIGMETRICS/Performance 29 Lee et al.: A Case for Flash Memory SSD in Enterprise Database Systems, SIGMOD 28 Wu, Chang, Kuo: An Efficient B-Tree Layer for Flash-Memory Storage Systems, Real-Time and Embedded Computing Systems and Applications 23 Tsirogiannis et al.: Query Processing Techniques for Solid State Drives, SIGMOD 29 Baumann, Nijs, Strobel, Sattler: Flashing Databases: Expectations and Limitations, DaMoN 21 39