Snowflakeにおけるクエリ性能の向上と関連コストの改善

Improving Query Performance and Reducing Related Costs in Snowflake

前回の記事では、Snowflake WarehouseとTablesを最適に使用する方法を理解しました。

このブログシリーズを続けて、今回はSnowflakeのパフォーマンスと関連するコストの改善に焦点を当てます。

Snowflakeのテーブルはマイクロパーティション化されているため、クエリのパフォーマンスが大幅に向上します。ただし、時間が経つと、大規模なデータセットでのDML操作の増加によりクエリの遅延が発生することがあります。

そのような場合は、テーブルをクラスタ化するか、検索最適化サービスを使用してパフォーマンスを向上させることができます。どちらのオプションを選択するかを決定する前に、それらが最も有益である特定のユースケースと関連するコストインパクトを考慮する必要があります。そうしないと、最適化が少なくなり、メンテナンスコストが高くなる可能性があります。

• 機械学習において決定木とランダムフォレストを使い分けるタイミング
• AIOpsの力を解き放つ：最適化されたITオペレーションのための知的自動化によるDevOpsの強化
• AIのマスタリング：プロンプトエンジニアリングソリューションの力

Snowflakeでのクラスタリング

Snowflakeでのクラスタリングは、ビッグデータ用語でのパーティショニングとは混同してはいけません。

Snowflakeでのクラスタリングは、マイクロパーティションをまだ管理していますが、挿入されたデータの順序ではなく、定義されたクラスタリングキーの順序で管理します。これによりパフォーマンスが向上します。定義されたクラスタリングキー値に対してマイクロパーティションスキャンが少なくなります。

テーブルに対してクラスタリングを選択する場合は、次のことを考慮してください。

• テーブルに複数のテラバイト（TB）のデータが含まれている場合、更新と削除が多すぎるため、時間の経過とともにテーブルのパフォーマンスが低下します。
• クラスタリングキーには、最大で3〜4つのクラスタリング列を使用することをお勧めします。それ以上は、大きな影響はありません。
• フィルターで最も使用される列、最もアクティブに使用される結合述語、使用されるORDER BY、GROUP BY句の順に列をクラスタリングします。
• 次のものを持つクラスタリングキーカラムを使用します。
  • テーブルで効果的なプルーニングを可能にする十分に大きな値の異なる数。
  • Snowflakeが同じマイクロパーティションに行を効果的にグループ化できる十分に小さな値の異なる数。
• 列をカーディナリティが最も低いものから最も高いものの順に並べます。
• 高カーディナリティの列をクラスタリングに使用する必要がある場合は、列そのものではなく、列上の式としてキーを定義して、異なる値の数を減らすことができます。

再クラスタリングに関連するコスト

既存のテーブルをクラスタ化する場合：

• 元のマイクロパーティションは削除されますが、Time TravelとFail-safeを可能にするためにシステムに保持されます。Time TravelとFail-safe後にのみ削除されます。
• 新しいマイクロパーティションは、以前のパーティションと同じサイズで作成されます。したがって、古いパーティションと新しいパーティションの維持には追加コストがかかります。

例:再クラスタリング前に、テーブルサイズが100 GBで、1日あたり2 GBが追加され、1 GBが削除されるとします。その後、オリジナルのテーブルは101 GBになり、その日のTime Travelサイズは2 GBになります。しかし、再クラスタリング後、オリジナルはクラスターキーに従って依然として101 GBのアクティブなパーティションを保持し、Time Travelは古いマイクロパーティションに従って100 GBのデータを保持します。この100 GBのTime Travelデータは、Fail-safeゾーンに移動されるまで保持されます。

• クラスタリングは常に自己管理型のSnowflake Warehouseで自動再クラスタリングコストが発生し、関連するコストも考慮する必要があります。

検索最適化クエリサービス

クラスタリングは、クラスタ化されていない列のパフォーマンス向上を保証しません。

クラスタ化されていない列の頻繁なクエリがあり、コストに関係なくパフォーマンスが重要な場合は、特定の列またはテーブル全体に対して検索最適化サービスを選択してください。

これは、OracleなどのRDBMSデータベースで特定の列にインデックスを有効にするのと似ています。

検索最適化クエリのコストインパクト

ストレージリソース

検索最適化サービスは、検索最適化が有効になっている各テーブルに対してスペースを必要とする検索アクセスパスデータ構造を作成します。

検索アクセスパスのストレージコストは、複数の要因に依存します。

• テーブル内の異なる値の数。
• すべての列が検索アクセスパスを使用するデータ型を持ち、各列のすべてのデータ値が一意である場合、必要なストレージは元のテーブルのサイズと同じになります。
• 通常は、サイズは元のテーブルのサイズの約1/4です。

コンピュートリソース

• 高いチャーン率の場合、リソース消費量が高くなります。
• これらのコストは、テーブルに追加または変更されたデータの量とテーブルの異なる値の数にほぼ比例します。
• 削除にもある程度のコストがかかります。
• 自動クラスタリングは、検索最適化を行ったテーブルのクエリのレイテンシを改善する一方で、検索最適化のメンテナンスコストをさらに増加させる可能性があります。
• SYSTEM$ESTIMATE_SEARCH_OPTIMIZATION_COSTS 関数を使用して、テーブルに検索最適化を追加するコストを見積もります。

検索最適化を使用しながらコストを削減するには

• 削除を少なく行ってください。
• INSERT、UPDATE、およびMERGE：これらのDMLステートメントをテーブルにバッチ処理すると、検索最適化サービスのメンテナンスコストが削減されます。
• テーブル全体を再クラスタリングする場合は、再クラスタリング前にそのテーブルのSEARCH OPTIMIZATIONプロパティを削除し、再クラスタリング後にSEARCH OPTIMIZATIONプロパティをテーブルに追加することを検討してください。

We will continue to update VoAGI; if you have any questions or suggestions, please contact us!