検索最適化のコスト見積もりおよび管理

検索最適化サービスは、ストレージリソースとコンピューティングリソースの両方のコストに影響します。

  • ストレージリソース:検索最適化サービスにより、検索アクセスパスデータ構造を作成します。この構造には、検索最適化が有効になっている各テーブルにスペースが必要です。検索アクセスパスのストレージコストは、次のような複数の要因によって異なります。

    • テーブル内における個別の値の数。すべての列に検索アクセスパスを使用するデータ型があり、各列のすべてのデータ値が一意であるという極端な場合、必要なストレージは元のテーブルのサイズと同じ程度の大きさになる可能性があります。

      ただし、通常、サイズは元のテーブルのサイズの約1/4です。

  • コンピューティングリソース:

    • テーブルに検索最適化を追加すると、最初のビルドフェーズ中にリソースが消費されます。

    • 検索最適化サービスを維持するには、リソースも必要です。チャーンが多い場合(つまり、テーブル内で大量のデータが変更される場合)は、リソースの消費量が多くなります。これらのコストは、取り込まれた(追加または変更された)データの量にほぼ比例します。削除にもいくらかのコストがかかります。

      自動クラスタリング は、検索最適化を使用してテーブル内のクエリの遅延を改善できますが、検索最適化のメンテナンスコストをさらに増加させる可能性があります。テーブルのチャーンレートが高い場合は、自動クラスタリングを有効にしてテーブルの検索最適化を構成すると、テーブルが検索最適化用に構成されている場合よりもメンテナンスコストが高くなる可能性があります。

      Snowflakeは、実際に使用されたリソースに対してのみアカウントに請求することにより、効率的なクレジット使用状況を確保します。請求は1秒単位で計算されます。

      コンピューティング時間あたりのコストについては、 Snowflakeサービス利用テーブル の「サーバーレス機能クレジットテーブル」をご参照ください。

      検索最適化サービスを有効にすると、 サービスの使用料金を表示 できます。

Tip

Snowflakeは、この機能を徐々に始めて(最初は検索最適化をいくつかのテーブルのみに追加するなど)、コストと利点を注意深く監視することをお勧めします。

検索最適化のコスト見積もり

テーブルに検索最適化を追加し、検索最適化のために特定の列を構成するためのコストを見積もるには、 SYSTEM$ESTIMATE_SEARCH_OPTIMIZATION_COSTS 関数を使用します。

一般的に、コストは次の要素に比例します。

  • この機能が有効になっている列の数、およびそれらの列内にある個別の値の数。

  • これらのテーブルで変更されるデータの量。

重要

SYSTEM$ESTIMATE_SEARCH_OPTIMIZATION_COSTS 関数によって返されるコストの見積もりはベストエフォートです。実際の実現コストは、見積もられたコストとは最大50%(またはまれに数倍)異なる場合があります。

  • 構築およびストレージのコストの見積もりは、テーブル内にある行のサブセットのサンプリングに基づいています。

  • メンテナンスコストの見積もりは、テーブル内の最近の作成、削除、更新アクティビティに基づいています。

検索最適化のコスト表示

ウェブインターフェイスまたは SQL を使用して、検索最適化サービスの実際の請求コストを表示できます。 コンピューティングコストの調査 をご参照ください。

検索最適化のコスト削減

慎重に 検索最適化を有効にするテーブルおよび列を選択する ことにより、検索最適化サービスのコストを制御できます。

さらに、検索最適化サービスのコストを削減するには、

  • SnowflakeはテーブルでDML操作をバッチ処理することをお勧めします。

    • DELETE :テーブルに最新の期間(例:最新の日、週、月)のデータが保存されている場合は、古いデータを削除してテーブルをトリミングする際に、検索最適化サービスで変更を考慮する必要があります。場合によっては、削除の頻度を減らすことでコストを削減できる場合があります(例: 1時間ごとではなく1日ごと)。

    • INSERTUPDATE、および MERGE :これらのタイプの DML ステートメントをテーブルでバッチ処理すると、検索最適化サービスにより、メンテナンスのコストを削減できます。

  • テーブル全体を再クラスタリングする場合は、再クラスタリングの前にそのテーブルの SEARCH OPTIMIZATION プロパティをドロップ し、再クラスタリング後、テーブルに SEARCH OPTIMIZATION プロパティを追加 しなおすことを検討してください。

  • 部分文字列検索(ON SUBSTRING(col))または VARIANTs(ON EQUALITY(variant_col))の検索最適化を有効にする前に、 SYSTEM$ESTIMATE_SEARCH_OPTIMIZATION_COSTS を呼び出してコストを見積もります。これらの検索方法の最初のビルドとメンテナンスは計算集約型になる可能性があるため、パフォーマンスとコストの間のトレードオフを評価する必要があります。