SQL Server 2014 In Memory OLTP Overview

B24:SQL Server

SQL Server 2014
In Memory OLTP Overview
Microsoft MVP for SQL Server
Masayuki Ozawa

はじめに

本資料は SQL Server 2014 CTP2 をベースに作成しています。
そのため、製品版では動作が変わる可能性があります。
あらかじめご了承ください。

2

db tech showcase 東京 2013

自己紹介


フリーランスエンジニアとして SQL Server の案件を中心
に従事しています




案件等で協力できることがありましたらお声掛けいただけると幸いです

Microsoft MVP for SQL Server (July 2011 - June 2014)


コミュニティやブログで SQL Server の情報を発信


コミュニティ活動
 SQL

Server : SQLTO (http://sqlto.net)
 Azure : JAZUG (http://r.jazug.jp/)
 ブログ : SE の雑記 (http://engineermemo.wordpress.com)

3


In Memory OLTP

4


いきなりですが

DEMO

5


システム要件


CPU




メモリ




プロセッサで cmpxchg16b をサポートしている必要がある
推奨される最大サイズは 256 GB まで

Edition


Enterprise Edition x64







32 ビットのエディションではサポートしていない
SQL Server 2014 の各エディションがサポートする機能
http://msdn.microsoft.com/ja-jp/library/cc645993(v=sql.120).aspx

AlwaysOn 可用性グループと組み合わせることも可能

メモリ最適化テーブルを使用するための要件

http://msdn.microsoft.com/ja-jp/library/dn170449(v=sql.120).aspx

6


テーブルの種類


ディスクベーステーブル (Disk Based Table)







従来からのテーブル
使用するデータのみディスクからメモリ上に格納
メモリが不足した場合はメモリからデータをキャッシュアウトし領域を確保
データはディスクに書き込まれ永続化される

メモリ最適化テーブル (Memory Optimized Table)





7

Code Name “Hekaton” (→ Hecto : 100 倍) と呼ばれていた機能
全てのデータをメモリ上に格納
メモリが不足した場合のデータのキャッシュアウトはない
永続化 / 非永続化の 2 種類を選択可能

メモリのサイズが不足すると


メモリが不足するとデータ操作ができなくなる




デフォルトでは max server memory の 80% まで利用される

リソースガバナーを使用することで最大メモリを調整できる


以下は上限を 50% にするための設定






8

CREATE RESOURCE POOL Pool_Hekaton WITH (MAX_MEMORY_PERCENT = 50);
EXEC sp_xtp_bind_db_resource_pool 'TESTDB', 'Pool_Hekaton‘
EXEC sp_xtp_unbind_db_resource_pool 'TESTDB‘

How to: Bind a Database with Memory Optimized Tables to a Resource Pool

基本構成

9


ファイル構成
データベース
ディスクベース
テーブル用
ファイルグループ
(mdf/ndf)

メモリ最適化
テーブル用
ファイルグループ
(Checkpoint File)

トランザクションログ
(ldf)
10


基本的な構成要素


データ




データの実体はメモリ上に格納される

トランザクションログ


ディスクベーステーブルと同様のログファイルを使用






論理ログレコードとして処理し、コミット時にファイルにログを書き込み
ログの書き込み負荷は通常のテーブルより小さい

メモリ最適化テーブル用ファイルグループ



データを永続化するために使用 (チェックポイントファイル)
データの実体ではなく、データの永続化をするために使用


データファイル : 追加されたデータを格納 (INSERT ONLY)





デルタファイル : 削除された行の管理情報を格納






11

ページサイズ = 256 KB
1 ファイル : 128MB / 最大 4,096 = 512GB
4 KB 書き込み
ファイルサイズは固定されていない

データファイルとデルタファイルはペアになっている

ストリームベースのシーケンシャル I/O により処理を実施

同時実行制御

12


ロック / ラッチフリーモデル


READCOMMITTED ではなくSNAPSHOT がデフォルト


In Memory OLTP 向けのスナップショット分離モデルを採用


SNAPSHOT / REPEATABLE READ / SERIALIZABLE が利用可能





REPEATABLE READ / SERIALIZABLE はネイティブコンパイルストアドプロシージャで利用
メモリ最適化テーブルでのトランザクション

同時更新の制御は楽観的同時実行制御


先に更新されたほうが優先



13

Check & Update (CMPXCHG : Compare and Exchange) という CPU 命令を使用
これを実現するために cmpxchg16b のサポートが必要となる


楽観的同時実行制御


レコード変更の競合は楽観的同時実行制御で管理される


先に更新された内容が優先され、後から更新されたものはエラーとなる



更新 / 削除の競合



追加の競合

14


エラーのタイミング
INSERT

UPDATE
Session A

Session B

Session A

Session B

BEGIN TRAN

BEGIN TRAN

BEGIN TRAN

BEGIN TRAN

UPDATE SET
WITH (SNAPSHOT)

UPDATE SET
WITH (SNAPSHOT)

COMMIT TRAN

Error
41302
3998

INSERT INTO
INSERT INTO
COMMIT TRAN

COMMIT TRAN

15

COMMIT TRAN


Error
41325

In Memory OLTP の同時実行制御

DEMO

16


利用するための流れ

17


メモリ最適化テーブルを使用する手順


設定を有効→自動的にメモリ最適化テーブルとはならない。
利用するための手順を踏む必要がある

メモリ最適化テーブル用のファイルグループを作成

メモリ最適化テーブルを作成

(ネイティブコンパイルストアドプロシージャの作成)
18


ファイルグループの作成
ALTER DATABASE [Hekaton]
ADD FILEGROUP [HekatonFG]
CONTAINS MEMORY_OPTIMIZED_DATA

ALTER DATABASE [Hekaton]
ADD FILE ( NAME = N'Hekatn_FS', FILENAME =
N'F:¥Hekaton_FS¥Hekatn_FS' ) TO FILEGROUP
[HekatonFG]

19


メモリ最適化テーブルの作成


DURABILITY (データの永続化) は 2 種類





SCHEMA_AND_DATA (スキーマとデータを永続化)
SCHEMA_ONLY (スキーマのみを永続化)

インデックスは 2 種類



ポイント参照用のハッシュインデックス (NONCLUSTERED HASH)
範囲検索用の非クラスター化インデックス (NONCLUSTERED)

CREATE TABLE dbo.MemoryTable
(
c1 int NOT NULL,
c2 int NOT NULL INDEX NCIX_MemTable_c2 NONCLUSTERED(c2),
c3 uniqueidentifier,
CONSTRAINT PK_MemoryTable_c1 PRIMARY KEY NONCLUSTERED HASH (c1) WITH (BUCKET_COUNT = 100000),
) WITH (MEMORY_OPTIMIZED = ON, DURABILITY = SCHEMA_AND_DATA)
GO

20


テーブルの制限 1/2


使用できるデータ型に制限がある


BLOB (nvarchar(max) / varbinary(max)) はサポートされていない





サポートされるデータ型

IDENTITY / UNIQUE 制約 / CHECK 制約 / FOREIGN KEY 制約は非サポート






列の最大サイズは 8,060 バイト

IDENTITY の代わりにシーケンスを使用する
PRIMARY KEY による一意制約は設定できる (SCHEMA_AND_DATA では必須)
サポートされていない Transact-SQL の構造

文字列データの制約



インデックスを設定する文字列型 ((n)char / (n) varchar) は BIN2 照合順序を利用
非 Unicode 文字列 (char / varchar) は CP1252 (Latin1_General 等) を利用


21

SELECT * FROM fn_helpcollations() WHERE COLLATIONPROPERTY(name,'codepage') = 1252


テーブルの制限 2/2


統計情報の自動更新は無効




統計情報のメンテナンスは手動で行う必要がある

テーブル作成後の定義の変更は不可








22

列の追加 / データ型の変更
バケットカウントのサイズ変更
インデックスの定義変更 / 追加
テーブルの定義を変更したい場合は、一度データを退避しテーブルを再作成し
てデータを再ロードする
SQL Server によるインメモリ OLTP のサポート
Transact-SQL によるインメモリ OLTP のサポート

ハッシュインデックス


特定の行を検索 (Seek) するのに向いている



範囲検索には不向き


23

Table Scan / Index Scan (全件操作) になる可能性が高い


ハッシュインデックのバケットカウント


ハッシュインデックスを格納するためにメモリ上に存在する領域 (バケツ)



1 バケット = 8 バイト
2 の累乗に自動的に切り上げられる






1,000 と設定した場合は 1,024 に切り上げられる
sys.hash_indexes で実際に設定された値を確認できる

設定した値は格納したデータ件数に関わらず固定でメモリが確保される


ハッシュインデックスのサイズ = バケットカウント × ポインターサイズ

インデックスキー項目

24

ハッシュ


バケットカウント

レンジインデックス


Bw-Tree 構造を使用したインデックス


ロック/ラッチフリーのツリー構造



特定の範囲を検索するのに向いている



インデックスのソート順であればソートコストはかからないが逆順で
取得した場合はソートコストがかかる

インデックスのソートの逆順

インデックスのソート順

25


インデックスの種類によるメモリ使用量の違い



SELECT * FROM sys.dm_db_xtp_table_memory_stats
WHERE object_id = OBJECT_ID(N'MemoryTable')
50 万件のデータ挿入前後のメモリ使用量 (上 : データ有 / 下 : データ無)





非クラスター化インデックス

26


データの永続化

27


データの永続化
メモリ

データの
変更

メモリ最適化
テーブル

コミット時にリカバリに
必要となるログのみ
ログファイルに書き込み
(WAL ではない)
SCHEMA_ONLY の場合は
最小限のログを書き込み

ディスク
ログファイル

データファイル

デルタファイル
sys.fn_dblog / sys.fn_dblog_xtp

28

バックグラウンドの
チェックポイントにより
シーケンシャル Write
データファイル / デルタファイルにより
データを永続化


ログの書き込みをタイミングを考慮すると…


SET NOCOUNT ON
GO
DECLARE @i bigint = 1)
WHILE (@i <= 100000)
BEGIN
INSERT INTO HekatonTable VALUES(@i, ‘AAAAA’)
SET @i += 1
END



SET NOCOUNT ON
GO
BEGIN TRAN
WHILE (@i <= 100000)
BEGIN
INSERT INTO HekatonTable VALUES(@i, ‘AAAAA’)
SET @i += 1
END
COMMIT TRAN
29


チェックポイントファイルの構造
Max 128MB/file
256KB Page Size

Timestamp (INSERT)
Timestamp (INSERT)
Timestamp (INSERT)
Timestamp (INSERT)

Table ID
Table ID
Table ID
Table ID

デルタファイル
Write 4KB Page

Timestamp (INSERT)
Timestamp (INSERT)
Timestamp (INSERT)
Timestamp (INSERT)

Timestamp (DELETE)
Timestamp (DELETE)
Timestamp (DELETE)
Timestamp (DELETE)

チェックポイント
ファイルペア

Row ID
Row ID
Row ID
Row ID

Row Payload
Row Payload
Row Payload
Row Payload

Row ID
Row ID
Row ID
Row ID

sys.dm_db_xtp_checkpoint_files

複数のチェックポイントファイルはマージされることでファイルの最適化が行われる
通常は自動で実行されるが、手動で実行する場合は、sp_xtp_merge_checkpoint_files でファイルをマージ
30


サービス起動時の処理


永続化しているメモリ最適化テーブルはサービスの起動時にチェック
ポイントファイルの内容をメモリにロードする


メモリにロードが終わるまではデータベースは復旧中になる
メモリ
メモリ最適化テーブル

31

デルタマップ
(デルタファイルの内容)

デルタマップ
(デルタファイルの内容)


削除レコードを
フィルタしてロード



データの永続化とログ書き込み

32


メモリ上のデータの構造

33


レコードの構成


レコードの格納単位は行ベース




行ヘッダーとペイロード (行データ) で構成されている

行ヘッダーにタイムスタンプを保持し、レコードの有効期限を管理



最新のデータはエンドのタイムスタンプが ∞ (infinity)
ステートメント ID は自トランザクションで変更したデータを識別するためのもの




同一のトランザクションではステートメント ID が同じになる

インデックスポインターは連続したデータのチェーンの次の行を示すポインター

行ヘッダー

開始 TS

8 バイト
34

ペイロード

終了 TS

8 バイト

ステートメントインデックス
リンクカウント
ID
4 バイト

2 バイト


インデックスポインター

8 バイト × インデックス数

データ変更処理の実装


削除 (DELETE)





追加 (INSERT)




レコードの終了のタイムスタンプを設定
削除されたレコードのメモリはガベージコレクタ (GC) によって回収
新規のレコードを追加

変更 (UPDATE)


35

DELETE & INSERT により変更後のデータを作成


テーブルの構造

開始 TS

200

インデックス
ポインター

終了 TS

300

ペイロード

Yamada

Y
300

∞

100

36

Yamada

∞


null

Yamashita

メモリサイズ


メモリサイズの考え方


データで使用するメモリサイズ




ハッシュインデックスで使用するメモリサイズ






(バケットカウント × 8) × インデックス数 (固定サイズ)

全件更新をした場合には瞬間で更新前 / 更新後のデータ分メモリが利
用される




行ヘッダ + (インデックスポインターサイズ × インデックス数) + データサイズ

GC により削除データのメモリは回収されるが、動作までは削除データのメモ
リは確保されている

メモリの使用状況は sys.dm_db_xtp_table_memory_stats で確認可能
メモリ最適化テーブルに移行する際のメモリ要件の推定

37


Native Compile

38


ネイティブコンパイル


従来からの T-SQL でもメモリ最適化テーブルにアクセスすることが可能だが、
最高のパフォーマンスを出すためにはネイティブコンパイルされたストアド
プロシージャを利用する



ネイティブコンパイルされるオブジェクトは以下の 2 種類


メモリ最適化テーブル






MEMORY_OPTIMIZED = ON のテーブル

SQL Server によるインメモリ OLTP のサポート
Transact-SQL によるインメモリ OLTP のサポート

ネイティブコンパイルされたストアドプロシージャ



39

WITH NATIVE_COMPILATION を有効にしたストアドプロシージャ
ネイティブでコンパイルされたストアドプロシージャの概要
http://technet.microsoft.com/ja-jp/library/dn133184(v=sql.120).aspx


ネイティブコンパイルストアドプロシージャ
CREATE PROCEDURE dbo.usp_NativeSP_Persist
@param1 int = 0
WITH NATIVE_COMPILATION, SCHEMABINDING, EXECUTE AS OWNER
AS BEGIN ATOMIC WITH
(
TRANSACTION ISOLATION LEVEL = SNAPSHOT, LANGUAGE = N'Japanese‘
-- 言語は sys.syslanguages から取得可能
)
DECLARE @i int = 1
WHILE (@i <= @param1)
BEGIN
INSERT INTO dbo.PersistTable VALUES(@i, RAND() * 1000, N‘dbts2013東京', N‘dbts2013)
SET @i += 1
END
END
GO
40


ネイティブコンパイルストアドの制限


メモリ最適化テーブルへのアクセスに制限される


ディスクベーステーブルへのアクセスはできない









BEGIN TRAN / COMMIT TRAN / ROLLBACK TRAN は使用できない

文字列の比較、並べ替えは BIN2 照合順序が必要




使用できる関数やデータ型の変換に制限がある

ストアドプロシージャ内のトランザクションは BEGIN ATOMIC で担保




メモリ最適化テーブルと通常のテーブルの JOIN といったことはできない
メモリ最適化テーブル間は JOIN できるが OUTER JOIN はサポートされていない

char / varchar を使用する場合は合わせて CP1252 が必要

サポートされていない Transact-SQL の構造
ネイティブでコンパイルされたストアドプロシージャの概要
http://technet.microsoft.com/ja-jp/library/dn133184(v=sql.120).aspx

41


コンパイルされたファイル


xtp ディレクトリにコンパイルされた DLL が格納される




DLL は SQL Server にモジュールとしてロードされる

各モジュールのロードタイミングは以下のようになる


メモリ最適化テーブルのロード




ネイティブコンパイルされたストアドプロシージャーのロード



42

テーブルの作成 / データベースをオンラインにする際にコンパイル

ストアドプロシージャの作成 / 初回実行時にコンパイル
最新の統計情報を使用してコンパイルをしたい場合にはデータを挿入後に、統計情
報を更新し、その後にネイティブコンパイルされたストアドプロシージャを作成


In Memory OLTP のモジュールロード

43


参考資料 1/2


SQL Server 2014 自習書シリーズ
http://www.microsoft.com/ja-jp/sqlserver/2014/technology/self-learning.aspx



Books Online




Blog







インメモリ OLTP (インメモリ最適化)

In-Memory OLTP: High Availability for Databases with Memory-Optimized Tables
http://blogs.technet.com/b/dataplatforminsider/archive/2013/11/05/in-memory-oltp-high-availability-for-databases-with-memory-optimized-tables.aspx
The 411 on the Microsoft SQL Server 2014 In-Memory OLTP Blog Series
http://blogs.technet.com/b/dataplatforminsider/archive/2013/10/15/the-411-on-the-microsoft-sql-server-2014-in-memory-oltp-blog-series.aspx
SQL Server 2014 In-Memory Technologies: Blog Series Introduction
http://blogs.technet.com/b/dataplatforminsider/archive/2013/06/26/sql-server-2014-in-memory-technologies-blog-series-introduction.aspx
Getting Started with SQL Server 2014 In-Memory OLTP
http://blogs.technet.com/b/dataplatforminsider/archive/2013/06/26/getting-started-with-sql-server-2014-in-memory-oltp.aspx

Tech Ed




44

Microsoft SQL Server In-Memory OLTP: Overview of Project "Hekaton“
http://channel9.msdn.com/Events/TechEd/NorthAmerica/2013/DBI-B204
Microsoft SQL Server In-Memory OLTP Project "Hekaton": App Dev Deep Dive
Microsoft SQL Server In-Memory OLTP Project “Hekaton”: Management Deep Dive


参考資料 2/2


Sample Database




Case Study








SQL Server 2014 CTP2 In-Memory OLTP Sample, based
https://msftdbprodsamples.codeplex.com/releases/view/114491

bwin.party
http://www.microsoft.com/casestudies/Microsoft-SQL-Server-2014/bwin.party/Gaming-Site-Can-Scale-to-250-000-Requests-Per-Secondand-Improve-Player-Experience/710000003117
TPP
http://www.microsoft.com/casestudies/Microsoft-SQL-Server-2014/TPP/Clinical-Software-Easily-Supports-Thousands-of-New-Users-andHelps-Doctors-Save-Lives/710000003430
SBI Liquidity Market
http://www.microsoft.com/casestudies/Microsoft-SQL-Server-2014/SBI-Liquidity-Market/Leading-Japanese-Financial-Firm-AcceleratesTrading-Platform-with-In-Memory-OLTP/710000003429

White Paper



45

Main-Memory Databases
http://research.microsoft.com/en-us/projects/main-memory_dbs/
SQL Server In-Memory OLTP Internals Overview for CTP2
http://download.microsoft.com/download/5/F/8/5F8D223F-E08B-41CC-8CE5-95B79908A872/SQL_Server_2014_InMemory_OLTP_TDM_White_Paper.pdf


SQL Server 2014 In Memory OLTP Overview

More Related Content

What's hot

Similar to SQL Server 2014 In Memory OLTP Overview

More from Masayuki Ozawa

SQL Server 2014 In Memory OLTP Overview