すべてのテーブルにColumnStoreインデックスを作成しないのはなぜですか？

Question

ColumnStoreインデックスは、データウェアハウスデータベースのパフォーマンスを向上させ、SQL 2104以降も更新可能です。すべてのテーブルにColumnStoreインデックスを作成してみませんか？

編集： SQL 2014では、CLUSTERED ColumnStoreインデックスがある場合、他のインデックスを持つことはできません。この制限はSQL 2016では解消されているので、私の質問はSQL 2016にもっと関連する可能性があります。

Niko Neugebuer · Answer

SQL Server 2016では、数百万を超える行がある場合、列ストアインデックスを使用できないのは、CCI、CLR、CDC、またはCCIを介したCTでのレプリケーションなど、現在のテクノロジーの制限のみです。 ...それ以外の場合、これは最新のデータウェアハウスにアプローチするためのデフォルトの方法です。

Paul Oster · Answer

通常、データウェアハウスには2つのパフォーマンスの問題があります。データの挿入とデータの読み取り。データの更新や削除を避けて、過度の時間をかけないようにします。列ストアインデックスは、パーティションごとに少なくとも100万行のテーブルで最適に機能します。また、圧縮性カラムで最適に機能します。選択性の高いカラムは圧縮できませんが、選択性の低いカラムは非常に圧縮可能です。 CSインデックスを使用すると、挿入が遅くなります。CSインデックスは、ほとんどのDWの問題が存在する場所です。ある紳士が示したように、MSはその機能を過剰に販売する傾向があり、リリースの準備ができていないものをリリースすることがよくあります。 SS 2016では、CSインデックスはほぼリリースされる準備ができています。 10億行のテーブルがあり、テーブルが圧縮可能な場合は列ストアに適している場合、既存のクラスター化インデックスを削除するだけで40時間以上かかることがあります。多くの場合、DBAは、テーブルからデータを移動するのに多くの時間を費やしています。そのため、クラスター化インデックスを削除してから列ストアを追加できます。これは、時間を挿入するのが不利益であることを知るためです。多くの場合、ソリューションで機能しないことが判明するまでのテストで多くの時間が失われます。 CSインデックスは誰の救い主でもありません。パーティション化と並列化に注意する必要があります。そして多分ある日、まともなCSスキームがリリースされるでしょう。うまくいけば、それまでにあなたはそれらを利用するためにあまり多くの行を持たないでしょう。多数の列がある一時テーブルは、CSを利用するのに適しています。時には彼らはそこで良い利益を提供することができます。 CSを妨害してバッチ処理を強制するいくつかのトリックもありますが、列ストアがない場合は、テーブルレベルでバッチ処理を強制しません。集約、ソート、その他の同様の操作のみをバッチ処理します。また、パーティションが均等に一致しない場合（たとえば、会計期間ごとのパーティションが最も均等に一致する場合）、列ストアは一部のパーティションには有利であり、他のパーティションには不利です。

Cody Konior · Answer

どうして？パフォーマンスがひどいからです。

Microsoftのマーケティング資料は、人々に製品を購入してもらうためのものです。すべての行を読んで、これが製品がすべての状況でどのように機能するかを正確に理解する必要はありません。したがって、ディスク容量の削減と40倍のIMOLTP速度の向上に関する素晴らしい主張を目にしたときは、警報ベルが鳴るはずです。

彼らが嘘をついているなどということではありません。 CSとIMOTLPは、ケーススタディとして使用する非常に特殊なニッチケースに最適です。これらの利点がニッチ以外のユースケースに変換されないということだけです。

免責事項：私はニコのようなCSの専門家ではなく、IMOLTPについても同様です。ミリ秒のレイテンシの大規模な同時ハイパフォーマンスには取り組みません。私は普通のDBAです。

しかし、今年の初めに取り組んでいた小さなレポートデータベースプロジェクトにそれらを実装しようとしました。それは、10倍速ディスクと40倍CPUの大きなメリットをもたらす可能性があると思ったからです。

最初の構造を稼働させ、IMOLTPに変換してからCSに変換すると、全体的にパフォーマンスが大幅に低下することがわかりました。 1〜2週間かけてドキュメントを読み、設定を微調整しましたが、結局のところ、Bツリーが最速でした。

IMOLTPを使用すると、データがメモリと異なる構造で保持されるため、パフォーマンスが10〜40倍向上すると想像しました。しかし、とにかくバッファプールにある小さなテーブルには何の違いもないことがわかりました。これらの利点は、高い同時実行性またはネイティブプロシージャを使用した場合にのみ得られるものでした（私はできませんでした。私のロジックは、多くのウィンドウ関数を持つ6〜7のネストされたCTEでした）。

私はCSからパフォーマンスを分析することもできると想像しましたが、ドキュメントのどこかに記載されているとおり、範囲スキャンではひどいことがわかりました。一般。

そうそう彼らは何かのためのドロップインの交換ではなく、時々読書は十分ではありません。独自のテストを行い、独自の結論のいくつかを形成します。