大きなレプリケートされたディメンションの更新（SQL Server PDW）

データウェアハウスにはSQL Server PDWアプライアンスを使用しています。ウェアハウス内のテーブルの1つは、約2,000万行の複製されたテーブルです。ETLプロセスの一部として、このディメンションの古いレコードを期限切れにする必要があります。ただし、少数のレコード（<100）の更新が完了するまでに1時間以上かかることがわかります。これは、できれば改善したいことです。

当然、私が考えた1つのオプションは、このディメンションを複製から分散に変更することでした。私のテストでは、ETLプロセスに時間がかかる（1.5時間から30秒に短縮された）問題が修正されることを示していますが、結合がほとんど同じ分布に基づいていないため、このディメンションの分散バージョンに対するすべての結合が影響を受けます。カラム。これらのクエリのいくつかの実行プランを見ると、通常、ShuffleMoveまたはBroadcastMove操作のいずれかが表示されます。

ここにあるPDWの第一人者に対する私の質問は次のとおりです。

このディメンションの複製バージョンでレコードを更新するパフォーマンスを向上させるために他にできることはありますか？

繰り返しになりますが、分散テーブルへの移行は、他の人が開発した何百ものSQLクエリやレポートに影響を与えるため、最善の解決策ではないようです。

いくつかの質問。2000万行は必ずしもないという大。

現在、更新と削除を実行するためにどのプロセスを使用していますか？

ディメンションはCLUSTERED COLUMNSTORE INDEX、CLUSTERED INDEX、またはHEAPですか？

このテーブルを更新および削除している間に動きがあると言いますか、それともテーブルをレプリケートから分散に変更したときに動きがあっただけですか？

後者の場合は当然のことです。結合および集約互換性がある可能性は低いです。更新/削除を通じて移動をトリガーするために何かをしている場合、それを見ることができます-具体的な例が役立つでしょう。

一般的に、ETLをシンプルに保つことから始めます。

保持する行のみを選択するディメンションに対してCTASを使用し、新しい行を結合し、CASEを使用して変更を取得します（UPDATEをCTAS内の変換に変換します）。完了したら、RENAME OBJECTコマンドのペアを使用して、現在のテーブルから新しいテーブルに切り替えることができます。これはあなたのテーブルの歴史的なビューを持つという追加の利点をあなたに与えます-あなたはあなたの暇な時にそれを落とすことができます。

レプリケートされても、パーティショニングを使用できなくなるわけではありません。テーブルを分割します。

次に、削除または更新する必要のある行について、パーティション全体を新しいテーブルにCTASし、LEFT JOINおよびCOALESCEを使用して、必要な行を保持しながら、変更された行から更新の適切な（つまり新しい）値を取得します。しないもの。

最後に、パーティションを古いテーブルで新しいテーブルに切り替えます。

そして完了:)

私の経験では、PDWは更新と削除を好みません。CTASとパーティションスイッチは適切に機能します。

PDWのUPDATEステートメントは、CTASのように完全に並列ではなく、部分的にのみ並列です。

とはいえ、これはインデックス作成にかかっている可能性があります。実行している実際のコードは何ですか？期限切れになるレコードを見つけるのに役立つインデックスを用意していますか？非クラスター化インデックスを行ストアテーブルに適用する標準的なチューニング手法の一部を適用する必要があります。PDWが主キーをサポートしていないという事実は、多くの場合、人々が自然キーのインデックスを作成するのを忘れていることを意味しているようです。