発表されたときはすごいなーと思いながらも、多分業務で使うことはしばらくないだろうなーと思っていたら、いきなり使うことになりそうなので急遽列ストアインデックスについてお勉強を始めてみる - 都内で働くSEの技術的なひとりごと / Technical soliloquy of System Engineer working in Tokyo

　早速お勉強。まず、基本概念から。
列ストアインデックスの説明

SQL Server のインメモリ列ストアインデックスは、列ベースのデータストレージと列ベースのクエリ処理を使用して、データを格納および管理します。列ストアインデックスは、主に一括読み込みと読み取り専用のクエリを実行するデータウェアハウスのワークロードで適切に動作します。従来の行指向ストレージの最大 10 倍のクエリパフォーマンスと、非圧縮データサイズの最大 7 倍のデータ圧縮を達成するために列ストアインデックスを使用します。

　一括更新向きなんですね。OLTP 系には不向きなのかな？なんか日本語がわかりづらい。

列セグメントの断片化を低減し、パフォーマンスを高めるために、列ストアインデックスでは、一部のデータおよび削除された行に対応する ID の B-Tree を一時的に行ストアテーブルに格納することがあります。デルタストア操作は内部で処理されます。列ストアインデックスは、正しいクエリ結果を返すために、列ストアとデルタストアの両方からのクエリ結果を結合します。
デルタストア
クラスター化列ストアインデックスでのみ使用されるデルタストアは、行数が列ストアに移動できる規模になるまで行を格納する行ストアテーブルです。デルタストアは、読み込みやその他の DML 操作のパフォーマンスを高めるために、クラスター化列ストアインデックスで使用されます。
大規模な一括読み込みでは、行のほとんどがデルタストアを通らずに列ストアに直接移動します。一括読み込みの最後に位置する行の数は、行グループの最小サイズである 102,400 行を満たすには足りないことがあります。この場合、それらの行は列ストアではなくデルタストアに移動します。 102,400 行未満の小規模な一括読み込みでは、すべての行がデルタストアに直接移動します。
デルタストアは、最大行数に達すると閉じられます。閉じている行グループは、組ムーバープロセスによって確認されます。閉じている行グループが見つかると、その行グループが圧縮され、列ストアに格納されます。

　tuple-move というプロセスによって、102,400 以上になったらデルタストアから列ストアに移動するのか。

deltastore
Used with clustered columnstore indexes only, a deltastore is a rowstore table that stores rows until the number of rows is large enough to be moved into the columnstore. A deltastore is used with clustered columnstore indexes to improve performance for loading and other DML operations.
During a large bulk load, most of the rows go directly to the columnstore without passing through the deltastore. Some rows at the end of the bulk load might be too few in number to meet the minimum size of a rowgroup which is 102,400 rows. When this happens, the final rows go to the deltastore instead of the columnstore. For small bulk loads with less than 102,400 rows, all of the rows go directly to the deltastore.
When the deltastore reaches the maximum number of rows, it becomes closed. A tuple-move process checks for closed row groups. When it finds the closed rowgroup, it compresses it and stores it into the columnstore.

　この図がわかりやすいですね。
f:id:koogucc11:20160629023502p:plain

図が示すように、クラスター化列ストアインデックスにデータを読み込むには、SQL Server は次のように動作します。
最大サイズの行グループを列ストアに直接挿入します。データが読み込まれると、SQL Server は開いている行グループに先着順でデータ行を割り当てます。
それぞれの行グループが最大サイズに到達すると、SQL Server は次の処理を行います。
行グループを CLOSED としてマークします。
デルタストアをバイパスします。
列ストア圧縮を使用する行グループで、それぞれの列セグメントを圧縮します。
圧縮された列セグメントを列ストアに物理的に格納します。
次のように、列ストアまたはデルタストアに残りの行を挿入します。
行数が行グループの最小限の行数の要件を満たしている場合は、行が列ストアに追加されます。
行数が行グループの最小限の行数の要件を満たしていない場合は、行がデルタストアに追加されます。

　非クラスター化列ストアインデックスの場合
f:id:koogucc11:20160629023609p:plain

　ふむ、結構辛そうね。

パフォーマンスに関するヒント
列ストアインデックスを並列で作成するための十分なメモリの計画
列ストアインデックスの作成は、メモリに制限がない限り既定で並列操作になります。インデックスを並列で作成するには、インデックスを順次作成する場合よりも多くのメモリが必要です。十分なメモリがある場合、列ストアインデックスの作成には、同じ列で B-Tree を構築する場合の約 1.5 倍の時間がかかります。
列ストアインデックスを作成するために必要なメモリは、列数、文字列型の列数、並列処理の最大限度 (DOP)、およびデータの特性によって異なります。たとえば、テーブル内の行数が 100 万未満の場合、SQL Server はスレッドを 1 つだけ使用して列ストアインデックスを作成します。
テーブルに 100 万を超える行があり、SQL Server で MAXDOP を使用してインデックスを作成するための十分なメモリ許可を取得できない場合、SQL Server は必要に応じて自動的に MAXDOP を減らし、使用できるメモリ許可に合うように調整します。場合によっては、メモリが制限された状況でインデックスを構築できるように、DOP を 1 まで小さくする必要があります。

　眠い。今日のカラムストアインデックスのお勉強は以上です。

Type-C 用にケーブル買ってみよう、と思ったけど使い道あるのか？