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
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
06.03.2014In-Memory OLTP (Hekaton)4
2013 © Trivadis
In-Memory OLTP gains
Disk-based tables
Page
Latch
Memory-optimized tables
06.03.2014In-Memory OLTP (Hekaton)5
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
In-Memory OLTP (Hekaton)06.03.2014
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
06.03.2014In-Memory OLTP (Hekaton)8
2013 © Trivadis
Memory Optimized Table Creation
CREATE TABLE DDL
Code generation and compilation
Table DLL produced
Table DLL loaded
In-Memory OLTP (Hekaton)06.03.2014
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
In-Memory OLTP (Hekaton)06.03.2014
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
In-Memory OLTP (Hekaton)06.03.2014
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
In-Memory OLTP (Hekaton)06.03.2014
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
In-Memory OLTP (Hekaton)06.03.2014
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
06.03.2014In-Memory OLTP (Hekaton)16
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
06.03.2014In-Memory OLTP (Hekaton)17
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
06.03.2014In-Memory OLTP (Hekaton)18
Limits
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
06.03.2014In-Memory OLTP (Hekaton)19
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
06.03.2014In-Memory OLTP (Hekaton)20
Top Related