Zum Einsatz von SSDs in DBMS: Festplattenersatz … · Memory based Solid State Drives, ... • Random Writes auf gewisse Größe begrenzen ... innodb_secondary_buffer_pool 29 0 45

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

Kai-Uwe SattlerDatabase & Information Systems GroupIlmenau University of Technology, Germanywww.tu-ilmenau.de/dbis

http://www.tu-ilmenau.de/dbis

http://www.tu-ilmenau.de/dbis

Zum Einsatz von SSDs in DBMS | Kai-Uwe Sattler | TU Ilmenau | 09.06.2010▶

Überblick

• Einführung & Motivation

• Funktionsweise & Eigenschaften von SSDs

• Performance-Erwartungen

• Micro-Benchmarking

• SSDs für DBMS

• Konsequenzen

• Fazit & Ausblick

2


Motivation

• Rasant wachsendes Datenvolumen: Google (Melnik @BTW 2009)

• 20 PB Daten täglich verarbeiten

• strukturierte Daten, Text, Bilder, Video

• 15 h Video-Upload jede Minute

• 20 PB von Disk lesen: bei 50 MB/s = 12 Jahre

• 1TB-Disks verfügbar (ab 170 €), aber (Gray 2006):

• 5 .. 15h bei sequentiellem Lesen

• 1 ..150 d bei wahlfreiem Lesen

• heute SATA-I (150 MB/s), SAS-II 6 Gbit/s (500 MB/s)

http://www.flickr.com/photos/nikclayton/1394374289/

3






Motivation

http://kerryosborne.oracle-guy.com/

4

http://kerryosborne.oracle-guy.com/2010/05/exadata-take-2-flash-cache/

http://kerryosborne.oracle-guy.com/2010/05/exadata-take-2-flash-cache/


Kosten für Flash-Speicher

Leventhal: Flash Storage Memory, CACM 51(7), 20085

0

75

150

225

300

2003 2004 2005 2006 2007

Kosten ($) pro GB


Motivation

• „Tape is Dead, Disk is Tape, Flash is Disk, RAM Locality is King“ J. Gray 2006

• seit 1995 Verdopplung der Kapazität

• Preisverfall getrieben durch Bedarf im Consumer-Bereich (von $30 auf $3 pro Chip in 2006)

• 5000 IO-Operationen pro Chip

• Leserate 20 MB/s, Schreibrate 10 MB/s pro Chip - n-fach bei n Chips

• Intel X25-M: 270 MB/s (mit dd gemessen)

• Energiebedarf (www.au-ja.de)

Intel X-25M WD5000AAKS

Lesen/Schreiben 0,15 W 8,77 W

Leerlauf 0,06 W 8,4 W

Ruhezustand 0,06 W 0,97 W

6

http://www.au-ja.de

http://www.au-ja.de


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


Aufbau von SSDs

Controller

Buffer

ECC

SATAInter-face

NAND

NAND

NAND

Cache

n*1000 Blöckea 64 ... 128 Pagesa 2/4 KB Daten+

128 Byte ECC

8


SSD: Operationen

• Zellen-Operationen

• Default-Wert einer Zelle = 1

• Programmierung = Wert 1 ➞ 0

• Löschen (Erase): 0 ➞ 1

• Granularität

• Read/Write-Operationen auf Page-Ebene

• Read: ca. 60 μs, Write: ca. 900 μs

• Erase auf Block-Ebene

• Anzahl der Erase-Operationen:

• ca. 105 für MLC

• aber - bei 50 MB/s gleichmäßiges Beschreiben von 128 GB: ca. 8,5 Jahre

9


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

10


SSD-Anbindung: SATA vs. PCIe

• Intel X25-M (MLC)

• SATA 1.5 Gbit/s und 3 Gbit/s

• Leselatenz: 85 μs

• Bandbreite: 250 MB/s Lesen, 70 MB/s Schreiben

• Leistungsaufnahme: 150 mW

• Preis: 220€ für 80 GB

11

• FusionIO ioDrive (SLC)

• PCIe X4

• Leselatenz: 50 μs

• Bandbreite: 750 MB/s Lesen, 650 MB/s Schreiben

• Preis: ca. 1900€ für 80 GB


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


Was passiert, wenn ...

• MySQL 5.1, SQL-Bench und SysBench auf HDD und SSD (X-25m)

13

0

150000

300000

450000

600000

read write other

Queries Perfomed

0

55

110

165

220

Transactions per sec.

HDD SSD

0

150

300

450

600

alter-table create insert select

sql-bech (secs.)


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


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: http://uflip.inria.fr/~uFLIP/ und Bouganim et al.: uFLIP: Understanding Flash IO Patterns, CIDR 2009

• Chen et al.: Understanding Intrinsic Characteristics and System Implications of Flash Memory based Solid State Drives, SIGMETRICS/Performance 2009

• Baumann et al.: Flashing Databases: Expectations and Limitations, DaMoN 2010

15

http://uflip.inria.fr/~uFLIP/

http://uflip.inria.fr/~uFLIP/

http://event.cwi.nl/damon2010/flashingdb.pdf



Gleichmäßige Latenz bei Leseoperationen?

• Herstellerangabe (2008): 25 ... 60 μs• Experiment: 4KB Leseanforderung, Random, Sequential, Stride

• Erklärung: Readahead, Interleaving beim Lesen mehrerer Planes

16

100

80

60

40

20

0

% R

eque

sts

0,05 0,1 0,15 0,2 0,3 0,4

Lese-Latenz (ms)

SequentialStrideRandom

kumulative Verteilung


Optimale Blockgröße

17

0

75

150

225

300

2 KB 4 KB 8 KB 16 KB 64 KB 256 KB 1 MB

Ban

db

reit

e M

B/s

BlockgrößeSSD random SSD sequential

0

7,5

15,0

22,5

30,0

2 KB 4 KB 8 KB 16 KB 64 KB 256 KB 1 MB 4 MB 16 MB 64 MB

Ban

db

reit

e M

B/s

BlockgrößeHDD random HDD sequential


Sind Random Writes teuer?

• Herstellerangabe (2008): Write = 250 .. 900 μs, Erase = 800 .. 1500 μs

• Experiment: 4 KB Schreibanforderung

• Erklärung: größere Puffer in High-End-Devices

18

100

80

60

40

20

0

% R

eque

sts

0,05 0,1 0,15 0,2 0,3 0,4

Schreib-Latenz (ms)

SequentialStrideRandom

kumulative Verteilung


Welchen Effekt hat Fragmentierung?

• Read-/Write-Workloads vor bzw. nach Fragmentierung

• kein Einfluss auf Random Reads

• signifikante Reduzierung bei Sequential Reads (43 MB/s ➞ 15 MB/s)

19

0

12,5

25,0

37,5

50,0

RND-RD SEQ-RD RND-WR SEQ-WR

unfragmentiert fragmentiert

Ban

db

reit

e M

B/s

ecs.


Interferenzen zwischen Lese- und Schreiboperationen?

• Workload aus 1000 Requests (Read/Write)

• wenig Einfluss bei Write

• write(n)-read(n): Leselatenz durch Flush der internen Caches

20

100

80

60

40

20

0

% R

eque

sts

0,25 0,5 0,75 1,0

Latenz (ms)

write(n)-read(n)only-readread(n)-write(n+1)

100

80

60

40

20

0

% R

eque

sts

0,25 0,5 0,75 1,0

Latenz (ms)

write(n)-read(n)only-readread(n)-write(n+1)


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


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’08

• 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 2003

• Flash-Operationen: Joins, Scans, ...

• Tsirogiannis et al.: Query Processing Techniques for Solid State Drives, SIGMOD‘09

22


SSDs für Transaction Log

• Idee: geringe Schreiblatenz für Logging nutzen

• Experiment: kommerzielles DBMS mit SSD für Transaction Log

• Fazit: IO-Begrenzung kann zu CPU-Begrenzung führen!

23

0

1750

3500

5250

7000

4 8 16 32 64

Transactions per second

HDD SSD

Anz. paralleler Transaktionen

0

22,5

45,0

67,5

90,0

4 8 16 32 64

CPU-Auslastung

Anz. paralleler Transaktionen


SSDs für temporäre Tablespaces

• Nutzung für externes Sortieren, Hash Joins, Sort-Merge Joins, ...

• IO-Muster

24

250

200

150

100

50

0

Log.

Sek

tora

dres

se

10 20 30 40 60 80

Zeit50 70 90

250

200

150

100

50

0

Log.

Sek

tora

dres

se

10 20 30 40 60 80

Zeit50 70 90

HDD SSD


SSDs für temporäre Tablespaces /2

• Sort-Performance

25

0

75

150

225

300

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

Aufwand für externes Sortieren

HDD SSD

Puffergröße (MB)

Lauf

zeit

(sec

s.)


Flash Cache

• eingeführt mit Sun‘s ZFS: Level 2 ARC

http://blogs.sun.com/brendan/entry/test

RAM

Disk Storage Pool

L2ARC ZIL

Main Memory Cache(DRAM)

SSD Layer

Flash Cachefür Reads

Log Device für Writes

26




Oracle Exadata

• Vorkonfigurierte RAC Database Machine

• DBS: 64 Nehalem Cores, 576 GB RAM

• Netzwerk: InfiniBand 40 Gbit/s

• Exadata Storage Server:

• 112 Nehalem Cores, 336 GB RAM

• 100 TB SAS HDD

• 5 TB Flash Cache

• Flash Cache

• automatischer Write-through Cache

• von Hand:create table emp( ... )storage (flash_cache keep)

27


Oracle Exadata

28


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

29

0

45

90

135

180

ohne FlashCache mit FlashCache

Sysbench - tps

4 Disk RAID10, X25-M 40 GB Cache

0

1250

2500

3750

5000

0 MB 512 MB 920 MB

TPC-C (tpmC), 1.2 GB DB


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‘07

30


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

31

100

30 60 95 150 200

10 40 70 97 120 ...

20 25 85

Primärschlüssel

Inhalt

Inhalte20 25 85 IndexUnits

Flash Translation Layer

Sektor 1 Sektor 2

ReservationBuffer

Logische Sicht auf B-Baum

BFTL


BFTL: Performance

• 8 MB-NAND-Prototyp, Anzahl Seiten nach 24.000 eingefügten Schlüsseln

32

0

10000

20000

30000

40000

0 0,2 0,4 0,6 0,8 1

BFTL FTL

#Pag

es W

rite

Anteil geordneter Schlüssel beim Einfügen Anteil geordneter Schlüssel beim Einfügen #P

ages

Rea

d0

25000

50000

75000

100000

0 0,2 0,4 0,6 0,8 1


Anfrageoperationen: FlashScan

• Idee: Ausnutzung der kleineren möglichen Blockgrößen

• Page-Format: klassisches NSM vs. PAX

1 1 1 1 0 0 0 0 0

1042104310441045

Jamaica BlueArabica Black

New York EspressoArabica Black

1 1 1 1 0 0 0 0 0

Miniseite fürProdNr

Miniseite fürBezeichnung

Präsenzbits

Miniseitenverzeichnis

17,9914,9516,9511,99

Miniseite fürPreis

Satz-verzeichnis

33


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‘09

34

0

37,5

75,0

112,5

150,0

0% 20% 40% 60% 80% 100%

NSMScanFlashScan 100% SELFlashScan 0.01% SEL

Projektivität

Lauf

zeit

(sec

)


Anfrageoperatoren: Standard Joins

• Performance von Standard-Join-Operationen • Do, Patel: Join Processing for Flash SSDs: Remembering Past Lessons, DaMoN 2009• 5400 RPM HDD vs. OCZ SATA-II SSD

35

0

1,25

2,50

3,75

5,00

Block Nested Loop Sort Merge Grace Hash Hybrid Hash

Speedup für SSD-Varianten gegenüber HDD (100 MB Bufferpool)

Join TimeIO Time


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


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


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


Literatur

• Leventhal: Flash Storage Memory, CACM 51(7), 2008

• Graefe: The five-minute rule 20 years later (and how flash memory changes the rules). CACM 52(7), 2009

• Do, Patel: Join Processing for Flash SSDs: Remembering Past Lessons, DaMoN 2009

• Bouganim et al.: uFLIP: Understanding Flash IO Patterns, CIDR 2009

• Chen et al.: Understanding Intrinsic Characteristics and System Implications of Flash Memory based Solid State Drives, SIGMETRICS/Performance 2009

• Lee et al.: A Case for Flash Memory SSD in Enterprise Database Systems, SIGMOD 2008

• Wu, Chang, Kuo: An Efficient B-Tree Layer for Flash-Memory Storage Systems, Real-Time and Embedded Computing Systems and Applications 2003

• Tsirogiannis et al.: Query Processing Techniques for Solid State Drives, SIGMOD 2009

• Baumann, Nijs, Strobel, Sattler: Flashing Databases: Expectations and Limitations, DaMoN 2010

39

http://dblp.uni-trier.de/db/journals/cacm/cacm52.html#Graefe09a

http://dblp.uni-trier.de/db/journals/cacm/cacm52.html#Graefe09a



Documents

Zum Einsatz von SSDs in DBMS: Festplattenersatz … · Memory based Solid State Drives, ... • Random Writes auf gewisse Größe begrenzen ... innodb_secondary_buffer_pool 29 0 45