SQL Server 2014 Mission Critical Performance with SQL Server 2014 Jump Start

Meet Kevin Liu

• Principal Lead Program Manager

• Kevin Liu has been with Microsoft and the SQL Server engine team for 7 years, working on key projects like AlwaysOn and has been leading program management for the In-Memory OLTP project since its transition into the product team from incubation.

• Prior to Microsoft, Kevin worked in enterprise software consulting (Accenture and etc) and holds a Ph.D on computational neural networks.

Kevin Liu| Principal Lead Program Manager Kevin.Liu@Microsoft.com

SQL Server 2014 In-Memory OLTP Overview

SQL Server 2014 Investments

In-Memory Technologies

Enhanced High Availability

New Hybrid Scenarios

In-Memory OLTP• 5-20X performance gain for

OLTP integrated into SQL Server

In-Memory DW• 5-25X performance gain and

high data compression • Updatable and clustered

SSD Bufferpool Extension• 4-10X of RAM and up to 3X

performance gain transparently for apps

Always On Enhancements • Increased availability and

improved manageability of active secondaries

Online Database Operations• Increased availability for

index/partition maintenance

Backup to Azure• Easy to implement and cost

effective Disaster Recovery solution to Azure Storage

HA to Azure VM• Easy to implement and cost

effective high availability solution with Windows Azure VM

Deploy to Azure• Deployment wizard to migrate

database

Better together with Windows Server• WS2012 ReFS support• Online resizing VHDx• Hyper-V replica• Windows “Blue” support

Extending Power View• Enable Power View on

existing analytic models and support new multi-dimensional models.

Other investments

In-memory Technologies

In-Memory Technologies

In-Memory OLTP• 5-20X performance gain for

OLTP integrated into SQL Server

In-Memory DW• 5-25X performance gain and

high data compression • Updatable and clustered

SSD Bufferpool Extension• 4-10X of RAM and up to 3X

performance gain transparently for apps

Applicable to

Transactional workloads: Concurrent data entry, processing and retrieval

Applicable to

Decision support workloads: Large scans and aggregates

Applicable to

Disk-based transactional workloads:Large working (data)set

MICROSOFT CONFIDENT IAL – INTERNAL ONLY

Why In-memory OLTP (Hekaton)

Market need for ever higher throughput and predictable lower latency OLTP at a lower cost

HW trend demands architectural changes on RDBMS to meet those demands

In-memory OLTP is: High performance,Memory-optimized OLTP engine, Integrated into SQL Server and Architected for modern hardware trends

6

1990

1991

1992

1992

1993

1994

1994

1995

1996

1996

1997

1998

1998

1999

2000

2000

2001

2002

2003

2004

2005

2007

2008

2009

2010

2011

1

10

100

1000

10000

100000

1000000

$ per GB of PC Class Memory

US$

/GB

Decreasing RAM cost

Moore’s Law on total CPU processing power holds but

in parallel processing…

CPU clock rate stalled…

Hardware trends

SQL Server Integration

• Same manageability, administration & development experience

• Integrated queries & transactions

• Integrated HA and backup/restore

Main-Memory Optimized

• Optimized for in-memory data

• Indexes (hash and range) exist only in memory

• No buffer pool, B-trees

• Stream-based storage

High Concurrency

• Multi-version optimistic concurrency control with full ACID support

• Core engine uses lock-free algorithms

• No lock manager, latches or spinlocks

T-SQL Compiled to Machine Code• T-SQL compiled to

machine code via C code generator and VC

• Invoking a procedure is just a DLL entry-point

• Aggressive optimizations @ compile-time

Steadily declining memory price,

NVRAM

Many-core processors

Stalling CPU clock rate

TCO

Hardware trends Business

In-memory OLTP Architecture Pillars

8

Hybrid engine and integrated

experience

High performance

data operations

Frictionless scale-up

Efficient, business-logic

processingCu

sto

mer

Ben

efi

ts

Hekato

n T

ech

P

illa

rsD

rivers

9

Demo 1

Memory-optimized Table Filegroup Data Filegroup

SQL Server.exe

In-memory OLTP Engine: Memory_optimized Tables &

Indexes

TDS Handler and Session Management

In-memory OLTP Integration and Application Migration

10

Natively Compiled SPs and Schema

Buffer Pool for Tables & Indexes

Proc/Plan cache for ad-hoc T-SQL and SPs

Client App

Transaction Log

Query Interop

Non-durable Table T1 T4T3T2

T1 T4T3T2

T1 T4T3T2

T1 T4T3T2

Tables

Indexes

Interpreter for TSQL, query plans, expressions

T1 T4T3T2

T1 T4T3T2

Checkpoint & Recovery

Access Methods

Parser, Catalog, Algebrize

r, Optimize

r

In-Memory OLTP

CompilerIn-Memory

OLTP Component

Key

Existing SQL Component

Generated .dll

Memory-optimized Table

FilegroupData Filegroup

SQL Server.exe

In-Memory OLTP Engine for

Memory_optimized Tables & Indexes

TDS Handler and Session Management

Performance Gains

Natively Compiled SPs and Schema

Buffer Pool for Tables & Indexes

Proc/Plan cache for ad-hoc T-SQL and

SPs

Client App

Transaction Log

Query Interop

Interpreter for TSQL, query plans, expressions

Access Methods

Parser, Catalog, Algebrize

r, Optimize

r

Hekaton

Compiler

10-30x more efficient

Reduced log bandwidth & contention. Log latency

remains

Checkpoints are background sequential IO

No improvements in communication stack,

parameter passing, result set generation Hekaton

Component

KeyExisting

SQL Compone

nt

Generated .dll

SQL Server row-store and column-store scenarios• Row-store for OLTP: mainly for operational transaction with minimum reporting and

shorter period of time

• Column-store for DW: mainly for reporting of transaction history over a longer period of time

Considerations IM Row store IM Updatable ColumnstoreData size and currency

Data size Designed to address bottlenecks in hot data (For V1,  < 256GB)   

Designed for cold and archival data (>256G)

Read patterns

Point select and ad hoc query for operational report

Ideal – key design points for non-blocking high performance data access

Not ideal – minimum scan set is 1M row + delta row store

Large scan set with aggregates

Not ideal Ideal – key design points

Star schema and related DW type of complex joins

Not ideal Ideal – key design points

Write patterns

Heavy updates and deletes

Ideal – key design points for contention free data operations

Functional but not optimized – change happens to on-disk row store and gets merged into column store in batches

Heavy ETL and data ingestion

Ideal – key design points Functional but not optimized – same as above

Relational cache scenario

Ideal (with NDT) Not ideal

13

Demo 2

• Microsoft Virtual Academy– Free online learning tailored for IT Pros and Developers – Over 1M registered users– Up-to-date, relevant training on variety of Microsoft

products

• “Earn while you learn!” – Get 50 MVA Points for this event!– Visit http://aka.ms/MVA-Voucher – Enter this code: PerfSQL (expires 1/3/2014)

Join the MVA Community!

©2013 Microsoft Corporation. All rights reserved. Microsoft, Windows, Office, Azure, System Center, Dynamics and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.