SQL Server 2014 インメモリ OLTP サンプルの実行結果（50倍の性能向上？）ラッチ待ちが多発しているならインメモリ OLTP！

2014/4/1 から提供された SQL Server の最新バージョン「SQL Server 2014」。
なんといっても SQL Server 2014 の一番の目玉機能は「インメモリ OLTP」（開発コード名：Hekaton）です。その名のとおり、OLTP 向けのインメモリ機能で、テーブルデータやインデックスをすべてメモリ内に載せることができて、高速動作を実現できる機能です。
すでにインメモリ OLTP 機能の早期導入を行っている bwin 社では、従来よりも約16倍の性能向上、SBIリクイディティ・マーケット株式会社では、約30倍の性能向上を確認しているそうです。
このインメモリ OLTP 機能は、同時実行制御に、従来のスナップショット分離機構を進化させた、インメモリ版のスナップショット機構を搭載することで、ラッチ待ちなし（Latch Free）、ロック待ちなし（Lock Free）を実現しているのが大きな利点です。

インメモリ OLTP 機能は、SQL Server 2014 に完全に統合されているので、以下のように SQL Server 2014 のデータベースエンジンを通常通りインストールするだけで、利用することができます。

■ インメモリ OLTP サンプル（50倍の性能向上！？）
Codeplex では、インメモリ OLTP 機能を簡単に試せるようにしたサンプルが提供されています（↓）。
https://msftdbprodsamples.codeplex.com/releases/view/114491

このサンプルを利用する手順は、オンラインブック（SQL Server のヘルプ）の以下の場所に記載されています。
http://msdn.microsoft.com/ja-jp/library/dn511655(v=sql.120).aspx

弊社環境で、このサンプルの負荷テストを実行したときの結果が次のグラフです。

ベンチマーク結果（各種の SQL Server の性能結果）を公開することは、SQL Server の使用許諾契約書で禁止されているので、数値を載せることに悩んだのですが、Microsoft 社での実行結果（グラフ内の 24コアと 8コアの結果）がオンラインブック内に記載されていたので、弊社環境（4コア）も載せてしまいました。弊社のマシンは、3年前に約15万ぐらいで自作した Core i7-2600K、32GBメモリ、SSD（PLEXTOR M3P 512GB）です。
オンラインブックによると、Microsoft 社の環境では、24コアで約 52倍の性能向上、8コアで約 20倍の性能向上を確認しているとのことです。
弊社環境（4コア）では、約 12.8倍の性能向上を確認することができました。
従来ながらのディスクベース（On Disk）の結果が、コア数が少ないほど良い結果になっているのは、（Microsoft 社のテスト環境がどういう状況だったのかは記載されていないので想像になりますが）おそらくラッチ待ちが原因と思われます。このサンプルの負荷テストを実行すると、ディスクベースでは、ラッチ待ちが多発することによって、性能が出ないのですが（インメモリ OLTP ではラッチ待ちが発生しないので速い！）、このラッチ待ちは、コア数が多いほどオーバーヘッドがあるという面があるからです（ラッチ待ちが多発すると、コア数が多いほどスループットが低下します）。

このサンプルの概要は、以下のとおりです。

AdventureWorks2012 データベースを利用（SQL Server 2012 用のサンプル DB）
このデータベース内に、インメモリ OLTP のテーブルと、従来ながらのディスクベースのテーブルを作成（同じ DB 内に混在可能、JOIN も可能です）
ostress ツールで負荷テストを実施（100接続から 5000回ずつ処理を実施。乱数利用）
SalesOrderHeader と SalesOrderDetail テーブルへデータの INSERT
上記の INSERT 時に、SpecialOffer テーブルからディスカウント率を取得（SELECT）
インメモリ OLTP では、一連の処理にネイティブコンパイルストアドプロシージャを利用

負荷テストを実行すると、SalesOrderHeader には約 1000万件、SalesOrderDetail には約 5000万件のデータが INSERT されるので、合計 6000万件のデータが追加されます（Microsoft 社の 24コア環境では 1分で処理が完了しています）。
なので、1秒あたりの INSERT 件数を割り出してみると、以下のようになります。

弊社環境（4コア）では、1秒あたり約 41万件の INSERT ですが、Microsoft 社の 24コア環境では、1秒あたり約 100万件の INSERT が完了（ディスクベースよりも 50倍の性能向上）しています。
この結果から分かることは、「ラッチ待ちが多発するような環境で、インメモリ OLTP が大活躍する！」です。
ちなみに、ラッチ待ちが発生しやすい典型的な例は、連番データ（IDENTITY など）でデータを追加している状況で、多数の同時追加（多くのユーザーが同時にデータを追加）する場合に、最終ページ（インデックスの一番最後のページ）がホットスポット（ラッチ待ちが多発するページ）になるなどです。

ラッチ待ちが多発しているかどうかを調べたい場合は、パフォーマンスカウンターで Latches オブジェクトの「Latch Waits/sec」を利用すると簡単に確認することができるので、現在のシステムでこの値を確認してみることをお勧めします！

現在、弊社環境では、いろいろな状況を想定したインメモリ OLTP 機能の検証を行っていて、どういった状況にインメモリ OLTP 機能が適しているのかを確認しようとしています。ラッチ待ちが多発する環境が最適ですが、そのほかにも適している状況がたくさんあるのでは、と検証を行っています。この結果は、いずれ何かの形でご紹介したいと思っております。

宣伝： CTP2 ベースですが、インメモリ OLTP の概要をまとめた自習書も Kindle 版で出版しております（↓）。