パフォーマンスに対するストレージの最適化¶

このトピックでは、類似したデータを一括りにした格納、最適化されたデータ構造の作成、特殊なデータセットの定義など、クエリのパフォーマンスを向上させるストレージの最適化について説明します。Snowflakeは、自動クラスタリング、検索最適化、マテリアライズドビューという3つのストレージ戦略を提供します。

一般に、これらのストレージ戦略では、すでに1秒以下で実行されるクエリのパフォーマンスは大幅には向上しません。

このトピックで説明する戦略は、クエリのパフォーマンスを向上させる1つの方法にすぎません。クエリの実行に使用されるコンピューティングリソースに関連する戦略については、パフォーマンスに対するウェアハウスの最適化をご参照ください。

ストレージ戦略の概要¶

自動クラスタリング¶

Snowflakeは、テーブルのデータをマイクロパーティションに格納します。これらのマイクロパーティションの中で、Snowflakeはデータの次元に基づいてデータを編成（つまり、クラスター）します。クエリがこれらのディメンションに沿ってフィルター、結合、または集計する場合は、結果を返すためにスキャンする必要があるマイクロパーティションの数を減らすと、クエリの速度が大幅に向上します。

クラスターキーを設定してマイクロパーティションのデフォルト構成を変更し、データが特定のディメンション（つまり、列）を中心にクラスタリングされるようにすることができます。クラスターキーを選択すると、クラスターキーで定義された列によってフィルター、結合、または集計を行うクエリのパフォーマンスが向上します。

Snowflakeでは、クラスターキーを定義するとすぐに自動クラスタリングが有効になり、テーブルのクラスタリングを維持できるようになります。自動クラスタリングを有効にすると、新しいデータがテーブルに追加されるときに、マイクロパーティションが更新されます。詳細

検索最適化サービス¶

検索最適化サービスにより、高度に選択的なフィルターを使用してテーブルから少数の行を返すポイントルックアップクエリ（つまり、「干し草の山から針を探す」）のパフォーマンスが向上します。検索最適化サービスは、低遅延のポイントルックアップクエリ（例: 調査ログ検索、脅威や異常の検出、選択フィルターを備えた重要なダッシュボード）が重要な場合に最適です。

検索最適化サービスは、特定の型の検索に最適化された永続的なデータ構造を構築することで、ポイントルックアップクエリの遅延を低減します。

検索最適化サービスは、テーブル全体または特定の列に対して有効にすることができます。選択性が十分である限り、これらの列に対する等価検索、部分文字列検索、および地域検索を大幅に高速化できます。

検索最適化サービスは、構造化データと半構造化データの両方をサポートします（サポートされるデータ型を参照）。

検索最適化サービスには、Snowflake Enterprise Edition以上が必要です。詳細

マテリアライズドビュー¶

マテリアライズドビューは、 SELECT ステートメントから派生した事前に計算されたデータセットであり、後で使用するために格納されます。データは事前に計算されているため、マテリアライズドビューのクエリは、ビューが定義されたベーステーブルに対してクエリを実行するよりも高速です。たとえば、マテリアライズドビューの作成時に SELECT SUM(column1) を指定すると、 column1 がすでに集計されているため、ビューから SUM(column1) を返すクエリの実行が速くなります。

マテリアライズドビューは、ベーステーブルに対して少数の行や列を返す、共通の繰り返しクエリパターンで構成されるワークロードのクエリパフォーマンスを向上させるように設計されています。

マテリアライズドビューは複数のテーブルに基づくことはできません。

マテリアライズドビューには、Snowflake Enterprise Edition以上が必要です。詳細

最適化戦略の選択¶

クエリの型が異なると、メリットの得られるストレージ戦略も異なります。次のセクションを使用して、ワークロードに最適な戦略を見つけることができます。

自動クラスタリングは、テーブルの同じ列にアクセスするさまざまなクエリにメリットをもたらす、最も広範なオプションです。管理者は多くの場合、頻度と遅延の要件に基づいて最も重要なクエリを選択し、それらのクエリのパフォーマンスを最大化するクラスターキーを選択します。自動クラスタリングは、多数のクエリが同じ少数の列をフィルター、結合、または集計する場合に意味があります。

検索最適化サービスとマテリアライズドビューのスコープは、より限定的です。特定のクエリがテーブルデータの明確に定義されたサブセットにアクセスする場合、管理者はクエリの特性を使用して、検索最適化サービスとマテリアライズドビューのどちらを使用するとパフォーマンスが向上するかを判断できます。たとえば、管理者は重要なポイントルックアップクエリを特定し、テーブルまたは列に検索最適化サービスを実装できます。同様に、管理者はマテリアライズドビューを作成することで、特定のクエリパターンを最適化できます。

1つのテーブルに対してこれらの戦略を複数実装でき、複数のフィルターを含む個別のクエリは、自動クラスタリングと検索最適化サービスの両方からメリットを受ける可能性があります。ただし、検索最適化サービスを有効にしたり、クラスター化テーブル上にマテリアライズドビューを作成したりすると、コストが高くなる可能性があります。これによりコンピューティングコストが増加する理由については、継続的コスト（このトピック内）をご参照ください。

複数の戦略によって特定のクエリのパフォーマンスが向上する可能性がある場合は、同様のアクセスパターンを持つ他のクエリも改善される可能性があるため、自動クラスタリングまたは検索最適化サービスから始めることをお勧めします。

差別化に関する考慮事項¶

以下は、ストレージ戦略の完全な比較ではなく、ストレージ戦略を区別する際の最も重要な考慮事項を示しています。

自動クラスタリング

最大のパフォーマンス向上は、クラスターキーの列をフィルター処理する WHERE 句によってもたらされますが、同じ列に作用する他の句や関数（例: 結合や集計）のパフォーマンスも向上させることができます。
範囲クエリまたは不等式フィルターを使用したクエリに最適です。等価フィルターも改善されますが、ポイントルックアップクエリでは通常、検索最適化サービスの方が高速です。
SnowflakeのStandard Editionで利用可能です。
クラスターキーは1つだけ存在できます。 ^[1] テーブルに対して異なるクエリが異なる列に作用する場合は、代わりに検索最適化サービスまたはマテリアライズドビューの使用を検討してください。

検索最適化サービス

少数の行 を返すポイントルックアップクエリを改善します。クエリが数個以上の記録を返す場合は、代わりに自動クラスタリングを検討してください。
次のようなポイントルックアップクエリのサポートが含まれます。
- LIKE や RLIKE などの述語を使用した、部分文字列または正規表現との一致。
- VARIANT、 ARRAY、または OBJECT 列内にある特定のフィールドの検索。
- GEOGRAPHY 値を持つ地理空間関数の使用。

マテリアライズドビュー

半構造化データの集計や分析など（フィルタリングだけでなく）、集中的で頻繁な計算を改善します。
通常は、特定のクエリ/サブクエリの計算に焦点を当てます。
外部テーブルに対するクエリを改善します。

^[1] 複数のクラスターキーを定義する重要な理由がある場合は、それぞれに独自のクラスターキーを持つ複数のマテリアライズドビューを作成できます。

プロトタイプクエリ¶

次の例は、特定のストレージ戦略で通常どの型のクエリがより高速に実行されるかを強調することを目的としています。

クラスタリング用プロトタイプクエリ

自動クラスタリングにより、大規模なテーブルスキャンを伴う 範囲クエリ のパフォーマンスが向上します。たとえば、次のクエリは WHERE 句が大量のデータをスキャンするため、 shipdate 列がテーブルのクラスターキーである場合により高速に実行されます。

SELECT
  SUM(quantity) AS sum_qty,
  SUM(extendedprice) AS sum_base_price,
  AVG(quantity) AS avg_qty,
  AVG(extendedprice) AS avg_price,
  COUNT(*) AS count_order
FROM lineitem
WHERE shipdate >= DATEADD(day, -90, to_date('2023-01-01));

Copy

テーブルがクラスター化されている場合に高速に実行される可能性があるクエリの追加の例については、クラスタリングキーを定義する利点（非常に大きなテーブルの場合）をご参照ください。

検索最適化用プロトタイプクエリ

検索最適化サービスは、大きなテーブルをスキャンして記録の小さなサブセットを返す ポイントルックアップクエリ のパフォーマンスを向上させることができます。たとえば、次のクエリは、 sender_ip 列に多数の個別の値がある場合に、検索最適化サービスを使用すると高速に実行されます。

SELECT error_message, receiver_ip
FROM logs
WHERE sender_ip IN ('198.2.2.1', '198.2.2.2');

Copy

検索最適化サービスを使用すると高速に実行される可能性のある他のクエリを確認するには、次の例をご参照ください。

マテリアライズドビュー用プロトタイプクエリ

マテリアライズドビューは、集計などの負荷の高い操作を使用してデータの小さなサブセットにアクセスするクエリのパフォーマンスを向上させることができます。例として、管理者がマテリアライズドビュー mv_view1 を作成するときに totalprice 列を集計したとします。マテリアライズドビューに対する次のクエリは、ベーステーブルに対するクエリよりも高速に実行されます。

SELECT
  orderdate,
  SUM(totalprice)
FROM mv_view1
GROUP BY 1;

Copy

マテリアライズドビューによってクエリを高速化できるその他のユースケースについては、マテリアライズドビューの使用例をご参照ください。

実装およびコストの考慮事項¶

このセクションでは、ストレージ戦略を使用してクエリのパフォーマンスを向上させる場合のコストの考慮事項と、コストとパフォーマンスのバランスをとる際の実装の考慮事項について説明します。

初期投資¶

ストレージ戦略の実装には、他のタイプのパフォーマンス最適化（例: SQL ステートメントの書き換えや、クエリを実行するウェアハウスの最適化）よりも長い時間のコミットメントと事前の金銭的投資が必要になる可能性がありますが、パフォーマンスの大幅な向上が見込めます。

Snowflakeは、サーバーレスコンピューティングリソースを使用して各ストレージ戦略を実装します。そのため、最適化によってパフォーマンスがどの程度向上するかをテストする前にクレジットが消費されます。さらに、Snowflakeが自動クラスタリングと検索最適化サービスを完全に実装するには、かなりの時間がかかる場合があります（例: 非常に大きなテーブルの場合は1週間）。

検索最適化サービスとマテリアライズドビューにはEnterprise Edition以上が必要なため、クレジットの価格も高くなります。

継続的コスト¶

ストレージ戦略では、コンピューティングコストとストレージコストの両方が発生します。

コンピューティングコスト

Snowflakeは、サーバーレスコンピューティングリソースを使用して、新しいデータがテーブルに追加されるときにストレージの最適化を維持します。テーブルへの変更が増えるほど、メンテナンスコストが高くなります。テーブルが常に更新される場合は、ストレージの最適化を維持するコストが異常に高くなる可能性があります。

基になるテーブルに対して自動クラスタリングが有効になっている場合は、マテリアライズドビューまたは検索最適化サービスを維持するコストが膨大になる可能性があります。自動クラスタリングを使用すると、Snowflakeはクラスターキーのディメンションに基づいてマイクロパーティションを常に再クラスタリングします。ベーステーブルが再クラスター化されるたびに、Snowflakeはサーバーレスコンピューティングリソースを使用して、マテリアライズドビューと検索最適化サービスによって使用されるストレージを更新する必要があります。その結果、ベーステーブルの自動クラスタリングアクティビティによって、ベーステーブルの DML コマンドのコストを超える、マテリアライズドビューと検索最適化サービスのメンテナンスコストがトリガーされる可能性があります。

ストレージコスト

自動クラスタリング: 検索最適化サービスやマテリアライズドビューとは異なり、自動クラスタリングは追加のストレージを作成するのではなく、既存のデータを再編成します。ただし、再クラスタリングにより Fail-safe ストレージのサイズが増加した場合は、追加のストレージコストが発生する可能性があります。詳細については、再クラスタリングのクレジットおよびストレージへの影響をご参照ください。
検索最適化/マテリアライズドビュー: マテリアライズドビューと検索最適化サービスには追加ストレージのコストが発生し、標準料金で請求されます。

コストの見積もり¶

検索最適化サービス: SYSTEM$ESTIMATE_SEARCH_OPTIMIZATION_COSTS 関数を実行すると、検索最適化サービスを列またはテーブル全体に追加するためのコストの見積もりに役立ちます。コストの見積もりは、有効になる列の数とテーブルが最近変更された量に比例します。

実装戦略¶

ストレージ戦略のコンピューティングコストとストレージコストは膨大になる可能性があるため、より大規模な実装に取り組む前に、小規模から始めて初期コストと継続的コストを注意深く追跡することをお勧めします。たとえば、1つまたは2つのテーブルのみにクラスターキーを選択し、他のテーブルのキーを選択する前にコストを評価することができます。

ストレージ戦略に関連する継続的コストを追跡するときには、仮想ウェアハウスはクエリの実行中にのみクレジットを消費するために、クエリが高速になると実行コストが少なくなることに注意してください。Snowflakeは、コスト評価に織り込むことができるように、ストレージの最適化前のクエリ実行コストを慎重にレポートし、ストレージの最適化後に同じクエリの実行コストと比較することをお勧めします。