SQL Server パフォーマンスチューニング、コンサルティング、アドバイス、相談、定期診断、トレーニング

ホーム＞技術情報＞ SQL Server 2014 実践 No.1 インメモリ OLTP 機能の実践的な利用方法

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

松本美穂と松本崇博が執筆した SQL Server 2014 実践シリーズの「No.1 インメモリ OLTP 機能の実践的な利用方法」の HTML 版です。日本マイクロソフトさんの Web サイトで Word または PDF 形式でダウンロードできますが、今回、HTML 版として公開する許可をいただきましたので、ここに掲載いたします。[2015年12月29日]

目次へ | 前のページへ | 次のページへ

2.8　INSERT ステートメントの具体的な性能向上例

INSERT ステートメントは、「トランザクションテーブル」と「顧客利用履歴テーブル」への挿入があります。

00106

◆ INSERT ステートメントは 1.4～4.6倍の性能向上

INSERT ステートメントは、ネイティブコンパイル SP 化することで、27～78%の性能向上（1.4～4.6倍の性能向上）を実現できることが分かりました。

どちらのテーブルも、SCHEMA_AND_DATA（データの永続化有り）に設定していますが、顧客利用履歴テーブルへの INSERT は、若干のタイムラグ（遅延）が許される状況だったので、Delayed Durability（遅延書き込み／非同期書き込み）を採用しました。これによって、大きな性能向上（4.6倍もの性能向上）を実現することができ、Delayed Durability の強力さを確認することができました。

これに対して、トランザクションテーブルへの INSERT は、ログへの通常書き込みがある分、1.4倍の性能向上に留まりました。UPDATE ステートメントが 1.2～1.3倍の性能向上であったことを考えると、SCHEMA_AND_DATA の場合に、ネイティブコンパイル SP 化することによって、1.2～1.4倍程度の性能向上（シングル実行）が期待できるのでは、と考えることができそうです。

◆ トランザクションテーブルへの INSERT

トランザクションテーブルへの INSERT は、次のように行っています。

INSERT INTO トランザクションテーブル (col2, col3, col4, …（29列分の列名）)
VALUES(@p1, @p2, @p3, …（29列分のパラメーター） )

テーブルには、30個の列があり、IDENTITY(1,1) に設定された「Seq」列が PRIMARY KEYです。INSERT 時は、この列を除いた 29列へ値を指定して、挿入しています。この INSERT は、ネイティブコンパイル SP 化することで、1.4倍の性能向上を確認することができました。ネイティブコンパイル SP は、次のように作成しています。

CREATE PROC p_トランザクションテーブルへの挿入
@p1 データ型, @p2 データ型, @p2 データ型, …（29列分のパラメーター）
WITH
   NATIVE_COMPILATION, EXECUTE AS OWNER, SCHEMABINDING
AS
BEGIN ATOMIC
WITH ( TRANSACTION ISOLATION LEVEL = SNAPSHOT, LANGUAGE = N'japanese')
  INSERT INTO dbo.トランザクションテーブル(col2, col3, col4, …（29列分の列名）)
   VALUES(@p1, @p2, @p3, …（29列分のパラメーター） )
  SELECT SCOPE_IDENTITY() AS ID値
END

このように、単純なデータの INSERT でもネイティブコンパイル SP を作成するだけで、シングル実行で 1.4倍の性能向上を実現することができました。

◆ SCOPE_IDENTITY での ID の取得をネイティブコンパイル SP へ含める

今回、ネイティブコンパイル SP 化するにあたって、SCOPE_IDENTITY() をストアドプロシージャの中に含めるように修正しています（今まではアプリケーションから SCOPE_IDENTITY を実行）。これを行わないと、IDENTITY によって生成された ID 値を取得できないからなのですが、これは次のような状況です。

00107

この動作は、通常のストアドプロシージャでも同様ですが、INSERT の実行後に、アプリケーションから SCOPE_IDENTITY を利用している場合には、ストアドプロシージャ化することによって値が取れなくなってしまうので、SCOPE_IDENTITY はネイティブコンパイル SP の中に含めるように修正しなければなりません。

◆ 顧客利用履歴テーブルへの INSERT ～Delayed Durability～

顧客利用履歴テーブルへの INSERT は、次のようにネイティブコンパイル SP を作成しています。

CREATE PROC p_顧客利用履歴への挿入
@p1 データ型, @p2 データ型, @p2 データ型, …（23列分のパラメーター）
WITH
   NATIVE_COMPILATION, EXECUTE AS OWNER, SCHEMABINDING
AS
BEGIN ATOMIC
WITH ( DELAYED_DURABILITY = ON,
        TRANSACTION ISOLATION LEVEL = SNAPSHOT, LANGUAGE = N'japanese')
  INSERT INTO dbo.顧客利用履歴テーブル(col2, col3, col4, …（23列分の列名）)
   VALUES(@p1, @p2, @p3, …（23列分のパラメーター） )
  SELECT SCOPE_IDENTITY() AS ID値
END

顧客利用履歴テーブルには、24個の列があり、IDENTITY(1,1) に設定された「Seq」列が PRIMARY KEYです。INSERT時は、この列を除いた 23列へ値を指定して、挿入を行っています。この INSERT を、ネイティブコンパイル SP 化するときに、「DELAYED_DURABILITY = ON」を WITH 句で追加することによって、遅延書き込み（非同期でのログへの書き込み）を行えるになります。これによって、4.6倍もの性能向上を実現できています。

DELAYED_DURABILITY = ON を指定しない場合は、トランザクションのコミット時にログへの書き込みを行って、書き込みが完了したことがコミットと見なされて、データの損失は発生しませんが、DELAYED_DURABILITY = ON を指定した場合は、ログへの書き込みが完了するのを待たないで、コミットと見なします（ログへの書き込みは遅延で行います）。したがって、コミットしたにも関わらず、データの損失の可能性があります（コミット直後に電源断などが発生した場合にはデータの損失が起こり得ます）。その分、大幅な性能向上を実現できるというメリットを得られます。

顧客利用履歴テーブルは、ユーザーが直接参照するテーブルではなく、ユーザーの利用状況を分析するためのデータになるので、多少のデータ損失が許容できるものでした。そこで、Delayed Durability を採用して、性能向上のメリットを享受することができました。こうした多少のタイムラグが許されるテーブルは、意外と多いのではないでしょうか？

例えば、もともと一定の間隔（1分間隔など）でその瞬間のデータのみを保存する、といった処理の場合などです。これであれば、もともと間のデータを取得していないので、1分間隔であれば、最大１分分のデータは損失する可能性があるわけです。それを許容して（性能とのトレードオフで）システムの設計を行っているので、そういったテーブルでは、Delayed Durability を採用しても、もともとデータの損失の可能性があったものなので、何の問題もありません。

Delayed Durability は、大幅な性能向上を実現することができるので、利用できる場面がないかどうか、検討してみることを強くお勧めします。

目次へ | 前のページへ | 次のページへ