SSD For Databases. Vadim Tkachenko Peter Zaitsev Percona April 2016

Transcription

1 SSD For Databases Vadim Tkachenko Peter Zaitsev Percona April 2016

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

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 Low cost per GB 4

5 RAID and SAN

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 Set all bits to Write Set some of the bits to 0: Change Zero to one 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 and Firmware Tasks Write wear leveling Garbage collection Error correction Bad block mapping Read disturb management Encryption 12

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

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

15 Transitioning AHCI NVMe 15

16 AHCI vs NVMe Source: AnandTech.com 16

17 Some Product Examples Products and Leaders are changing quickly 17

18 Sandisk ULLtraDIMM 18

19 HGST Virident 19

20 Sandisk FusionIO 20

21 Intel P3x00 21

22 Intel

23 Intel 730 (SATA) 23

24 msata 24

25 M.2 Interface 25

26 Violin Memory 26

27 Consumer vs Enterprise Performance Endurance Durability Retention Encryption 27

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

29 Evaluation Performance changes over time Empty Space Matters Complex internals Watch stability carefully 29

30 How Flash Fails Write amount defined EOL (but often can handle a lot more) One day it s gone Internal ECC and redundancy 30

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

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

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

34 Flash And Databases

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

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

37 37 Intel P TB/$2450

38 38 Samsung SM TB/$1500

39 39 Samsung 850 PRO 2TB/$850

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

41 IO vs Memory 41

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

43 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) 43

44 Endurance Might be a top consideration 44

45 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 45

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

47 Storage Engines Innodb TokuDB 47

48 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 48

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

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

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

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

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

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

55 Logs on RAID can be fast 55

56 Single Intel 730 Sysbench 56

57 IOPS 57

58 58 Consistency

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

60 Other Thoughts Host hardware and OS matter, especially with high end flash Virtualization has higher relative overhead Network higher relative overhead 60

61 Thank you!