SQL Server 2016-ColumnStoreクラスター化インデックスと非ColumnStoreクラスター化インデックス
ここ にあるSQL 2016列ストアインデックスガイドを読んだだけです。 OLTPと分析の両方に使用されるSQL 2016データベースに、かなり大きなテーブル（数億から数十億行）を作成します。
これらのテーブルは、主に次の2つの方法のいずれかでクエリされます。1）ユーザーは、Where句の特定の離散値に基づいて、かなり小さな結果セットを取得します（例：Where SubId = 'ABC'）; 2）ユーザーは日付/時刻の値の範囲に基づいて、より大きな結果セットを取得します（例：ReadTime Between '2/1/2017' And '2/5/2017'）。
Columnstoreインデックスはscenerio＃2に適していると思うので（私は思う）、scenerio＃1のクラスター化インデックスを非columnstore（たとえば、SubId）にし、非クラスター化列ストアインデックス（たとえば、ReadTime）を作成することを検討しています）scenerio＃2の場合。
ただし、ReadTimeで列ストアクラスター化インデックスを作成し、SubIdで非列ストアインデックスを作成した場合よりも、これが実際に優れているかどうかはわかりません。
この決定をする方法がわかりません。
クラスター化列ストアインデックスは、主にデータウェアハウス、OLAP、またはレポートソリューションで使用するように設計されています。WHERE x = yタイプのクエリ。彼らは優れていますWHERE x < 1 and x > 1000000タイプのクエリ。クエリプロセッサはCCIで範囲スキャンを実行できます。
ワークロードがOLTPクリティカルであると仮定すると、私は、多くの作業をせずに、標準のBツリークラスター化インデックスを使用してテーブルを作成し、ポイントに役立つ適切に設計された非クラスター化列ストアインデックスを検討することをお勧めします＃2。
ワークロードのOLTPコンポーネントが小さいか、それほど重要ではないが、レポートコンポーネントis重要である場合、クラスター化列ストアインデックスとしてテーブルを作成できます。次に、OLTPコンポーネントをサポートするのに役立つように、starndard bツリーの非クラスター化インデックスをいくつか追加します。