Blazing Fast Application Performance Using In-Memory OLTP...
Transcript of 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)
Memory Optimized Tables and Indexes
50, ∞ Pinal BLR
Timestamps NameChain ptrs City
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
Memory Optimized Tables and Indexes
50, ∞ Pinal BLR
Timestamps NameChain ptrs City
Hash index
on CityHash index
on Name
T150: DELETE (Vinod, Chennai)
100, ∞ Balu BLR
Memory Optimized Tables and Indexes
90, 150 Vinod Chennai
50, ∞ Pinal BLR
Timestamps NameChain ptrs City
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)
Memory Optimized Tables and Indexes
90, 150 Vinod Chennai
50, ∞ Pinal BLR
Timestamps NameChain ptrs City
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