Flash Storage 101 Revolutionizing Databases Matt Henderson Consulting Engineer

Inside the Server 10-40% utilization Many threads Many cores Many time slices 10-40% utilization Why is the CPU not at 100%? -> Resource constrained

SQL Server Process Management One SQL scheduler per logical core SQL scheduler time-slices between users

Queues Running Waiting Runnable Currently executing process Waiting for a resource (IO, network, locks, latches, etc) Runnable Resource ready, waiting to get on CPU

Storage Latency Latency issues multiplied by the number of cores in the system

Over 50 IO in the same amount of time Visualizing Latency Block of data requested HDD Storage 8ms latency 8ms Block of data returned Time I/O Bound Apps Oracle DB2 SQL Server Etc… Total latency = seek time + rotational latency Flash Storage 0.15ms (150 microsecond) latency Over 50 IO in the same amount of time Time

Legacy Architecture Aggregation & Segregation Model Cost Inefficient Many autonomous parts Separate RAID groups Data locality Hot spots Transient data / usage Tiering software / admin Cost Inefficient Each workload bottlenecked by a different subset of components Flash != Flash SSDs are a modernization – disk substitution Distributed block all-flash is a revolution One 64k inbound write is split into 16 separate 4k packets Each 4k packet has parity calculated creating a total of 5k of data to store The 5k final packet is split into five 1k packet and one is sent to each of the five VIMMS in a RAID group

Distributed Block Flash VIMM – custom built flash storage cards and controllers Packets striped across VIMM’s flash wafers at the bit level Each VIMM chip splits a 1k packet to the bit level and stores them all in parallel to the many flash chip layers comprising each nand chip 12 RAID groups 5 VIMMS each

Massive Parallelism Batches split into 4k blocks All blocks split over VIMMS VIMMS parallelize to the bit Memory-like addressing 12 RAID groups 5 VIMM cards per group One 64k inbound write is split into 16 separate 4k packets Each 4k packet has parity calculated creating a total of 5k of data to store The 5k final packet is split into five 1k packet and one is sent to each of the five VIMMS in a RAID group

Distributed Block Flash for Databases Simplicity Less to design, plan. Easy to scale. No performance variance Faster, Quicker, More. Speed and Scale Reduced admin time No LUN/stripe mapping Chasing down / resolving performance issues Chores and tasks run faster ETL’s Backup/Restores – reduced RTO No index rebuilding for logical fragmentation Reduced admin costs / issues No costly tiering/locality management software No quarterly new-spindle purchases Turn asynch mirroring into synch mirroring Less hardware to do the same work (context switches) Drop from Enterprise to Standard edition SQL Server

Modern = Simplicity Traditional Architecture Aggregation & Segregation Violin Memory Storage Distributed Block

NTFS Tuning – Need several LUNs

SQL Tuning – IDENTITY Column & Clustered Indexes As PK = OK As Clustered index = NOT OK Huddles data onto one data page Bottlenecks on inserts Removes locks/latches as source of bottleneck

SQL Tuning – In and Outs Out In Any number of files, partitions Many files for speed / data placement Many partitions for speed / data placement Index defragging to re-order data MAXDOP <= 4 Admin in serial mode (one at a time) Table loads (ETL) Index maintenance Backups Archiving Admin only during off hours Segregated workloads In Any number of files, partitions MAXDOP = number of cores in server Admin in parallel Admin during business processing Mixed workloads (many servers & DB’s on same storage device)