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

ホーム > 技術情報 > SQL Server 2012 自習書 No.12 Analysis Services によるインメモリ BI 入門

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

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

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

4.9 BUCKET_COUNT の違いによる性能差

HASH インデックスでは、BUCKET_COUNT(バケット数)を適切な値へ設定していないと、性能低下の原因に繋がります。

これについて、col2 の検索(取得件数が約 5件になる検証)で利用したのと同じテーブル(1,000万件のデータ)で説明します(以下)。

00300

col2 列の HASH インデックスBUCKET_COUNT 400万100万10万1万に設定したテーブルを 4つ作成しました。

このテーブルに対して、次のように INSERT .. SELECT ステートメントを利用して、1,000万件分のデータを一括コピーしています。

00301

◆ BUCKET_COUNT の違いによる INSERT .. SELECT の性能差

上の INSERT .. SELECT 1,000万件のデータを一括コピーしたときの性能差は、次のようになりました。

00302

BUCKET_COUNT 100万のときは 1.1倍10万のときは 2.1倍1万のときは 9.2倍も遅くなっていることを確認できました。

今回の col2 列は、次のように一意な値が約 200万件あります。

00303

また、特定の値で検索すると、約 5件の結果が返ります(約200万件 * 約5件=1,000万件)。

00304

◆ BUCKET_COUNT の違いによる SELECT の性能差

BUCKET_COUNT が異なる場合の SELECT ステートメント(col2 列での検索)の性能差は、次のようになりました。

00305

BUCKET_COUNT 100万のときは 1.01倍(ほぼ同じ)、10万のときは 1.1倍1万のときは 1.66倍も遅くなっていることを確認できました。

このように、BUCKET_COUNT の設定は、INSERT SELECT へ影響があることを確認できました。特に BUCKET_COUNT を小さい値に設定した場合(col2 の例では 1万件)は、性能が大きく低下するので注意が必要です。

◆ BUCKET_COUNT の設定基準

BUCKET_COUNT の設定基準は、オンライン ブックの以下のトピックに記載されています。

ハッシュ インデックスの適切なバケット数の決定
http://msdn.microsoft.com/ja-jp/library/dn494956.aspx

00306

このトピックでは、「ほとんどの場合、バケット数はインデックス キーにおける別個の値の数の 1 倍から 2 倍の範囲に設定する必要があります」と記載されています。別個の数は、前述の DISTINCT で検索した一意な値の数のことで、col2 では約200万件でした(以下に再掲)。

00307

したがって、オンライン ブックの記述によれば、col2 列では、200万(1倍)~400万(2倍)ぐらいが妥当な設定値であるということになります。実際、400万に設定したときと、100万に設定したときでは、性能差が現れたので(100万に設定したほうが若干遅くなったので)、col2 に関しては、400万程度が妥当な設定値であることが分かります。また、BUCKET_COUNT は、テーブルの作成時(CREATE TABLE 時)に設定して、後から変更することができないものなので、将来増えるであろうデータ量も想定して、多めに設定しておく必要があります(その分、メモリを消費することになりますが、どれぐらいのメモリを消費するのかについては後述します)。

また、このトピックでは、「バケット数は内部的に、最も近い 2 のべき乗に切り上げられます。たとえば、バケット数に 300,000 を指定すると、実際のバケット数は 524,288 になります。」と記載されていて、BUCKET_COUNT で設定した値に、最も近い 2のべき乗に設定される(切り上げられる)とあります。

したがって、代表的な 2のべき乗を知っておいた方が設定がしやすくなるので、次の表が参考になると思います。

00308

◆ 空きバケット数、ハッシュ インデックスのチェーンの長さ

HASH インデックスでは、十分な BUCKET_COUNT を設定している場合(一意な数よりも大きい値へ設定している場合)には、同じ値が、同じハッシュ値になって、チェーンが構成されます。

00309

これに対して、BUCKET_COUNT の設定が小さい場合には、異なる値でも、同じハッシュ値になってしまうことがあるので、次のようにチェーンが長くなってしまいます。これは、ハッシュ コリジョン衝突)と呼ばれています。

00310

現在のバケット数や、空いているバケット数、チェーンの長さなどは、次のように「dm_db_xtp_hash_index_stats」動的管理ビューを利用すると確認することができます。

SELECT 
   -- object_name(hs.object_idAS 'object name'
   i.name as 'index name'
   hs.total_bucket_count,
   hs.empty_bucket_count,
   floor((cast(empty_bucket_count as float)/total_bucket_count* 100AS 'empty_bucket_percent',
   hs.avg_chain_length
   hs.max_chain_length
FROM sys.dm_db_xtp_hash_index_stats AS hs 
   JOIN sys.indexes AS 
   ON hs.object_id=i.object_id AND hs.index_id=i.index_id
00311

この結果のうち、一番上のものが BUCKET_COUNT 1万に設定したときのもので、現在のバケット数(total_bucket_count)が 16,384、空きバケット数(empty_bucket_count)が 0avg_chain_length平均のチェーンの長さ)が 610 にもなっていて、ハッシュ コリジョンが多発していることが分かります。

これに対して、上から 4つ目の結果が BUCKET_COUNT 400万に設定したときのもので、現在のバケット数4,194,304空きバケット数2,590,043259万空いている)、平均のチェーンの長さ6 になっていて、妥当なチェーンの長さになっていることが分かります(col2 は、約5件の結果が返るので、チェーンの長さは 5前後が妥当になります)。

このように、設定した BUCKET_COUNT が妥当かどうかは、このクエリを実行することで確認することができるので、確認しておくことをお勧めします。

◆ バケット数の違いによるメモリ使用量の差

バケット数の違いによるメモリ使用量の差は、dm_db_xtp_table_memory_stats 動的管理ビューを利用して確認することができます。

SELECT OBJECT_NAME(object_idAS テーブル名*
 FROM sys.dm_db_xtp_table_memory_stats
00312

memory_allocated_for_indexes_kb が、インデックスに割り当てられたメモリ量で、この値は、バケット数をもとに決定されます。インメモリ OLTP では、1つのバケット数に 8バイトを消費するので、次の表のようになります。

00313

今回のテーブルは、PKcol1)の BUCKET_COUNT 1億に設定しているので、1,048,576 KB1GB)にプラスして、col2 BUCKET_COUNT 100万なら +8,1928MB)で、1,056,768 KB400万なら +32,7688MB)で、1,081,344 KB を消費することになります。

なお、メモリ使用量の見積もり方法については、オンライン ブックの以下のトピックも参考になります。

メモリ最適化テーブルのメモリ必要量の推定
http://msdn.microsoft.com/ja-jp/library/dn282389.aspx

メモリ最適化テーブルのテーブルと行のサイズ
http://msdn.microsoft.com/ja-jp/library/dn205318.aspx

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

事例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ノート)