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 Bufferpool 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-20X performance gain for OLTP integrated into SQL Server In-Memory DW 5-25X performance gain and high data compression Updatable and clustered SSD Bufferpool Extension 4-10X of RAM and up to 3X performance gain transparently for apps Applicable to Transactional workloads: Concurrent data entry, processing and retrieval Applicable to Decision support workloads: Large scans and aggregates Applicable to Disk-based transactional workloads: Large working (data)set

6

Meanwhile RAM cost continues to drop Moore’s Law on total CPU processing power holds but in parallel processing… CPU clock rate stalled… Because processors would melt… New CPU won’t run a short transaction much faster

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 Architectural Pillars Results 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 Principl es Performance- critical data fits in memory Conflicts are Rare Push decisions to compilation time Built-In

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 option T1T1 T3T3 T2T2 T1T1 T3T3 T2T2 T1T1 T3T3 T2T2 T1T1 T3T3 T2T2 Table s Indexe s T-SQL Interpreter T1T1 T3T3 T2T2 T1T1 T3T3 T2T2 Access Methods Parser, Catalog, Optimizer Hekaton Compiler Hekaton Componen t Key Existing SQL Componen t Generated.dll 20-40x more efficient Real Apps see 2-30x Reduced log contention; Low latency still critical for performance Few improvements in comm layers

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.

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 INDEX [ICustomerID-Since] NONCLUSTERED (CustomerID, CustomerSince) ) WITH (MEMORY_OPTIMIZED = ON, DURABILITY = SCHEMA_AND_DATA); This table is memory optimized This table is durable. Non-durable tables: DURABILITY=SCHEMA_ONLY Indexes may be specified inline NONCLUSTERED indexes are supported Hash Index BUCKET_COUNT Use 2x # of unique index key values Multi-Column indexes are supported

CREATE PROCEDURE 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

One of the hardest parts of a high-performance in-memory system Performance goals require in-memory format to diverge from storage format Storage format must be very efficient for checkpoint and recovery Contention on the transaction log grows High-availability remains very critical

CustomerWorkloadResults Edgenet – SaaS provider for retailers and product delivery for end consumers Provide real-time insight into product price/availability for retailers and end- consumers. Used by retailers in-stores and to end- consumers via search engines. 8x-11x in performance gains for ingestion of data Consolidated from multi-tenant, multi- server to single database/server. Removed application caching layer (additional latency) from client tier. Case Study Case Study BWin.party - Largest regulated online gaming site Running ASP.NET session state using SQL Server for repository Critical to end-user performance and interaction with the site Increase 15,000 batch requests/sec per to over 250,000 in case study Lab testing achieved over 450,000 batch requests/sec Consolidate 18 SQL Servers -> 1. Case Study Case Study SBI Liquidity Market - Japanese foreign currency exchange trading platform. Includes high volume and low latency trading. Expecting 10x volume increase 2x throughput (get over 3x in testing) with goal to reduce latency from 4 seconds to 1 per business transaction. Case study

Despite 20 years of optimizing for 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

Apply to In-Memory BI (PowerPivot, PowerView) In-Memory DW (columnstore) In-Memory OLTP Apply to In-Memory BI (PowerPivot, PowerView) In-Memory DW (columnstore) In-Memory OLTP

CustomerApp Pattern SQL Common Labs Event ReportingShock Absorber BWIN - Session StateRelational Cache SaxobankRead Scale Baltika BreweriesOLTP EdgenetRead Scale DerivcoRelational Cache SBI LiquidityOLTP Plenty Of FishRead Scale CareGroupShock Absorber

Typical scenarios Data is typically written once and read many times Queries are against large amounts of data Aggregating, filtering are common Star & snowflake schemas are common using dimension and fact tables New data is typically appended to fact tables

… C1 C2 C3 C5C4 25 Benefits: Improved compression: Data from same domain compress better Reduced I/O: Fetch only columns needed Improved Performance: More data fits in memory Data stored as rows Columnstore internals Data stored as columns

OrderDateKeyProductKeyStoreKeyRegionKeyQuantitySalesAmount ColumnStore Index Example

OrderDateKeyProductKeyStoreKeyRegionKeyQuantitySalesAmount OrderDateKeyProductKeyStoreKeyRegionKeyQuantitySalesAmount Horizontally Partition (create Row Groups) ~1M rows

OrderDateKey ProductKey StoreKey RegionKey Quantity SalesAmount OrderDateKey ProductKey StoreKey RegionKey Quantity SalesAmount Vertically Partition (create Segments)

OrderDateKey ProductKey StoreKey RegionKey Quantity SalesAmount OrderDateKey ProductKey StoreKey RegionKey Quantity SalesAmount Compress Each Segment

OrderDateKey ProductKey StoreKey RegionKey Quantity SalesAmount OrderDateKey ProductKey StoreKey RegionKey Quantity SalesAmount Read The Data Column Elimination Segment Elimination

Table consists of column store and row store DML (update, delete, insert) operations leverage delta store INSERT Values Always lands into delta store DELETE Logical operation Data physically remove after REBUILD operation is performed. UPDATE DELETE followed by INSERT. BULK INSERT if batch < 100k, inserts go into delta store, otherwise columnstore SELECT Unifies data from Column and Row stores - internal UNION operation. “Tuple mover” converts data into columnar format once segment is full (1M of rows) REORGANIZE statement forces tuple mover to start. C1 C2 C3 C5C6C4 Column Store C1 C2 C3 C5C6C4 Delta (row) store tuple mover

In-Memory OLTP Overview Motivating trends – hardware, software, apps In-memory OLTP architecture & integration into SQL Server Performance and customer results In-Memory Data Warehousing Overview Buffer Pool Extension Overview

Use of cheaper SSD to reduce SQL memory pressure No risk of data loss – only clean pages are involved Observed up to 3x performance improvement for OLTP workloads during the internal testing Sweet spot machine size: Up to 32GB RAM High throughput and endurance SSD storage (ideally PCI-E) sized 4x-10x times of RAM size Not optimized for DW workloads * Not applicable to In-memory OLTP * DW workload data set is so large that table scan will wash out all the cached pages.

SQL Server RDBMS Column-Store Engine for DW Disk-optimized, row-store engine Memory- optimized OLTP engine AlwaysOn, Backup/Restore, Security, Admin, Deployment Transactions, Queries, Stored Procedures Batch Query Operators Native- Compiled Procedures Blobs Readable Secondaries Range + Column secondary indexes Nearly seamless across all engines Work across all engines but with limitations Work across two engines with limitations Available only in one engine Not comprehensive - only representative examples.