blazing fast application performance using in-memory oltp...

Blazing Fast Application Performance Using In-Memory OLTP on Windows Azure VMs

Balmukund, Support Escalation Engineer

Agenda

• What is IaaS?

• Overview of In-Memory OLTP

• Combining IaaS and In-Memory OLTP

• Demo

Ready?

Test # 1

Answer # 1

Ready?

Test # 2

FINISHED FILES ARE THE RESULT OF YEARS OF SCIENTIFIC STUDY COMBINED WITHTHE EXPERIENCE OF YEARS…

FINISHED FILES ARE THE RESULT OF YEARS OF SCIENTIFIC STUDY COMBINED WITHTHE EXPERIENCE OF YEARS…

Answer # 2

Ready?

Test # 3

You cnat bielveetaht u cuold raedtihs sneetcne

Solution for Slow Response?

Lord RAM

RAM RUM?

Hekaton

Computer RAM?

More CPU?

Super Heroes

Memory-optimized, but durable

Very high performance OLTP engine

Fully integrated into SQL Server

Memory-optimized, but durable

Very high performance OLTP engine

Fully integratedinto SQL Server

Architected for modern CPUs

Myths About In-Memory OLTP

• SQL Server In-Memory OLTP is a recent response to competitors’ offerings

• In-Memory OLTP is like DBCC PINTABLE

• In-Memory Databases are new separate products

• You can use In-Memory OLTP in an existing SQL Server app with NO changes whatsoever

• Since tables are in memory, the data is not Durable or Highly Available – I will lose it after server crash

Hekaton or In-Memory OLTP?

Memory-optimized Table

Filegroup Data Filegroup

SQLServr.exeHekaton Engine: Memory_optimized

Tables & Indexes

TDS Handler and Session Management

Native-

Compiled SPs

and Schema

Buffer Pool

Execution Plan cache for

ad-hoc T-SQL and SPs

Application

Transaction Log

Query

Interop

Non-durable

Table option T1 T3T2

T1 T3T2

T1 T3T2

T1 T3T2

Tables

Indexes

T-SQL Interpreter

T1 T3T2

T1 T3T2

Access Methods

Parser,

Catalog,

Optimizer

Hekaton

Compiler

Hekaton

Component

Key ==> Existing SQL

Component

Generated

.dll

20-40x more efficientReal Apps see 2-30x

Reduced log contention; Low

latency still critical for performance

Few improvements in comm layers

Interpretation of query plans

Page

#

Buffer FrameLatch

Q1 checks

for page 7

Frame

allocated

& latched

I/O Initiated

Q1 blocked

I/O

completes

Latch

released

Q1 & Q2

continue

25 ms.

Q2 checks

for page 7

TimeQ2

blocked by

latch

7

Buffer

Pool

Q1: A = A + 100 DB actions: Read A, A=A+100, Write A

Q1

Read A

A=A+100

Q1

Write A

A = 1100

Q2

Read A

A=A+500

Q2

Write A

A = 1600A = 1000

Time

A = 1000

TimeQ1

Read AQ2

Read A

A=A+100

Q1

Write A

A = 1100

A=A+500

Q2

Write A

A = 1500

Schedule 1 is a serial schedule: Q1 followed by Q2

Schedule 2 is not equivalent to any serialschedule.

Final value of A does not reflect Q1’s update!

Q2: A = A + 500 DB actions: Read A, A=A+500, Write A

A = 1000Time

Q1 Set

X (eXclusive)

Lock on A

Q2

Read A

A=A+100A = 1100

A=A+500

Q2

Write A

A = 1600

Q1

Read A

Q2

Attempts

to Set X

Lock on A

Q2

Blocked

Q1

Write A

Q1

Release

Lock on A

Q2

Unblocked

HOW TO USE IN-MEMORY OLTP?

CREATE TABLE RecentSales (

ItemID int32 not null

PRIMARY KEY NONCLUSTERED HASH,

Name varchar not null,Price decimal not null

) with ( MEMORY_OPTIMIZED = ON,

DURABILITY = SCHEMA_AND_DATA)

Via standard ad-hoc T-SQL query interface

(termed “interop”) –Up to 3X perf boost

Adapt, recompile, & execute T-SQL stored procedures –

5X to 30X perf boost(Caveat: some language restrictions

for V1)

Slow Fa

st

Slow Fa

st

Read Thread

Throughput

Read

Threads

Read

Threads

Read Thread

Throughput

Latch

Lock-free

Latch

Latch

Lock-free

Slow Fa

st

Slow Fa

st

Read Thread

Throughput

Read

Threads

Read

Threads

Read Thread

Throughput

Latch

Latch

Slow Fa

st

Slow Fa

st

Read

Threads

Read

Threads

Update Thread

Read Thread

Throughput

Lock-free

Read Thread

Throughput

Latch

In-Memory OLTP Architectural Pillars

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

• Multi-version

optimistic

concurrency control,

full ACID support

• Lock-free data

structures

• No locks, latches or

spinlocks,

• No I/O in 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 optimizations

Arc

hitect

ura

l Pill

ars

Resu

lts

Hybrid engine and

integrated experience

In-memory cache

speed with capabilities

of a database

Transactions execute to

completion without

blocking

Queries & business

logic run at native-code

speed

Princi

ple

s

Performance-critical

data fits in memoryConflicts are Rare

Push decisions to

compilation timeBuilt-In

Memory Optimized Tables and Indexes

50, ∞ Pinal BLR

Timestamps NameChain ptrs City

Hash index

on CityHash index

on Name

90, ∞ Vinod Chennai

f(Pinal)

f(Vinod)

f(BLR)

f(Chennai)


50, ∞ Pinal BLR


Hash index

on CityHash index

on Name

T100: INSERT (Balu, BLR)

100, ∞ Balu BLR

90, ∞ Vinod Chennai

f(Balu) f(BLR)

90, 150 Vinod Chennai


50, ∞ Pinal BLR


Hash index

on CityHash index

on Name

T150: DELETE (Vinod, Chennai)

100, ∞ Balu BLR



50, ∞ Pinal BLR


Hash index

on CityHash index

on Name

T200: UPDATE

(Balu, BLR) to

(Balu, Chennai)

100, ∞ Balu BLR

200, ∞ Balu Chennai

100, 200

f(Chennai)

f(Balu)



50, ∞ Pinal BLR


Hash index

on CityHash index

on Name

T250: Garbage collection

100, 200 Balu BLR

200, ∞ Balu Chennai

f(Balu)

f(Pinal)

f(Chennnai)

f(BLR)

Suitable Application Characteristics

• 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 migration simplified if– Stored procedures used

– Performance problems isolated to subset of tables and SPs

Special Thanks

• David Dewitt

• Microsoft Jim Gray Systems Lab

Cristian Diaconu

Craig Freedman

Mike Zwilling

Hideaki Kimura

Rimma

Nehme

Contributors

blazing fast application performance using in-memory oltp...

Documents