Evolving SQL Server for Modern Hardware Paul Larson, Eric N. Hanson, Mike Zwilling Microsoft plus to the many members of the Apollo and Hekaton teams Paul Larson, ICDE 20151

SQL Server 2014 Evolving the architecture of SQL Server Hardware changed drastically since 1980s Large cheap memory, plenty of cores, SSDs Deep architectural changes needed To fully exploit the changing hardware To adapt to different workloads Apollo: column-store optimized for DW Hekaton: in-memory, row-store optimized for OLTP Queries and transactions can cross all three engines 2 Common Front End: API, Catalog, Language, Management, Security, … Common Back End: Storage, Backup, High- Availability, Resource Management, … Apollo column-store engine Optimized for data warehousing Apollo column-store engine Optimized for data warehousing Classical row-store engine General Purpose Hekaton row-store engine Optimized for OLTP Paul Larson, ICDE 2015

Agenda Apollo column store engine Hekaton in-memory OLTP engine Looking ahead Paul Larson, ICDE 20153

Why add columnar storage? 1.Column stores beat the pants off row stores on analytical queries 2.Increased importance of analytical workloads Analytical queries scan lots of rows but access only a few columns Row stores excel at OLTP-type workloads Short requests accessing a few rows Lots of overheads for scanning lots of rows Indexes and materialized views help But they are expensive to store and maintain Column stores excel at analytical queries Fast scans, reduced storage, reduced IO, less memory wasted But updates tend to be slow, small lookups are expensive Paul Larson, ICDE 20154

What’s in Apollo? Column store indexes An index that stores data column-wise (instead of row-wise) Can be used as a primary index (base storage) or as a secondary index Compressed to save space Optimized for scans Batch mode (vectorized) operators Process batches of rows (~1000) instead of one row at time Scan operator with filtering and aggregation on compressed data Operators for select, hash join, hash aggregation, union all Paul Larson, ICDE 20155

Index creation and storage Paul Larson, ICDE Also have a global dictionary per column (not shown)

Column store compression Paul Larson, ICDE Encoding – convert to integers Value-based encoding (linear transformation Dictionary encoding 2.Row reordering Find optimal permutation of rows (best compression) Proprietary algorithm 3.Compression Run length encoding (value + number of consecutive repeats) Bit packing (use min number of bits) 4.Optional on-disk archival compression (Lempel-Ziv)

Observed compression ratios Paul Larson, ICDE Database Name Raw data size (GB) Compression ratio Archival compression?GZIP NoYes EDW Sim Telco SQM MS Sales Hospitality

Supporting updates Paul Larson, ICDE Delete bitmap B-tree on disk Bitmap in memory Delta stores Up to 1M rows/delta store May have several Tuple mover Converts delta store to row group Automatically or on demand

Record performance on TPC-H Date published CS indexes used? Sockets/cores/ threads QphHPrice/QphH 4/15/13No8/80/160158,108$6.49 4/16/14Yes4/60/120 25% fewer cores 404, X faster $ % cheaper 4/06/15Yes8/120/240 50% more cores 652, X faster $ % cheaper Paul Larson, ICDE TPC-H, 10,000GB scale

Customer Experiences Bwin.Party Time to prepare 50 reports reduced by 92% Best reduction: 17 min to 3 sec, 340X faster Clalit Health 48 out of 50 problem queries ran faster Average speedup 400X Average wait time reduced from 20 min to 3 sec DevCon Security Reports went from sec to 1 sec, >10X Ad hoc queries went from 5-7 min to 1-2 sec, > 100X Paul Larson, ICDE

Agenda Apollo column store engine Hekaton in-memory OLTP engine Looking ahead Paul Larson, ICDE

Hekaton: what and why Hekaton is a high performance, memory-optimized OLTP engine architected for modern HW trends and integrated into SQL Server Market need for ever higher throughput and lower latency OLTP at lower cost HW trends demanded architectural changes Large main memories, lots of cores, SSDs Data doesn’t live on disk anymore! 13Paul Larson, ICDE 2015

SQL Server Integration Same manageability, administration & development experience Integrated queries & transactions Integrated HA and backup/restore Main-Memory Optimized Direct pointers to rows Indexes exist only in memory No buffer pool No write-ahead logging Stream-based storage Non-Blocking Execution Lock-free data structures Multi-version optimistic concurrency control with full ACID support No locks, latches or spinlocks No I/O during transaction T-SQL Compiled to Native Machine Code T-SQL compiled to machine code leveraging VC compiler Procedure and its queries, becomes a C function Aggressive compile-time Hekaton Architectural Pillars Architectural Pillars Results Hybrid engine but integrated experience Speed of an in- memory cache with capabilities of a database Transactions execute to completion without blocking Queries & business logic run at native- code speed Principle s Performance-critical data fits in memory Conflicts are Rare Push decisions to compilation time Built-In Paul Larson, ICDE

Record and index structure 90,150SusanBeijing 50, ∞ JanePrague 100, 200 JohnParis70, 90SusanBrussels 200, ∞ JohnBeijing TimestampsNameChain ptrsCity Range index on City Hash index on Name J S Rows are multi-versioned Each row version has a valid time range indicated by two timestamps A version is visible if transaction read time falls within version’s valid time A table can have multiple indexes Row format BW- tree Paul Larson, ICDE

Transaction validation (for update transactions) Read stability Check that each version read is still visible as of the end of the transaction Phantom avoidance Repeat each scan checking whether new versions have become visible since the transaction began Extent of validation depends on isolation level Snapshot isolation: no validation required Repeatable read: read stability Serializable:read stability, phantom avoidance Details in “High-Performance concurrency control mechanisms for main-memory databases”, VLDB 2011 Paul Larson, ICDE

Non-blocking execution Goal: enable highly concurrent execution no thread switching, waiting, or spinning during execution of a transaction Lead to three design choices Use only latch-free data structure Multi-version optimistic concurrency control Allow certain speculative reads (with commit dependencies) Result: Read-only transactions run without blocking or waiting Update transactions block only on final log write Exception: speculative reads may force a transaction to wait before returning a result (rare) Paul Larson, ICDE

Durability and availability Logging changes before transaction commit All new versions, keys of old versions in a single IO Aborted transactions write nothing to the log Checkpoint - maintained by rolling log forward Organized for fast, parallel recovery Require only sequential IO Recovery – rebuild in-memory database from checkpoint and log Scan checkpoint files (in parallel), insert records, and update indexes Apply tail of the log High availability (HA) – based on replicas and automatic failover Integrated with AlwaysOn (SQL Server’s HA solution) Up to 8 synch and asynch replicas Paul Larson, ICDE

Hekaton Engine Performance (micro- benchmark) Transaction size in #lookups/#updates Speedup over classical engine LookupsUpdates X20.2X X23.4X X31.4X 1, X27.9X 10, X30.5X Paul Larson, ICDE

Scalability under extreme contention (1000 row table) 20 80% R=10 20% R=10, W=2 5× Single version, locking Multiversion, optimistic Paul Larson, ICDE 2015

Performance does make a difference! Bwin.party – large online gaming site ASP.NET session state repository Went from 15,000 requests/sec to 250,000 requests/sec, 17X Achieved 450,000 requests/sec in testing, 30X Replaced 18 servers by one server Edgenet – provides real-time price/availability data for retailers 8X-11X faster data ingestion enabled huge service improvements Moved from once-a-day batch ingestion to continuous data ingestion Consolidated multiple servers into a single database server Removed application caching layer Samsung Electro-Mechanics – statistical process control system Improved OLTP performance by 24X and DW performance by 22X Now able to ingest and analyze all sensor data from manufacturing lines Improved quality control, better products 21Paul Larson, ICDE 2015

SQL Server viewed as technical leader Gartner Magic Quadrant for Operational Database Systems (formerly OLTP) Microsoft 22Paul Larson, ICDE 2015

Agenda Apollo column store engine Hekaton in-memory OLTP engine Looking ahead Paul Larson, ICDE

In the not-so-distant future Support for real-time analytics Column store indexes on Hekaton tables Making secondary CS indexes updatable Column store enhancements B-tree indexes on primary CS Even faster scans Paul Larson, ICDE

Thank you for your attention Paul Larson, ICDE