列ストアインデックスの構造は何ですか？
SQL Server 2012のコードネームDenaliの新機能の1つは、 Columnstoreインデックスです。
Bツリー構造、リーフレベルページとBツリーページ間のストレージの違い、含まれるフィールドの影響、それらを使用するための最適化、キーの順序など、通常の古い行ストアインデックスについてはある程度知っています。
列ストアインデックスのinternalsに関する適切な情報を取得できません。
- それはどのように構成されていますか？
- Bツリーはありますか？他の構造が整っていますか？
- データはどのように整理されていますか？
- どのような種類の特定の演算子がそれを使用するのに最も適していますか？
- それらを使用するときに避けるべき他のアンチパターンはありますか？
それらについて私が知ることができることの多くは、基本的に「通常の」インデックスの正反対です。つまり、キーの順序付け、含まれるフィールド、非クラスター化のみです。
どんな洞察もありがたいです。
列ストア構造
列ストアデータは、列ごとに 1つ以上セグメント （通常のLOBアロケーションユニット）に物理的に格納され、通常の方法でパーティション化することもできます。各セグメントには、約100万行の高度に圧縮された値または値の参照が含まれています（いくつかの圧縮手法を利用できます）。値の参照は、2つまでの ハッシュ辞書 の1つのエントリにリンクします。
辞書は メモリに固定 クエリの実行中に実行され、実際のデータ値が必要な場合はいつでも、辞書からセグメントのデータ値IDが検索されます（この検索は、パフォーマンス上の理由から可能な限り延期されます）。
セグメントには、セグメントに保存されている最小値や最大値などのメタデータを含むヘッダーレコードもあります。ヘッダーからの情報は、実行時の処理からパーティションを 除去 するためによく使用されます。ヘッダーレコード情報は通常のLOBデータのルート構造に格納されるため、セグメントを削除すると、ストレージエンジンは物理ストレージからのLOBデータページの読み取りを完全にスキップできます。排除の可能性を最大化するには、列ストアインデックスの構築時にクラスター化インデックスの順序に 依存関係 を含めて 慎重な設計 が必要になる場合があります。
特定の計画演算子
SQL Server 2012では、バッチモードと呼ばれる新しい実行モードが導入されています。このモードでは、約1000行のパケットがオペレーター間で受け渡されるため、プロセッサーの使用効率が大幅に向上します。各パケット内で、列データはベクトルとして表されます。すべてのプランオペレーターがバッチモードの操作をサポートしているわけではありませんが、列ストアインデックススキャン、ハッシュ内部結合、バッチハッシュテーブルビルド、ビットマップフィルター、ハッシュ集計（ スカラー 集計ではない）、フィルター、スカラーを計算します（投影および式の評価用）。クエリ実行プランが拡張され、推定および実際の実行モードが表示されるようになりました。
アンチパターン
最初のリリースには、許容される データ型 への制約を含め、多数の制限があります。最も一般的なタイプがサポートされています。サポートされていないデータ型には、18桁を超える精度のDECIMAL、(N)VARCHAR(MAX)、UNIQUEIDENTIFIER、CLR型、(VAR)BINARYなどがあります。
文字列タイプ 、 OUTER JOIN 、 IN、EXISTS 、 NOT IN 、 OR 、 UNION ALL 回避策がない限り、パフォーマンスが大幅に低下する可能性があります（行モードの実行）。このセクションのリンク先の記事に示されているように、通常は異常な構文の書き換えを伴う採用。
詳細情報
Remus Rusanuが素晴らしい概要をブログに書きました here 。