1. Flash Storage 101 Revolutionizing Databases
Matt Henderson
Consulting Engineer

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

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

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

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

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

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

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

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

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

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

12. NTFS Tuning – Need several LUNs

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

14. 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)