sql server 2014 -...

2013 © Trivadis

BASEL BERN BRUGG LAUSANNE ZUERICH DUESSELDORF FRANKFURT A.M. FREIBURG I.BR. HAMBURG MUNICH STUTTGART VIENNA

2013 © Trivadis

SQL Server 2014Highlights der wichtigsten Neuerungen – In-Memory OLTP (Hekaton)

Karl-Heinz Sütterlin

Meinrad Weiss

March 2014

06.03.2014In-Memory OLTP (Hekaton)1

2013 © Trivadis

06.03.2014In-Memory OLTP (Hekaton)

SQL Server 2014

In-Memory OLTP (Hekaton)

2

2013 © Trivadis

Driver for In Memory OLTP (HEKATON)

1

10

100

1000

10000

100000

1000000

10000000

1970 1975 1980 1985 1990 1995 2000 2005 2010 2015

Intel CPU trends and Memory prices($/GB)

Computing power holds Moore Law

(due to parallelism)

CPU clock frequency stalled

Memory has gotten a LOT cheaper

In-Memory OLTP (Hekaton)06.03.2014

3

2013 © Trivadis

In-Memory OLTP gains

20-30x improvement

Example 1

2 ms

Execution and data access

1 ms

2 ms

Connectivity

Logging

Total

5 ms

2 ms

0.03 ms

2 ms

4 ms

1X

30X

1X

20%

Example 2

0.5 ms

Execution and data access

10 ms

0.2 ms

Connectivity

Logging

Total

10.7 ms

0.5 ms

1ms

0.2 ms

1.7 ms

1X

10X

1X

600%

No improvement

Same latency

Less volume


2013 © Trivadis

In-Memory OLTP gains

Disk-based tables

Page

Latch

Memory-optimized tables


2013 © Trivadis

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

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, NVRAMMany-core processorsStalling CPU clock rate TCO

Hardware trends Business

Hekaton Architecture Pillars

Hybrid engine and

integrated experience

High performance data

operations

Efficient, business-logic

processing

Cust

om

er

Benefits

Heka

ton T

ech

Pill

ars

Dri

vers

High Concurrency

• Multi-version optimistic

concurrency control with full

ACID support

• Core engine uses lock-free

algorithms

• No lock manager, latches or

spinlocks

Frictionless scale-up


6

2013 © TrivadisMemory Optimized Table

Filegroup Data Filegroup

SQL Server.exeMemory Optimized Tables & Indexes

TDS Handler and Session Management

Hekaton Integration and Application Migration

Natively Compiled

SPs and Schema

Buffer Pool for Tables & Indexes

Client App

Transaction Log

Query

InteropT1 T3T2

T1 T3T2

Tables

Indexes

T-SQL Query Execution

T1 T3T2

Parser,

Catalog,

Optimizer

Hekaton

Compiler

Hekaton

Component

Existing SQL

Component

Generated

.dll

2013 © Trivadis

CREATE TABLE [Customer](

[CustomerID] INT NOT NULL

PRIMARY KEY NONCLUSTERED HASH WITH (BUCKET_COUNT = 1000000),

[Name] NVARCHAR(250) NOT NULL

INDEX [IName] HASH WITH (BUCKET_COUNT = 1000000),

[CustomerSince] DATETIME NULL

)

WITH (MEMORY_OPTIMIZED = ON, DURABILITY = SCHEMA_AND_DATA);

Create Table DDL

This table is

memory optimized

This table is durable

Secondary Indexes

are specified inline

Hash Index


2013 © Trivadis

Memory Optimized Table Creation

CREATE TABLE DDL

Code generation and compilation

Table DLL produced

Table DLL loaded


9

2013 © Trivadis

Memory Optimized Tables and Indexes

90,150 Susan Bogota

50, ∞ Jane Prague

100, 200 John Paris

200, ∞ John Beijing

Timestamps NameChain ptrs City

Hash index

on CityHash index

on Name

Garbage Collection

Removes Unused Rows


10

2013 © Trivadis

Limitations in Initial Release

Optimized for high-throughput OLTP

No DML triggers

No XML and no CLR data types

Optimized for in-memory

Rows are at most 8060 bytes

– no off row data

No Large Object (LOB) types like

varchar(max)

Scoping limitations

No FOREIGN KEY and no CHECK

constraints

No IDENTITY

No schema changes (ALTER TABLE)

– need to drop/recreate table

No add/remove index

– need to drop/recreate table


11

2013 © Trivadis

• Natively Compiled Procs

– Access only memory optimized

tables

– Maximum performance

– Limited T-SQL surface area

• When to use

– OLTP-style operations

– Optimize performance critical

business logic

Interpreted T-SQL Access (InterOP)

– Access both memory- and disk-

based tables

– Less performant

– Virtually full T-SQL surface

When to use

– Ad hoc queries

– Reporting-style queries

– Speeding up app migration

– Eliminating Latch Contention

Accessing Memory Optimized Tables


12

2013 © Trivadis

In-Memory OLTP (Hekaton)

Create Procedure DDL

CREATE PROCEDURE [dbo].[InsertOrder] @id INT, @date DATETIME

WITH

NATIVE_COMPILATION,

SCHEMABINDING,

EXECUTE AS OWNER

AS

BEGIN ATOMIC

WITH

(TRANSACTION

ISOLATION LEVEL = SNAPSHOT,

LANGUAGE = 'us_english')

-- insert T-SQL here

END

This proc is natively

compiled

Native procs must be

schema-bound

Atomic blocks

• Create a transaction

if there is none

• Otherwise, create a

savepoint

Execution context is

required

Session settings

are fixed at

create time

06.03.201413

2013 © Trivadis

Procedure Creation

CREATE PROC DDL

Query optimization

Code generation and compilation

Procedure DLL produced

Procedure DLL loaded


14

2013 © Trivadis

Application is suited for in-memory processing

All performance critical data already fits in memory

Transaction locking or physical latching causing stalls and blocking

Application is “OLTP-Like”

Relatively short-lived transactions

High degree of concurrent transactions from many connections

Examples: Stock trading, travel reservations, order processing

Application porting simplified if

Stored procedures used

Performance problems isolated to subset of tables and SPs

15

Suitable Application Characteristics

06.03.2014In-Memory OLTP (Hekaton)

2013 © Trivadis

Shock Absorber

Handles constant high volumes

Atypical spikes in workload

Usually latching bottleneck on input

Push to disk-based:

Hot and cold data

Memory footprint Only certain data fits into memory Desire compression on colder data

Workload pattern Mixed OLTP Reporting/BI query workloads Columnstore indexing

High data input or ”Shock Absorber”

Table1_MemoryOptimized

Data Loading

Table2_Diskbased

Optional data movement


2013 © Trivadis

Goal: Throughput

Bottlenecks: Typically IO (or latching)

Staging table containing transient data

SCHEMA_ONLY in many cases

Ability to replay data from source if data is lost

Reduce IO impact

Memory optimized-tables can be used

as temp tables

Staging tables and temp tables

Staging SCHEMA_ONLY

Table2_DataWarehouse

Data Loading - ETL

Native Compiled - Transformation


2013 © Trivadis

No foreign key or check constraints

No T-SQL function calls in compiled stored procedures

…

Transact-SQL Constructs Not Supported by In-Memory OLTP


Limits

http://msdn.microsoft.com/en-us/library/dn246937(v=sql.120).aspx

2013 © Trivadis

Where you lack the ability to change code

Hardware limitations

Non-OLTP workloads:

Full data warehouse

Long running reporting

Heavy parallel queries

XML/full text

Bottleneck cannot be addressed by migration (outside of In-memory OLTP engine)

Application patterns to avoid with In-Memory OLTP


2013 © Trivadis

Key takeaways

In-Memory OLTP engine

Provides a solution for applications with common RDBMS performance and scale bottlenecks

Meets demanding scale and performance goals with a relational database

Common design patterns

In-Memory OLTP

High-performance OLTP

High data input or ”Shock Absorber”

Relational cache

Read-scale

ETL target and staging/temp tables

To assess workload for In-Memory OLTP:

• Understand your bottleneck (AMR can help)

• Migrate only necessary pieces of your solution

• Execute testing at scale to understand the full benefits you may achieve

• Some applications may require a lot of work to achieve the gains, while others migrate quite easily

• Some applications may not be a good fit


sql server 2014 -...

Documents