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

1.7　INSERT 中心のシステムでも効果を発揮

インメモリ OLTP 機能は、INSERT が中心のシステムでも効果を発揮します。例えば、センサー系のデータを常に INSERT し続けるような状況や、大規模イベントでの「登録」や「予約」、「投票」のみを受け付けるようなシステムなどです。

インメモリ OLTP 機能では、次のような INSERT 性能を出すことができます。

この性能テストは、10個の列を持ったテーブルを作成して、そのテーブルへデータを 1件ずつ INSERT を行って、5,000万件分を INSERT したときの実行時間を測定したものです（データには、実際のアプリケーションを想定して、乱数を利用し、同じ値が格納されないようにしています）。

このテストは、Bulk Insert や SELECT INTO などの一括操作を利用したものではなく、またネイティブ コンパイル ストアド プロシージャの中でループ処理を記述して、複数件をまとめて INSERT するようなものでもなく、実際のアプリケーションを想定して、1件ずつの INSERT 処理を行った場合の実行時間を測定しています。ネイティブ コンパイル ストアド プロシージャ内の処理も、前述の図のように 1件の INSERT を行うものしか記述していません。接続に関しても、1件の INSERT ごとに Open と Close を行っています。

実行結果は、従来のディスク ベースと比較して、インメモリ OLTP では、100多重で 1.6倍の性能向上、400多重では 2倍の性能向上を確認することができました（この検証は、約15万円のデスクトップPC で行っているので、サーバー機であればさらに良い性能になります）。

ディスク ベースのテーブルでは、多重度が上がっていくと、性能が頭打ちになってしまう（多重度が上がるほど遅くなってしまう）ところが、インメモリ OLTP では、多重度が上がっても、性能低下があまり発生していません（∵ラッチ フリー、ロック フリーのアーキテクチャであるため）。

また、Delayed Durability（遅延書き込み）オプションを利用した場合は、400多重では 2.2倍の性能向上、SCHEMA_ONLY（データの永続化なし／ログ書き込みなし）オプションを利用した場合は、400多重では 2.5倍の性能向上を確認することができました。

このように、インメモリ OLTP 機能は、常に INSERT をし続けるようなシステムでも大きな効果を発揮します。センサー系のデータであれば、元々サンプリング（定期的な間隔）でデータを取得していたりするので、Delayed Durability オプションで遅延書き込みを行っても、多少のデータのロスが許さるので、性能向上を実現できる有効なオプションです。

また、データの永続化が必要ないのであれば、SCHEMA_ONLY オプションを利用することで、2.5倍の性能向上を実現できるので、一時的なデータ領域として利用するときに便利なオプションになります。

なお、このテストで利用したアプリケーションは、実際のアプリケーションを想定して、次のように .NET（VB＋ADO.NET）で作成しています（C#で作成してもほとんど同じコードになります）。

このコードは、ディスク ベースのテーブルへ INSERT を行う場合のものですが、インメモリ OLTP のネイティブ コンパイル ストアド プロシージャを利用する場合には、次のように 2ヶ所を修正しています。

SqlCommand の CommandType を変更して、CommandText をネイティブ コンパイル ストアド プロシージャの名前に変更するだけで、ネイティブ コンパイル ストアド プロシージャを実行することができます。

以上のコードを、多重実行（並行実行）して、実行時間を計測しています。

◆ ラッチ待ちの様子 ～インデックスの最終ページがホットスポット～

このテストで利用したテーブルは、col1 列を IDENTITY(1, 1) の PRIMARY KEY へ設定しているので、ディスク ベースのテーブルでは、多数のユーザーが同時にデータを追加することによって、次のようにインデックスの最終ページにアクセスが集中します（ディスク ベースのテーブルの場合は、PRIMARY KEY 制約を作成することで、自動的にクラスター化インデックスが作成されています）。

連番系の列（IDENTITY を設定した列や、シーケンスを設定した列）など、データを追加するたびに連続した値（1、2、3、…）が格納されていくような場合には、このようなインデックスの最終ページでページ ラッチ待ちが多発する（最終ページがホット スポットになる）ことがよくあります。これは、シングル実行（1人のユーザーによる単体実行）では、発生しないものですが、多数のユーザーが同時にデータを追加する場合には発生してしまいます。

実際に、400多重のときのラッチ待ちの様子をパフォーマンス カウンターで取得すると、次のようになります。

Batch Request（バッチ要求数）の数の 3倍近いラッチ待ち（Latch Waits）が発生してしまっています。

次に、40多重の場合のラッチ待ちの様子をパフォーマンス カウンターで確認すると、次のようになります。

40多重では、Batch Request の 1.7倍ぐらいのラッチ待ちが発生しています。これに対して、400多重では 3倍近いラッチ待ちが発生していたことからも、多重度が上がることで、ラッチ待ちが増えてしまうことを確認できると思います。

なお、このように、ラッチ待ちが多発している場合には、CPU 利用率（%Processor Time）が低い値になり、フル活用されていない状態になります（100％ 利用されていない状態）。

これに対して、インメモリ OLTP の Durable では、次のように CPU 利用率が推移しています。

インメモリ OLTP ではラッチ待ちが発生しない分、Batch Request が高い値で安定しています。また、CPU 利用率は 80％近辺を推移して、ディスク ベースのときよりも CPU を活用しています。100％ 近くまでフル活用していない理由としては、Durable ではログ書き込みがあること、ログの配置先が HDD（約１万円の 3TB HDD：Western Digital WD30EZRX、RAID なしのシングル構成）であること、多重度が上がりすぎていること（今回のテストで利用した 4コアの CPU に対しては 400多重では負荷が高すぎること）、1件の INSERT ごとに 接続の Open と Close を繰り返していることなどがあります。

したがって、今回の環境では、多重度を 100 に下げて、ログ書き込みをしない（SCHEMA_ONLY を利用）、接続をキープする（100個の接続を作った後に、その接続をキープする）ことで、CPU をフル活用に近い状態まで持っていくことができます（以下のグラフ）。

このように、接続をキープできるような状況であれば、CPU をさらに活用することができるので、ディスク ベースとインメモリ OLTP の性能差をさらに広げることができます（以下のグラフ）。