SQL Server 2014: In In-memory OLTP for Database Developers

In-Memory Technologies Enhanced High Availability New Hybrid Scenarios In-Memory OLTP 5-25X performance gain for OLTP integrated into SQL Server In-Memory DW 5-25X performance gain and high data compression Updatable and clustered SSD Buffer Pool 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 OLTP 5-25X performance gain for OLTP integrated into SQL Server In-Memory DW 5-30X performance gain and high data compression Updatable and clustered SSD Buffer Pool Extension 4-10X of RAM and up to 3X performance gain transparently for apps

Market need for higher throughput and predictable lower latency OLTP at a lower cost Hardware trends demand architectural changes on RDBMS In-Memory OLTP is:  High performance,  Memory-optimized OLTP engine,  Integrated into SQL Server and  Architected for modern hardware trends

Decreasing RAM cost Moore’s Law on total CPU processing power holds but in parallel processing… CPU clock rate stalled…

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 High Concurrency Multi-version optimistic concurrency control with full ACID support Lock-free data structures No locks, latches or spinlocks No I/O during transaction T-SQL Compiled to Machine Code T-SQL compiled to machine code leveraging VC compiler Procedure and its queries, becomes a C function Aggressive compile-time Steadily declining memory price, NVRAM Many-core processors Stalling CPU clock rateTCO Hardware trends Business Hybrid engine and integrated experience High performance data operations Frictionless scale-up Efficient, business- logic processing Customer Benefits Hekaton Tech Pillars Drivers

Demo Business and User impact

Memory-optimized Table Filegroup Data Filegroup SQL Server.exe Hekaton 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 T1 T3 T2 T1 T3 T2 T1 T3 T2 T1 T3 T2 Table s Indexe s T-SQL Interpreter T1 T3 T2 T1 T3 T2 Access Methods Parser, Catalog, Optimizer Hekaton Compiler Hekaton Component Key Existing SQL Componen t Generated.dll 20-40x more efficient Reduced log contention; Low latency still critical for performance Checkpoints are background sequential IO No V1 improvements in comm layers

Despite 20 years of optimizing for existing OLTP benchmarks – we still get 2x on a workload derived from TPC-C Apps that take full advantage: e.g. web app session state Apps with periodic bulk updates & heavy random reads Existing apps typically see 4-7x improvement

CREATE TABLE [Customer]( [CustomerID] INT NOT NULL PRIMARY KEY NONCLUSTERED HASH WITH (BUCKET_COUNT = ), [Name] NVARCHAR(250) NOT NULL, [CustomerSince] DATETIME NULL INDEX [ICustomerSince] NONCLUSTERED ) WITH (MEMORY_OPTIMIZED = ON, DURABILITY = SCHEMA_AND_DATA); This table is memory optimized This table is durable Non-durable tables: DURABILITY=SCHEMA_ONLY Indexes are specified inline NONCLUSTERED indexes are supported Hash Index BUCKET_COUNT 1-2X nr of unique index key values

Demo Table and Stored Procedure Performance Gain

Row headerPayload (table columns) Begin Ts End Ts StmtId IdxLinkCount 8 bytes 4 bytes (padding) bytes 8 bytes * (IdxLinkCount)

50, ∞ JohnParis TimestampsNameChain ptrsCity Hash index on Name Transaction 100: UPDATE City = ‘Prague’ where Name = ‘John’ No locks of any kind, no interference with transaction , ∞ JohnPrague 90, ∞ Susan Bogota f(John) 100 Transaction 99: Running compiled query SELECT City WHERE Name = ‘John’ Simple hash lookup returns direct pointer to ‘John’ row Background operation will unlink and deallocate the old ‘John’ row after transaction 99 completes. Hekaton Principle: Performance like a cache Functionality like a RDMBS

PAGE Page Mapping Table PAGE , ∞ 1 50, Root Non-leaf pages leaf pages Data rows PageID-0 PageID-3 PageID-2 PageID -14  Page size- up to 8K. Sized to the row  Logical pointers  Indirect physical pointers through Page Mapping table  Page Mapping table grows (doubles) as table grows  Sibling pages linked one direction  Require two indexes for ASC/DSC  No in-place updates on index pages  Handled thru delta pages or building new pages  No covering columns (only the key is stored) Key Logical Physical 100,200 1

CREATE PROCEDURE DATETIME WITH NATIVE_COMPILATION, SCHEMABINDING, EXECUTE AS OWNER AS BEGIN ATOMIC WITH (TRANSACTION ISOLATION LEVEL = SNAPSHOT, LANGUAGE = N'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

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 Accessing Memory Optimized Tables Interpreted T-SQL Access Access both memory- and disk- based tables Less performant Virtually full T-SQL surface When to use Ad hoc queries Reporting-style queries Surface area not available in native

Buffer Pool Memory Optimized Tables Available Memory Buffer Pool Memory Optimized Tables Buffer Pool Memory Optimized Tables Buffer Pool Memory Optimized Tables

Demo Memory Usage and Control

Data File Delta File 0100 TS (ins)RowId TableId TS (ins)RowIdTableId TS (ins)RowIdTableId TS (ins)RowIdTS (del) TS (ins)RowIdTS (del) TS (ins)RowIdTS (del) Checkpoint File Pair Row pay load Transaction Timestamp Range Data file contains rows inserted within a given transaction range Delta file contains deleted rows within a given transaction range

Populating Data/Delta files via sequential IO only Offline Checkpoint Thread Memory-optimized Table Filegroup Range Range Range Range Range 500- New Inserts Delete 450 TS Delete 250 TS Delete 150 TS Data file with rows generated in timestamp range IDs of Deleted Rows (height indicates % deleted) Del Tran2 (TS 450) Del Tran3 (TS 250) Del Tran1(TS150 ) Insert into Hekaton T1 Log in disk Table Del Tran1 (row TS150) Del Tran2 (row TS 450) Del Tran3 (row TS 250) Insert into T1 SQL Transaction log (from LogPool) Data file has pre- allocated size (128 MB or 16 MB on smaller systems) Engine switches to new data file when the current file is full Transaction does not span data files Once a data file is closed, it becomes read- only Row deletes are tracked in delta file Files are append only

Memory-optimized data Filegroup Range Range Range Range Memory-optimized data Filegroup Files as of Time 600 Range Range Range Range Data file with rows generated in timestamp range IDs of Deleted Rows (height indicates % deleted) Merge Deleted Files Files Under Merge Files as of Time 500 Range Range Range Range

Delta map Recovery Data Loader Delta File1 Memory Optimized Tables Recovery Data Loader Delta map Data File1 Delta File2 Data File2 Delta File3 Data File3 filter Memory Optimized Container - 1Memory Optimized Container - 2

Optimal for V1Not Optimal for V1 Business logicIn database (as SPs)In mid-tier Latency and contention locations Concentrated on a sub-set of tables/SPs Spread across the database Client server communicationLess frequentChatty T-SQL surface areaBasicComplex Log IONot limiting factorLimiting factor Data sizeHot data fit in memoryUnbounded hot data size

Demo Analysis and Migration tools

TimeTransaction T1 (SNAPSHOT)Transaction T2 (SNAPSHOT) 1BEGIN 2 3UPDATE t SET c1=‘value2’ WHERE c2=123 4UPDATE t SET c1=‘value1’ WHERE c2=123 (write conflict) First writer wins

Disk-based tablesMemory-optimized tables Tab1TabnTab1Tabm Regular Tx contextMem-opt Tx context

Disk-basedMemory optimizedUsage recommendations READCOMMITTEDSNAPSHOT Baseline combination – most cases that use READCOMMITTED today READCOMMITTEDREPEATABLEREAD/ SERIALIZABLE Data migration Hekaton-only Interop REPEATABLEREAD/ SERIALIZABLE SNAPSHOT Memory-optimized table access is INSERT-only Useful for data migration and if no concurrent writes on memory-optimized tables (e.g., ETL) Disk-basedMemory optimized SNAPSHOT Any isolation level REPEATABLEREAD/ SERIALIZABLE REPEATABLEREAD/ SERIALIZABLE Supported isolation level combinations (V1) Unsupported isolation level combinations (V1)