4

タイプ 2 の緩やかに変化するディメンションを持つテーブルがあるとします。

次の列を使用して、このテーブルを次のように表現しましょう。

* [Key]
* [Value1]
* ...
* [ValueN]
* [StartDate]
* [ExpiryDate]

この例では、[StartDate] が事実上、特定の [Key] の値がシステムに認識されるようになる日付であると仮定します。したがって、主キーは [StartDate] と [Key] の両方で構成されます。

特定の [Key] に対して新しい値のセットが到着すると、[ExpiryDate] を「12/31/9999」などの事前定義された高いサロゲート値に割り当てます。次に、その [Key] の既存の「最新」レコードを、新しい値の [StartDate] と等しい [ExpiryDate] を持つように設定します。結合に基づく単純な更新。

したがって、特定の [キー] の最新のレコードを常に取得したい場合は、次のようなクラスター化インデックスを作成できることがわかります。

* [ExpiryDate] ASC
* [Key] ASC

キースペースは非常に広い場合がありますが (たとえば、100 万個のキー)、[ExpiryDate] で最初に並べ替えることで、読み取り間のページ数を最小限に抑えることができます。また、特定のキーの最新のレコードの [ExpiryDate] は常に '12/31/9999' であることがわかっているため、これを有利に利用できます。

しかし... 特定の時点ですべての [Key] のポイント イン タイム スナップショットを取得したい場合はどうすればよいでしょうか。理論的には、キースペース全体が同時に更新されるわけではありません。したがって、特定の時点では、[StartDate] と [ExpiryDate] の間のウィンドウは可変であるため、[StartDate] または [ExpiryDate] のいずれかで並べ替えても、探しているすべてのレコードが含まれる結果は得られません。連続。確かに、[StartDate] が定義した時点よりも大きいすべてのレコードをすぐに破棄できます。

本質的に、典型的な RDBMS では、特定の時点のすべてのキーの値を取得するための読み取り回数を最小限に抑える最善の方法を提供するインデックス作成戦略は何ですか? [キー] でテーブルをパーティション分割することで、少なくとも IO を最大化できることはわかっていますが、これは確かに理想的ではありません。

あるいは、この問題をよりパフォーマンスの高い方法で解決する、ゆっくりと変化するディメンションの別のタイプはありますか?

4

2 に答える 2

1

レイジーDBA

ディメンション テーブルのすべての値を戻すことについて話しているのですか? もしそうなら、テーブルからではなくインデックス自体からのみ値を引き出すように、追加のカバレッジを備えた非クラスター化インデックスを追加してみませんか? そうすれば、潜在的にテーブルスキャンを実行するのではなく、いくつかの「カバーされた」値が添付された B ツリーをスキャンしていますか? 相対的なパフォーマンスを保証することはできませんが、明らかに取り組んでいるシナリオについてテストする価値はあります。

乾杯

オジーメデス http://ozziemedes.blogspot.com/

于 2010-01-09T05:07:02.093 に答える
0

これが本当に "緩やかに変化するディメンション" テーブルである場合は、クラスター化された列ストア インデックスを検討します。あなたが質問したときにこれが利用できなかったことは知っていますが、とにかく。" https://msdn.microsoft.com/en-us/library/gg492088.aspx " と " http://www.nikoport.com/2013/07/05/clustered -columnstore-indexes-part-1-intro/ ".

行ストア インデックスに固執する場合、テーブルにデータを順番に挿入する場合、私が過去に行ったことは ID フィールドを利用することでした。クエリは次のようになります。

    declare @id;
    select @id = min(ID) from table where date = '12/31/9999';
    select fields from table where key = 112 and id > @id;
于 2016-10-26T15:33:08.250 に答える