SQL Server 2014 実践シリーズ （HTML 版）
「No.1 インメモリ OLTP 機能の実践的な利用方法」

1.5　インメモリ OLTP はシングル実行でも性能向上を期待可能

インメモリ OLTP 機能は、多数のユーザーによる同時実行時だけでなく、シングル実行（1ユーザーによる単体実行）でも性能向上を期待できます。これについて、次のアーキテクチャをベースに説明します（図は、TechEd North America 2014 のセッションより引用）。

図の水色と緑の部分が、インメモリ OLTP のコンポーネントです（名称にある「Hekaton」は、インメモリ OLTP の開発コード名です）。「SQL Server.exe」メモリ空間内に Hekaton Engine: Memory-optimized Table＆Indexes（インメモリ OLTP のエンジンと、メモリ最適化されたテーブルとインデックス）が常駐され、緑の部分の Native Compiled SP（ネイティブ コンパイル ストアド プロシージャ）は、ストアド プロシージャを事前コンパイルして DLL 化することができる機能です。

図では、この Hekaton Engine と Native Compiled SP の部分で、20-40x more efficient（20～40倍効率化）されて、Real Apps see 2-30x（リアル アプリケーションでは 2～30倍の効率化）と記載されています。

また、Non durable Table option は、データを永続化（durable）しないオプションで、SCHEMA_ONLY オプションとも呼ばれ、メモリ内にのみテーブルとインデックスを配置します。このオプションでは、トランザクション ログへの書き込みを行わず、図の左下にある Memory-optimized Table Filegroup（インメモリ OLTP 用のファイル グループ）も利用しません（正確には、データを保存せずに、スキーマのみを保存するので、SCHEMA_ONLY と呼ばれています）。

これに対して、データを永続化するオプションがあり、これは SCHEMA_AND_DATA と呼ばれています。このオプションの場合は、トランザクション ログへの書き込みや、Memory-optimized Table Filegroup への書き込みを行って、データを永続化します（永続化することで、電源断などがあったとしても、コミット済みのデータを復旧させることができます）。トランザクション ログへの書き込みは、従来ながらのディスク ベースのテーブルよりも効率化されていますが、これについては後述します。

◆ どの部分で性能が向上するのか？ ～接続、実行、ログ書き込み～

インメモリ OLTP 機能を利用することで、どの部分で性能が向上するのか、次の図で説明します。

この図も、TechEd North America 2014 のセッションから引用したものですが、左側が Traditional execution stack（従来ながらのディスク ベースの実行スタック）、右側がインメモリ OLTP の実行スタック、真ん中の Perfomance gain が性能向上に関してです。

上から、Client Connectivity（クライアント接続）に関しては、No Improvement（向上なし）で、アプリケーションからの接続と切断（ADO.NET の場合は SqlConnection の Open と Close）に関しては、ディスク ベースでもインメモリでも性能は変わりません。

性能が大きく変わるのは、Query Execution（クエリ実行）と Data Access（Buffer Pool）の部分で、2-10x improvement（2～10倍の性能向上）となっています。インメモリ OLTP では、ネイティブ コンパイル ストアド プロシージャを作成／利用することで、クエリ実行部分が Procedure Execution（事前コンパイルした DLL によるプロシージャ実行）に代わって、データ アクセスに関しては、メモリ最適化（Memory-Optimized）されることで、このような性能向上を期待できます。

トランザクション ログへの書き込みは、Same Latency（遅延時間は同じ）とありますが、これはデータを永続化（SCHEMA_AND_DATA オプションを利用）した場合です。データを永続化する場合には、ディスク ベースと同様、トランザクション ログへの書き込みが発生します。

ディスク ベースとの大きな違いは、インメモリ OLTP の方が Less volume（ログへの書き込み量が少ない）という部分です。インメモリ OLTP では、インデックスに関する情報はログへは書き込まないので、その分ログへの書き込み量を減らすことができます。インメモリ OLTP でのインデックスは、メモリ内にのみ配置し、永続化をしないからです（電源断などがあって、復旧が必要な場合には、インデックスは再作成されます）。

また、SQL Server 2014 からは、Delayed Durability（遅延書き込み）というオプションが提供されて、ログへの書き込みを非同期で行えるようになったので、これでログへの書き込みの性能向上を図ることもできます。このオプションを利用しない場合は、トランザクションのコミット時にログへの書き込みを行って、書き込みが完了したことがコミットとなり、データの損失は発生しません。一方、Delayed Durability オプションを利用した場合は、ログへの書き込みが完了するのを待たないで、コミットとすることができます（ログへの書き込みは遅延で行います）。したがって、コミットしたにも関わらず、データの損失の可能性があり、コミット直後に電源断などが発生した場合にはデータの損失が起こり得ます（データ損失のリスクと性能向上のトレード オフがあります）。後述の Edgenet 社では、このオプションを利用することで性能向上を実現しています。

トランザクション ログへの書き込みは、データを永続化しない SCHEMA_ONLY オプションであれば、書き込みを行わないので、その分大きく性能を向上させることができます（電源断などが発生した場合には、完全にデータが損失してしまうので、それとのトレード オフになります）。後述の bwin 社では、このオプションを利用することで、16.7倍もの性能向上を実現しています（最新のテストでは 30倍もの性能向上も確認しています）。インメモリ OLTP 機能の性能メリットを最大限に活かすことができるのがこのオプションです。

◆ ネイティブ コンパイル ストアド プロシージャによる性能向上

ネイティブ コンパイル ストアド プロシージャは、詳しくは第2章以降で説明しますが、通常の SQL ステートメントのようなインタプリタ形式（その都度コンパイルする形式）ではなく、事前にコンパイル済みの DLL を作成しておくことができる機能です。ネイティブ コンパイル ストアド プロシージャを作成する一番のメリットは、性能向上を期待できることです。

弊社のお客様では、次のような効果を確認しています。

アプリケーションを一切修正することなく、インメモリ OLTP 化しただけで 1.8倍の性能向上、ネイティブ コンパイル ストアド プロシージャ（グラフ内は Native SP と表記）を作成して、これを利用するようにアプリケーションを修正することで 2.8倍もの性能向上を確認することができました。このように、大きな性能向上を期待できるのが、ネイティブ コンパイル ストアド プロシージャです。

このグラフは、100多重で実行した場合の負荷テストの結果ですが、シングル実行した場合の性能差は、次の表のようになっています。

詳しくは後述しますが、ネイティブ コンパイル ストアド プロシージャを作成／利用することで、全体として 1.74倍の性能向上を確認することができました（12個のステートメントで 1.3ミリ秒かかっていた処理を、750マイクロ秒に短縮できました）。

◆ ネイティブ コンパイル ストアド プロシージャの作成概要

ネイティブ コンパイル ストアド プロシージャは、通常のストアド プロシージャと同様、CREATE PROC ステートメントを利用して、簡単に作成することができます。次のように、WITH 句で「NATIVE_COMPILATION」オプションを付けることで、ネイティブ コンパイル ストアド プロシージャとして作成することができます。

BEGIN ATOMIC で囲んで、スナップショット分離レベル（ISOLATION LEVEL = SNAPSHOT）を指定している以外は、見慣れた Transact-SQL ステートメントだと思います。このネイティブ コンパイル ストアド プロシージャは、ポイントカード システムで実際に利用したもので、「カードID」列が PRIMARY KEY の「カード マスター」テーブルから 1件分のデータを取得するためのものです。これを作成／利用することで、約1.8倍の性能向上を確認しています（インメモリ OLTP 化する前は、.NET アプリケーションから ADO.NET を利用して、直接 SELECT ステートメントを実行していました）。

このように、インメモリ OLTP 機能では、ネイティブ コンパイル ストアド プロシージャを作成することで、シングル実行でも性能向上を期待することができます。