SQL Server のことなら SQL Quality 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日]

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

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

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

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

00025

00026

00027

この性能テストは、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#で作成してもほとんど同じコードになります)。

00028

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

00029

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

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

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

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

00030

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

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

00031

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

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

00032

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

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

00033

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

00034

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

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

00035

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

00036

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

事例1

MPNロゴ


SQLQualityは執筆とセミナーを通じて技術の啓蒙やエンジニアの育成支援も行っています
最新刊
SQL Server 2012 の教科書
SQL Server 2012 の教科書(ソシム)

弊社オリジナル制作の
SQL Server 2012 自習書も
マイクロソフトのサイトで公開中!
ロングセラー
ASP.NET でいってみよう  SQL Server 2000 でいってみよう
ASP.NET でいってみよう
第7刷 16,500 部発行
SQL Server 2000 でいってみよう
第12刷 28,500 部発行


セミナー風景
セミナー風景

弊社執筆の
SQL Server 2012 自習書
マイクロソフトのサイトで公開中
全30冊
ダウンロードはこちら
弊社執筆の
SQL Server 2008 R2 自習書
マイクロソフトのサイトで公開中
全30冊
目次はこちら
松本美穂のコラム
(公開活動などのお知らせ)

第 51 回:PASS Summit と MVP Summit で進化を確信!
第 50 回:新しくなった Power BI(2.0)の自習書を作成しました!
第49 回:Excel 2016 の Power Query を使う
第 48 回:新しくなった Microsoft Power BI ! 無料版がある!!
第 47 回:「Microsoft Azure SQL Database 入門」 完成&公開!
第 46 回:Microsoft Power BI for Windows app からの Power BI サイト アクセス
第 45 回:Power Query で取得したデータを PowerPivot へ読み込む方法と PowerPivot for Excel 自習書のご紹介
第44回:「SQL Server 2014 への移行とアップグレードの実践」ドキュメントを作成しました
第43回:SQL Server 2014 インメモリ OLTP 機能の上級者向けドキュメントを作成しました
第42回:Power Query プレビュー版 と Power BI for Office 365 へのクエリ保存(共有クエリ)
第41回:「SQL Server 2014 CTP2 インメモリ OLTP 機能の概要」自習書のお知らせです
第40回: SQL Server 2012 自習書(HTML版)を掲載しました
第39回: Power BI for Office 365 プレビュー版は試されましたか?
第38回: SQL Server 2014 CTP2 の公開
第37回: SQL Server 2014 CTP1 の自習書をご覧ください
第36回: SQL Server 2014 CTP1 のクラスター化列ストア インデックスを試す
第35回: SQL Server 2014 CTP1 のインメモリ OLTP の基本操作を試す
第34回: GeoFlow for Excel 2013 のプレビュー版を試す
第33回: iPad と iPhone からの SQL Server 2012 Reporting Servicesのレポート閲覧
第32回: PASS Summit 2012 参加レポート
第31回: SQL Server 2012 Reporting Services 自習書のお知らせ
第30回: SQL Server 2012(RTM 版)の新機能 自習書をご覧ください
第29回: 書籍「SQL Server 2012の教科書 開発編」のお知らせ
第26回: SQL Server 2012 の Power View 機能のご紹介
第25回: SQL Server 2012 の Data Quality Services
第24回: SQL Server 2012 自習書のご案内と初セミナー報告
第23回: Denali CTP1 が公開されました
第22回 チューニングに王道あらず
第21回 Microsoft TechEd 2010 終了しました
第20回 Microsoft TechEd Japan 2010 今年も登壇します
第19回 SQL Server 2008 R2 RTM の 日本語版が公開されました
第18回 「SQL Azure 入門」自習書のご案内
第17回 SQL Server 2008 自習書の追加ドキュメントのお知らせ
第16回 SQL Server 2008 R2 自習書とプレビュー セミナーのお知らせ
第15回 SQL Server 2008 R2 Reporting Services と新刊のお知らせ
第14回 TechEd 2009 のご報告と SQL Server 2008 R2 について
第13回 SQL Server 2008 R2 の CTP 版が公開されました
第12回 MVP Summit 2009 in Seattle へ参加

技術コミュニティでも活動中

Microsoft MVP for SQL Server

松本美穂松本崇博

松本崇博 Blog(SQL Server Tips)
松本美穂ブログ(SQL Serverノート)