SQL Server 2012では新しくカラムストアインデックス(CS-index)という機能が追加されています。

この機能はデータベースのデータから特定の列をまとめ圧縮してインデックスを作成します。

データ検索時に必要な列だけを読み込むことでメモリ上に読み出すデータ量が削減でき、

また同じ列には似たような種類のデータが多く圧縮効率も高く、クエリレスポンスの向上を実現します。

一方で読み取り専用の制約があり(次期SQL Server 2014では更新も可能になるとのこと)、

特に大量データを扱うデータウェアハウス向けの機能となっています。

CS-indexはSAP BWでもサポートされています。詳細は以下でご確認ください。

本記事ではSAP GUIからのCS-indexの適用手順とパフォーマンス比較について簡単に紹介します。

まず、サポートされるBWバージョンとSPSレベルの最小要件は以下の通りです。

BW on HANAの場合はBW 7.3以降へのアップグレードが必須ですが、

CS-indexの場合はBW 7.0からサポートされていますので、

SQL Serverを2012へアップグレードするだけで使用できるユーザーも多いのではないでしょうか。

また標準機能のため追加ライセンスなど不要で手軽に使用することができます。

  • BW 7.0 SPS 27
  • BW 7.01 SPS 12
  • BW 7.02 SPS 12
  • BW 7.30 SPS 8
  • BW 7.31 SPS 5
  • BW 7.4 SPS 5

適用手順は以下の流れで行います。SQL Serverの知識がなくてもSAP GUIからすべての操作が行えます。

CS-indexの作成自体はわずか2ステップで完了でき、作成時間も従来のB-Treeインデックスと変わりません。

  1. Tr-cd: SNOTEから「SAP Note 1771177」の適用します
  2. Tr-cd: SE38からABAPレポート「MSSCSTORE」を実行しキューブごとにCS-indexを定義します
    /wp-content/uploads/2013/09/csi001_287751.jpg
    /wp-content/uploads/2013/09/csi002_287752.jpg
  3. Tr-cd: RSA1から工程2で定義したキューブごとにCS-indexを作成します。削除・再作成も同画面から実行することができます
    /wp-content/uploads/2013/09/csi003_287778.jpg
    /wp-content/uploads/2013/09/csi004_287779.jpg
  4. Tr-cd: DBACOCKPITのSpace => Single Table Analysis欄からCS-indexを作成したキューブ内のテーブルを入力すると、インデックス一覧からプライマリーキーインデックスとカラムストアインデックスの2つのみになっていることが確認できます
    /wp-content/uploads/2013/09/csi005_287786.jpg

今回使用したSAP BI Data Mart Benchmarkでは似通ったデータが多いため非常に圧縮率が高く、

テーブルによってはページ圧縮に比べなんとインデックスサイズが約99%削減という結果になりました。

マイクロソフト社提示のデータによると一般的に50~80%の削減効果が期待できるとのことです。

/wp-content/uploads/2013/09/csi006_287792.jpg

運用面では、CS-indexは読み取り専用のためソースシステムからのデータロードの前後で

削除・再作成が必要ですが、これはパフォーマンス向上を目的とした一般的なBW運用と変わりません。

従来通りプロセスチェーンのデータターゲット管理として実行します。

むしろ、運用管理コスト増の要因となっていた性能改善のためのAggregates(集約)が不要になり、

ロード時間の短縮化と運用管理コストを下げることができると言えます。

最後にクエリレスポンスについて紹介します。

今回のパフォーマンス測定ではSAP BI Data Mart Benchmark(BI-D)を利用しています。

BI-Dは、10個のインフォキューブに25億件の販売管理関連のデータを格納し、

複数ユーザーからクエリを同時実行して1時間あたりの検索処理性能を測るベンチマークとなっています。

ここではこのBI-Dのデータを用いて2500万件レコードを作成し、BI-Dで実行されるいくつかの検索クエリを

個別にTr-cd: RSRT2で実行してCS-indexの性能特性を見てみようと思います。

検索条件を以下のように変えて、B-treeインデックスのSQL Server 2008とSQL Server 2012、

そしてCS-indexのSQL Server 2012で同じ処理を実行しクエリレスポンスを比較しました。

  • 2500万件から9件検索。絞り込み条件は「Month」
  • 100万件から9件検索。絞り込み条件は「Month」「Country」
  • 500件から9件検索。絞り込み条件は「Month」「Country」「SalesOrg」「Distr_Chan」

2500万件とデータ件数が多い場合は約40倍、100万件で約6倍のクエリレスポンスと

大量データからの検索ではCS-indexの効果が非常によく発揮されています。

しかし少量の500件ではCS-indexのほうが遅くなっています。

このように条件によって速くなる場合と遅くなる場合があるため、クエリの特性や対象レコード数などを

事前に確認し、適切なキューブにのみCS-indexを作成することをお奨めします。

/wp-content/uploads/2013/09/csi007_287793.jpg

CS-indexの特徴や制限、向かない処理などの留意事項は以下のMSDNライブラリも参考にしてください。

To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply