データウェアハウスのどこにnvarchar（max）ディメンションを配置すればよいですか？
新しいデータウェアハウスのERDを設計しています。
- SQL Server 2016
- 「ファクト」テーブルのクラスター化列ストアインデックス
- スタースキーマが緩い
クラスター化列ストアを使用すると、行の幅に関する一般的な懸念なしに、多くのディメンションを「ファクト」テーブルに直接配置できるため、「ファクト」を引用符で囲み、「ルーズスタースキーマ」と言います。私のディメンションの多くは「ファクト」テーブルに入ります。ディメンションテーブルと代理キーをいくつか作成していますが、ディメンションの説明自体に加えて、ディメンションに属性がある場合のみです。
これにより、nvarchar(max)である非常に広くて基数の多いフィールドが表示されます。深く掘り下げることなく、これらのフィールドを非正規化リストと考えてください。データソースの1つの粒度のために非正規化されたリストが必要です。別のファクトテーブルで正規化していますが、このデータソースで表示しているものはありません。
ユーザーは、私が浮上しているデータマートでキーワードを検索するためにこれらのフィールドを必要とします。現在の設計では、クラスター化列ストアの「ファクト」テーブルにあります。ユーザーは、nvarchar(max)フィールドに触れずにファクトテーブルを頻繁にクエリします。
クラスター化された列ストアテーブルよりも適切な広いディメンションをデータウェアハウスに配置する場所はありますか？
Joe Obbish は、次のことを通知しました 現在はできませんnvarchar(max)をCCIに入れました。 「ファクト」テーブルの拡張としてLOBのテーブルを作成するのがベストプラクティスでしょうか？
今後、他の言語を追加する可能性があります。現在、予見可能な用語として、nvarchar列には英語のみが含まれています。
マイクロソフトは 大規模なデータウェアハウステーブルにCCIを使用する を推奨しますが、次のようないくつかの警告があります。
次の場合は、クラスター化列ストアインデックスを使用しないでください。
- テーブルには、varchar（max）、nvarchar（max）、またはvarbinary（max）データ型が必要です。または、これらの列が含まれないように列ストアインデックスを設計します。
簡単に言うと、列ストアを完全に削除するか、VARCHAR(MAX)列を含まないテーブルに非クラスター化列ストアインデックスを作成するか、LOB列を別のテーブルに移動するかを選択できます。エンドユーザーはVARCHAR(MAX)列をクエリせずにテーブルにアクセスすることがあるので、可能な場合は列ストアを使用して、これらのクエリで最大限のメリットが得られるようにしました。
これを設計していた場合、最初の試みは、VARCHAR(MAX)以外のすべての列を含む非クラスター化列ストアインデックスを使用してワークロードをテストすることです。これは別のインデックスなので、列に追加のストレージが必要になりますが、通常のCCI圧縮率を確認すると、10％しか追加されません。これは最も単純な設計であり、SQL Server 2017の可用性を利用してクラスター化列ストアインデックスにVARCHAR(MAX)列を含めるのに最適な位置にいます。 Niko Neugebauerが、SQL Server vNextのLOBデータを使用したCCIのいくつかのテストについてブログ投稿しました ここ 。