クラスター化列ストアインデックスを使用してディメンションテーブルが必要になるのはいつですか？
レポートデータベースでMS SQL Server 2016クラスター化列ストアインデックス（CCIと呼ぶ）を使用しています。
最初のデザインではスタースキーマを考えていましたが、その後CCIで遊んでいます。現在、文字列を「ファクト」テーブルに直接フラット化するために、多くのディメンションテーブルを破棄しています。ディメンションテーブルを保持する唯一の場所は、そのディメンションに頻繁に変更される属性があり、変更された属性をすべての履歴レコードに適用できるようにする必要がある場合です。 DWの経験は豊富ですが、CCIを探索する自由な時間がない同僚をがっかりさせました。
個別の列としてディスクに保存されたフラットテーブル（および提供される大規模な圧縮）は、必ずしも狭くする必要はないようです。 CCIを使用する場合、いつディメンションテーブルが必要ですか？
私はあなたの質問がカラムナストレージをサポートするRDBMSに当てはまるとは思いません。 SQL Serverの観点から回答を書いていますが、ほとんどの理由はSQL Serverに固有の実装の詳細に依存しています。
CCIを使用する場合、いつでもディメンションテーブルが必要ですか？
1。ディメンションテーブルへの変更量が多いため、CCIファクトテーブルの更新が実用的ではありません
500 M行のファクトテーブルでは、一部のディメンション列が不運に変化した場合、CCIで数億行を更新する必要がある場合があります。これを行うために知っている唯一の実用的な方法は、テーブル全体を書き換えるか、削除と挿入を行うことです。削除+挿入アプローチの場合、すべての列のデータをステージング領域に書き込み、シリアル削除クエリが完了するのを待ち（パーティションごとに削除できない場合を除く）、すべての行のすべての列を読み取る必要があります。変更が必要な行を含む可能性のある行グループなど。コーディングの手間がかかり、データの変換にかなりの費用がかかる可能性があります。ファクトテーブルが広くなるほど、問題は悪化します。
2。文字列列の長さと数により、メモリ制限のためにCCI圧縮が実用的ではなくなります
文字列列のメモリ許可要求は、CCIの構築方法によっては制御不能になる可能性があります。たとえば、VARCHAR(8000)列のREBUILDは、DOPごとに6.5 GBを要求し、列の長さに応じて縮小します。 CCI挿入のメモリ許可要求は25秒でタイムアウトします（これを変更する方法がないことを私が知っている限り）。これは、圧縮を実行するのに十分なメモリがない場合、一部のCCI挿入クエリが（デッドロックやその他の悪いこととともに）デルタストアに直接書き込みを開始する可能性があることを意味します。
。ETLまたはメンテナンスプロセスは、デルタストアを防止またはクリーンアップするように設計されていません
質問で「大規模圧縮」について言及していますが、デルタストアのデータは圧縮されていません。 ETLプロセスがヒープを作成し、後でそのデータを列ストア形式に圧縮する場合、ステージング用に、慣れているよりも多くの一時スペースを使用している可能性があります。パーティション分割されたテーブルに多数の並列挿入を行うと、データが圧縮されない数千以上のデルタストアになる可能性があります。
4。ディメンションテーブルには多数の一意の長い文字列があります
SQL Server 2016では、列あたり16 MBの辞書サイズに制限されています。列に一意の値が多すぎる場合は、その制限を超える可能性があり、ディクショナリの圧力により行グループが分割されます。文字列列を既存のCCIファクトテーブルに追加すると、圧縮された行グループが小さくなり、圧縮とクエリのパフォーマンスの効率が低下する可能性があります。