列ストアインデックスの構造は何ですか？

コードネームDenaliが付けられたSQL Server 2012の新機能の1つに、Columnstoreインデックスがあります。

Bツリー構造、リーフレベルとBツリーページのストレージの違い、含まれているフィールドの影響、それらを使用するための最適化、キーの順序など、通常の古い行ストアインデックスについてかなり知っています。

列ストアインデックスの内部情報を得るのに苦労しています。

• どのように構成されていますか？
• Bツリーはありますか？その他の構造はありますか？
• データはどのように編成されていますか？
• どの種類の特定の演算子を使用するのが最適ですか？
• 他のアンチパターンを使用する際に避けるべきものはありますか？

それらについて私が知ることができるものの多くは、基本的に「通常の」インデックスの正反対です。つまり、キーの順序付け、含まれるフィールド、非クラスタ化のみです。

どんな洞察も大歓迎です。

列ストアの構造

列ストアデータは、列ごとに1つ以上の セグメント（通常のLOB割り当て単位）に物理的に格納され、通常の方法でパーティション化することもできます。各セグメントには、約100万行の高度に圧縮された値または値参照が含まれています（いくつかの圧縮技術が利用可能です）。値参照は最大2つのハッシュ辞書の 1つのエントリーにリンクします。

クエリの実行中に辞書がメモリに固定され、実行が実際のデータ値を必要とするたびに、セグメントのデータ値IDが辞書で検索されます（この検索は、パフォーマンス上の理由から可能な限り延期されます）。

セグメントには、セグメントに格納されている最小値や最大値などのメタデータを含むヘッダーレコードもあります。多くの場合、ヘッダーからの情報を使用して、実行時の処理から完全なパーティションを排除できます。ヘッダーレコード情報は通常のLOBデータルート構造に格納されるため、セグメントを削除すると、ストレージエンジンは物理ストレージからのLOBデータページの読み取りを完全にスキップできます。削除の可能性を最大化するには、Columnstoreインデックスの構築時のクラスター化インデックスの順序への依存を含め、慎重に設計する必要があります。

特定の計画オペレーター

SQL Server 2012には、バッチモードと呼ばれる新しい実行モードが導入されています。このモードでは、約1000行のパケットがオペレーター間で受け渡され、プロセッサーの使用効率が大幅に向上します。各パケット内では、列データはベクトルとして表されます。すべてのプラン演算子がバッチモード操作をサポートしているわけではありませんが、列ストアインデックススキャン、ハッシュ内部結合、バッチハッシュテーブル構築、ビットマップフィルター、ハッシュ集計（スカラー集計ではない）、フィルター、計算スカラー（投影および式用）評価）。クエリ実行プランが強化され、推定および実際の実行モードが表示されます。

アンチパターン

最初のリリースには、使用可能なデータ型の制約など、多数の制限があります。最も一般的なタイプがサポートされています。サポートされていないデータ・タイプは、DECIMAL18桁、より高精度大きいと(N)VARCHAR(MAX)、UNIQUEIDENTIFIER、CLR型、および(VAR)BINARY。

使用文字列型は、OUTER JOIN、IN、EXISTS、NOT IN、OR、UNION ALL回避策は、このセクションのリンクされた記事に示すように、典型的には珍しい構文書き換えを伴うことが採用されていない限り、大幅に低減性能（ローモード実行）をもたらし得ます。

詳しくは

Remus Rusanuはここで素晴らしい概要をブログに書いています。