SQL Server 2012 – 列ストアインデックスを実装した最初のリリースとその課題
DWH ワークロードでの劇的な性能向上が見込める列ストア インデックスでしたが、SQL Server ＾2012 リリース当初は、以下の制限がありました。
- 行データの更新・削除・挿入は行えない
- 主キーや外部キー、一意インデックスとして利用できない。そのため、データを更新するには、以下のような対処が必要でした。
- 列ストア インデックスを無効化し、データ更新後に、再構築する
- ステージング テーブルでデータを更新・列ストア インデックスを作成し、ターゲット テーブルにパーティション切り替えを実施
- 変更されないデータを格納するテーブルに列ストア インデックスを作成し、変更されるデータを格納したテーブルと UNION させたビューを作成
SQL Server 2012 リリース当時は、実システムでの列ストア インデックスの利用は運用コストとパフォーマンス向上のトレードオフを見極める必要がありました。
詳細については「カラムストア インデックスのすべて（後編）」をご覧ください。
SQL Server 2014 - 列ストア インデックス適用範囲の拡大と運用コスト削減に向けた機能強化
SQL Server 2014 では前述の制限を無くした、更新可能なクラスター化 列ストア インデックスが導入されました。これにより、より多くの要件で列ストア インデックスのメリットを享受して頂けるようになりました。多くのお客様で運用負荷の低い列ストア インデックスの導入が実現しましたが、以下の制限は依然として残っていました。
-
クラスター化列ストア インデックスはテーブルに作成できる唯一のインデックス(他のインデックスと共存できない)
→依然として主キーや外部キー、一意インデックスとしては利用できない - 非クラスター化列ストア インデックスは読み取り専用
- SQL Server 2014 から導入されたメモリ最適化テーブルに対して、列ストア インデックスは作成できない
SQL Server 2016 - 様々なワークロードへの対応
世界中のデータが爆発的な増加傾向にあること、それに伴うリアルタイム分析要求がさらに高まることを鑑み、Microsoftはそれらのニーズへの対応を製品・サービスの強化戦略の大きな柱に据えています。DWH において利用が拡大してきた列ストア インデックスですが、SQL Server 2016 では前述の制限を解消すると共に、膨大なデータへのリアルタイム分析要求への対応を開始しました。
クラスター化列ストア インデックスに対する、非クラスター化インデックス(B-Tree)作成のサポート
SQL Server 2016 では、以前のリリースではサポートしていなかったクラスター化列ストア インデックスに対する主キー インデックスや外部キー インデックスの作成ができるようになりました。これにより、列ストア化できるテーブルの制限が大幅に緩和されました。
列ストア インデックスが苦手とする狭い範囲でのスキャンやシーク、等価条件での検索などの処理はB-Treeインデックスの追加で対応できるようになり、チューニングの幅が広がりました。
非クラスター化列ストア インデックスの DML 対応 - ディスクベースの OLTP 表に対するリアルタイム オペレーショナル分析の実現
ヒープ(テーブル)またはクラスター化インデックスに対して作成された非クラスター化 列ストア インデックスが更新・削除・挿入処理に対応しました。これにより、OLTP 処理で利用されるような変更が頻繁に発生する表に対するクエリのチューニングにも非クラスター化列ストア インデックスを利用できるようになりました。
メモリ最適化テーブルに対するクラスター化列ストア インデックス作成のサポート - インメモリの OLTP 表に対するリアルタイム オペレーショナル分析の実現
メモリ最適化テーブルにクラスター化列ストア インデックスを作成できるようになりました。これにより、さらにシビアな性能が求められるシステムにおいてもリアルタイム オペレーショナル分析を実現することができるようになりました。
また、メモリ最適化テーブルに作成されたクラスター化列ストアインデックスはストレージにも永続化されるため、次回起動時に列セグメントを形成し直す必要なく非常に効率的な実装になっています。
上記二つのリアルタイム オペレーショナル分析シナリオでは、ベースとなるテーブルに対するデータの変更は自動的にメンテナンスされるため、分析およびOLTP ワークロードにおいてデータの遅延はありません。リアルタイム分析を利用するシナリオでは、ETL の必要性およびDWHを別途用意するためのコストと複雑性が大幅に削減されます。
リアルタイム オペレーショナル 分析は、オペレーショナル ワークロードと分析ワークロードの両方を実行する ERP のようなシングルデータソース環境でのシナリオをターゲットとしています。分析ワークロードを実行する前に複数データソースのデータを統合したDWHや、キューブのような事前集計による分析パフォーマンスの向上を目指したものを置き換えるものではない点についてご留意ください。
