3

外部キーのプロファイル

FK      Distinct Values      %
----    ---------------  ------
Id1     1                 0.1%
,Id2    4                 0.3%
,Id3    5                 0.3%
,Id4    6                 0.4%
,Id5    6                 0.4%
,Id6    95                6.1%
,Id7    97                6.2%
,Id8    1423             90.7%

すべての外部キーは、すでにクラスター化されたPrimary Key. このファクト テーブルは、6 つのディメンションを含むスター スキーマの一部です (ID の 6、7、および 8 は同じ日付ディメンションを参照します)。

現在、ファクト テーブルには約 1800 行 (信じられないほど小さい) があり、毎月その量だけ増加すると予想されます。

結合を容易にするために、各外部キーに独自のクラスター化されていない非一意の単一列インデックスを設定する必要がありますか? もしそうなら、なぜですか？

各外部キーは、そのディメンション テーブルのクラスター化インデックス (主キー) の一部になります。

インデックスを外部キーに配置する必要がある場合、列のカーディナリティが低い場合、フィル ファクターとパディング インデックスをどのように設定する必要がありますか?

4

2 に答える 2

2

あなたのプロファイルは、「%」列では意味がありません。フィールド全体で異なる値の「パーセンテージ」を見つけているのはなぜですか? 個別の値の分布に関する統計が必要です。Id8 のキーの 99% は同じですか? それらは均等に分散されていますか？等

ここで述べていることはすべて、より大きなテーブルに適用されることに注意してください。1 か月あたり 1800 行のインデックスは、スペースと時間の無駄になる可能性があります。

@jrara のすべてのディムのインデックス作成に関する「ルール」は、簡単に適用できるルールですが、それだけでは簡単に間違いを犯す可能性があります。たとえば、1 億行の顧客ディメンションで Oracle ビットマップ インデックスを使用したくありません。

インデックス作成は、クエリがデータに対してどのように見えるかによって異なります。「概要」レポートの集計とグループ化を実行するためにファクト テーブルのフル スキャンを実行している場合、インデックスは役に立ちません。これは、ユーザーがディメンションの属性をフィルター処理しようとしているときに役立ちます。そのフィルターにより、ファクト テーブルからレコードのごく一部を検索するだけで済みます。テーブルへの主要なエントリ ポイントはありますか? 通常、「Id8」ディメンションの属性でフィルタリングしてから、他のディメンションの属性でグループ化する必要がありますか?

基本的に、あなたの質問に対する答えは次のとおりです。

結合を容易にするために、各外部キーに独自のクラスター化されていない非一意の単一列インデックスを設定する必要がありますか?

一般に、ディメンション テーブルが小さく、Dim キーがファクト テーブルに比較的均等に分散されている限り、可能です。通常、ファクト テーブルの行の 99% を取得するためにインデックス アクセスを使用する方が悪いです。

列のカーディナリティが低い場合、フィル ファクタとパディング インデックスをどのように設定する必要がありますか?

FILLFACTOR を 100% 未満に下げると、インデックスの読み取りが遅くなります。これは、DB が読み取るためのインデックスに (空の) ページが増えるためです。データ ウェアハウスは高速選択用に設計されているため、fillfactor を下げることはあまりお勧めしません。

そうは言っても、いくつかのケースでは、FILLFACTOR を調整することが理にかなっている場合があります。ファクト テーブルが非常に大きく (数百 GB/TB)、インデックスの再構築に数時間かかる場合、インデックスの再構築は月に 1 回またはそれ以下の場合もあります。このような場合、毎日テーブルに追加するデータの量 (パーセンテージ) を把握し、それに応じてフィルファクターを設定する必要があります。

于 2012-11-26T14:09:18.660 に答える
2

まず第一に、外部キーに基づいてクラスター化された主キーを作成するべきではないと思います。クラスタ化されたインデックスは、ディスク上のデータを整理するものであり、それがより優れています。

  • 狭い
  • 数値
  • 増加 (厳密に単調)

したがって、行を一意にするために、たとえば外部キーに一意の制約を作成する方がよいと思います。または、これらの列にクラスター化されていない主キーを作成してから、日付外部キー (YYYYMMDD) などにクラスター化インデックス (主キーではない) を作成します。

通常、検索を高速化するために、Fact テーブルで外部キーにインデックスが付けられます (クラスター化されておらず、一意ではありません)。しかし、主キーと外部キーの制約により ETL の読み込みが遅くなるため、次元モデルにカーディナリティをまったく適用しない人もいます (ETL が参照整合性を処理します)。

ヴィンセント・レイナルディより

  1. 質問: ファクト テーブルにどのようにインデックスを付けますか? そして、その理由を説明してください。{H}

回答: クラスター化されていない (SQL Server) またはビットマップ (Oracle) のすべてのディメンション キー列に個別にインデックスを付けます。ディム キー列はディメンション テーブルへの結合に使用されるため、それらにインデックスが付けられている場合、結合は高速になります。例外的な候補者は、次の 3 つの追加事項を提案します: a) ファクト キーを個別にインデックス化する、b) ディム キーの組み合わせで正しい順序でカバリング インデックスを作成することを検討する、c) ファクト テーブルがパーティション分割されている場合、パーティション キーを含める必要があるすべてのインデックスで。

于 2012-11-26T09:19:42.283 に答える