リフレッシュモードが動的テーブルのパフォーマンスに与える影響¶

増分リフレッシュパフォーマンスの理解¶

増分リフレッシュでは、通常、ほとんどの労力は動的テーブルの変更を計算することに費やされます。これはクエリによって異なり、非常に複雑になることがあります。よくある誤解は、増分リフレッシュはソーステーブルの変更のみをスキャンするのであって、ソーステーブルそのものをスキャンするのではないということです。これは、増分リフレッシュは変更されたソースデータの量に比例した作業のみを行うべきだという誤解を招きかねませんが、そうではありません。実際には、増分リフレッシュはソーステーブルを直接スキャンする必要があります。

例えば、テーブルAとテーブルBの間に内部結合を行うクエリがあるとします。テーブルAに行が挿入されると、クエリの変更を計算するためにテーブルBと結合する必要があります。このAの1行がBの多くの行と結合する可能性があるため、ソースの変更が少なかったとしても、多くの作業が発生する可能性があります。

このような余分な作業は、様々な演算子で発生する可能性があります。増分リフレッシュは、新しいデータを処理し、すでに行われた作業をスキップします。特に複雑なクエリでは、何をスキップするかを決定するのに追加作業が必要になることがあり、 異なる演算子は、異なる方法で作業をスキップすることができます。

通常、変更のサイズと局所性は、どの程度作業をスキップできるかに影響します。

サイズが増分リフレッシュのパフォーマンスに与える影響¶

増分リフレッシュのパフォーマンスに影響を与える最も重要な要因は、ソースデータの変更サイズです。動的なテーブルリフレッシュの変更サイズを決定する際には、コピーされた行もカウントするようにしてください。マイクロパーティション内のいくつかの行を変更するDMLも、そのマイクロパーティション内の変更されていない行を新しいマイクロパーティションにコピーします。

ベーステーブルで、変更された行の数を分析するには、ベーステーブル上で最後のリフレッシュ時に ストリームを作成 し、 SYSTEM$STREAM_BACKLOG を使用します。例:

CREATE STREAM mystream ON TABLE mybasetable BEFORE(STATEMENT => 'last refresh UUID');

SELECT * FROM SYSTEM$STREAM_BACKLOG('mystream');

極端な例として、ソースからすべてのデータを削除した場合の影響を考えてみましょう。フルリフレッシュでは空のテーブルが表示されるだけで、非常に短時間で処理できます。一方、増分リフレッシュでは、削除された行をすべて処理しなければならず、処理速度が大幅に低下します。

同様の減速は、それほど極端でないケースでも発生します。良好なワークロードのガイドラインは、ソースまたはターゲットの変更を行の5%未満に抑えることです。

局所性が増分リフレッシュのパフォーマンスに与える影響¶

増分リフレッシュに影響を与える2番目に重要な要因は、 局所性 です。これは、異なるディメンションに沿って、データやアクションがどれだけ密接に関連しているかを意味します。

例えば、タイムスタンプ列を持つテーブルがあり、常にその列に現在時刻を持つ行を挿入する場合、ワークロードは挿入順序とタイムスタンプ列の間に強い局所性を持ちます。

局所性は様々な形で現れますが、増分リフレッシュにとって特に重要なものがいくつかあります。以下の3つのカテゴリーすべてで強力な局所性を確保できるとは限りませんが、いずれかの分野で局所性を向上させると、増分リフレッシュのパフォーマンスが向上します。

各演算子の増分リフレッシュに対するパフォーマンス期待内容¶

次のテーブルは、各演算子の増分リフレッシュのおおよその期待されるパフォーマンスを示しています。パフォーマンスは、行の5%のみが変更され、リフレッシュジョブに少なくとも1分かかると仮定して、フルリフレッシュに対する相対値で測定されます。

局所性の影響を受ける演算子については、局所性が良い場合と悪い場合の期待パフォーマンスをテーブルに示しています。演算子によっては、局所性が悪いとフルリフレッシュよりもパフォーマンスが低下する場合があることに注意してください。

詳細については、 演算子が増分リフレッシュする方法 をご参照ください。

複雑な動的テーブルに対する増分リフレッシュモードのパフォーマンスの最適化¶

動的テーブルには通常複数の演算子が含まれているため、増分リフレッシュによるパフォーマンス予測が難しくなります。このセクションでは、この課題に対処する方法を検討し、複雑な動的テーブルのパフォーマンスを向上させるためのヒントを示します。

複数の演算子が関係する場合、増分リフレッシュは、各演算子を別々に処理することで変更を計算し、入力に基づいた変更を計算できるクエリプランの断片に変えます。各入力に対して、この新しい断片は、変更前の入力、変更後の入力、または変更そのものを要求することができます。元のクエリのすべての演算子にこの処理を適用することで、変更スキャンとフルテーブルスキャンを組み合わせて変更を計算する新しいクエリプランが得られます。このプランはSnowflakeのクエリオプティマイザーによって最適化され、他のクエリと同様に実行されます。

増分リフレッシュがうまくいかない場合、たいていは変更が多すぎるか、局所性が低いことが原因です。クエリが複雑な場合、これらの問題の特定がより困難になります。増分演算子の性能は、通常、変更量と入力の局所性に依存します。しかし、これらの入力は他の演算子の出力であるため、演算子を通過するにつれてデータの量や局所性が変化する可能性があります。

したがって、複雑な増分・リフレッシュのパフォーマンスを理解するには、各演算子の入力を個別に考慮する必要があります。ここでは、よくあるシナリオとその対処法をご紹介します。