SSD/Flash for Modern Databases. Peter Zaitsev, CEO, Percona October 08, 2014 Percona Technical Webinars

Transcription

1 SSD/Flash for Modern Databases Peter Zaitsev, CEO, Percona October 08, 2014 Percona Technical Webinars

2 In this Presentation Flash technology overview Review some of the available technology What does this mean for databases? Specific opportunities for MySQL 2

3 Before SSDs 3

4 There were HDDs Good at Sequential Read/Writes RT=Seek Time + Rotation Latency Reads/Write Similar Latency No Specific Write Limits Retain data for a long time One IO Request in Parallel Low cost per GB 4

5 RAID and SAN 5

6 Using Many HDDs together Caching Reads Buffering Writes (Writeback Cache) Better Sequential Read/Write speed Better throughput at high concurrency Higher IO latencies for uncached IO 6

7 Flash Revolution Use Flash chips instead of platters No moving parts No seeks 7

8 NAND Flash Cell Page/Read Block Erase Block Write but no overwrite Wears with writes (erases) 8

9 Writing to the Flash Erase Write Change Zero to one Set all bits to Set some of the bits to 0: Impossible. Do Erase, when Write 9

10 Types of NAND Flash From AnandTech: 10

11 Flash Storage Design Cache Battery/Super Capacitor Controller + Complex Firmware Built-in Parallelism 11

12 Flash Controller Tasks Write wear leveling Garbage collection Error correction Bad block mapping Read scrubbing Read disturb management Encryption 12

13 Flash Properties Lots of IOs per device! (100K+) Less random IO penalty Writes more expensive than reads Limited by amount of writes Limited retention Concurrent execution on single device Fast write acknowledgement (safe or not) Can burst writes 13

14 Flash Interface Designs DIMM PCI-E SATA/SAS FC and Network 14

15 Sandisk ULLtraDIMM 15

16 HGST Virident 16

17 Sandisk FusionIO 17

18 Intel DC S

19 Crucial M500 19

20 Crucial M500 msata 20

21 Violin Memory 21

22 Consumer vs Enterprise Performance Endurance Durability Retention Encryption 22

23 Not your HDD All HDDs are the same; All SSDs are different 23

24 Evaluation Performance changes over time Complex internals Watch stability carefully 24

25 How Flash Fails Clear write amount defined EOL One day it s gone Internal ECC and redundancy 25

26 To RAID or not to RAID? More valuable for consumer grade Watch for good Flash support RAID controller logic may slow things down Use a redundant array of inexpensive servers instead? 26

27 Redundancy Device internal redundancy Hardware RAID Software RAID Filesystem RAID 27

28 OS Support Flash support is actively being improved TRIM Sparse Files 28

29 Flash And Databases 29

30 Database History Most have been designed in HDD time Optimize for sequential IO Count on cheap sequential writes RAID, BBU to improve performance 30

31 It s time for Flash Your OLTP Database should live on Flash 31

32 But What Flash? Pick a flash type that is right for your application 32

33 IO vs Memory 33

34 Warmup Much faster warmup times Even if the database fits in memory, SSD might be justified 34

35 Tolerate more IO bound load HDD 5ms Can do 20 IO/s for 100ms response time (non parallel) Flash 0.1ms Can do 1000 IO/s for 100ms response time (non parallel) 35

36 Endurance Might be a top consideration 36

37 Endurance Math HGST FlashMax III 2200GB 4400GB/day over 5 Years 1400MB/sec peak writes 66 days at peak write throughput Crucial M GB 72TB total life time writes 400MB/sec write 52 hours at peak write throughput 37

38 Databases and Flash How do we optimize databases to us Flash best? 38

39 Torn Page problem Flash can avoid this with little cost due to internal design FusionIO NVMFS (Atomic Writes) Copy-on-Write File Systems ZFS BTRFS Filesystem level data journaling less preferred data=journal for EXT4 Skip-Innodb-double-write 39

40 Fast IO Path Bypass Caching O_DIRECT Native Asynchronous IO Efficient Checksuming Innodb_checksum_algorithm=crc32 Innodb_flush_method=O_DIRECT 40

41 IO Cost Accounting Sequential vs Random IO balance IO vs CPU Balance Smaller page sizes might make sense innodb_page_size=4k 41

42 Less Pre-fetching Most pre-fetched data must be used Often best to try It out 42

43 Less merging on flushing Do not assume flushing multiple sequential dirty pages has same cost Innodb_flush_neighbors=0 43

44 Less Space on Disk Innodb Compression (2x typical) TokuDB Compression (5-10x typical) Archiving data off OLTP System 44

45 Less Writes on Flash Hybrid Flash/SSD System Transactional Logs, Other logs on the HDD with RAID and BBU Small Temporary objects on tmpfs Innodb_log_file_size=<LARGE> 45

46 Logs on RAID can be fast 46

47 Is Flash Too Fast? Multiple instances might scale better 47

48 Other Thoughts Host hardware matters, especially with high end flash Virtualization has higher relative overhead Network higher relative overhead 48

49 Thank You! Peter 49