Cortex Search Serviceのコストについて¶

コストカテゴリ¶

Cortex Search Serviceには以下のタイプのコストが発生します：

カテゴリ	説明
バーチャルウェアハウスコンピューティング	Cortex Search Serviceは、サービスをリフレッシュするために仮想ウェアハウスを必要とします。これは、テキスト埋め込みジョブのオーケストレーションや検索インデックスの構築など、初期化およびリフレッシュ時にベースオブジェクトに対してクエリを実行するためです。これらのオペレーションはコンピューティングリソースを使用しますが、これがクレジットを消費します。リフレッシュ中に変更が識別されなかった場合、リフレッシュする新しいデータがないため、仮想ウェアハウスクレジットは消費されません。
EMBED_TEXT トークン計算	Cortex Search Serviceは、 `ON` パラメーターで指定された検索列の各テキスト行を自動的にベクトル空間に埋め込み、セマンティック検索を可能にします。これは、埋め込まれたトークンごとにクレジットコストが発生します。これは、 EMBED_TEXT_768 、または EMBED_TEXT_1024 、各ドキュメントをその意味を符号化する一連の数字として変換するために呼び出すことを含みます。埋め込みは、行が挿入または更新されるたびに計算されます。埋め込みはソースクエリの評価の中で段階的に処理されるため、埋め込みコストは追加または変更された文書に対してのみ発生します。ベクター埋め込みコストに関する詳細については、ベクトル埋め込みをご参照ください。
使用中コンピュート	Cortex Search Serviceは、ユーザーが提供する仮想ウェアハウスとは別に、マルチテナントのサービングコンピュータを使用し、低レイテンシーで高スループットのサービスを確立します。このコンポーネントの計算コストは、 GB/月 (GB/月) の非圧縮インデックスデータあたりで発生します。インデックスデータとは、Cortex Searchソースクエリ内のユーザー提供データと、ユーザーに代わって計算されたベクトル埋め込みです。クエリに応答するためにサービスが利用可能である間、一定の期間にクエリが提供されなかった場合でも、これらのコストが発生します。インデックスされたデータ GB/月あたりのCortex Search Servingクレジットレートについては、 Snowflake Service Consumption Table をご参照ください。
ストレージ	Cortex Search Serviceは、ソースクエリをお客様のアカウントに保存されているテーブルに実体化します。このテーブルは、低レイテンシ配信に最適化されたデータ構造に変換され、お客様のアカウントにも保存されます。テーブルと中間データ構造のストレージは、1テラバイトあたりの定額制（TB）基づいています。
クラウドサービスコンピュート	Cortex Search Servicesは、 Cloud Servicesのコンピュートを使用して、基になるオブジェクトの変更と、仮想ウェアハウスを呼び出す必要があるかどうかを識別します。クラウドサービスのコンピューティングコストには、日次クラウドサービスコストがアカウントの日次ウェアハウスコストの10%より大きい場合にのみ、Snowflakeによって請求されるという制約が適用されます。

このトピックでは、これらのコストに関する情報と、これらのコストを効果的に管理するための推奨事項を提供します。

インデックス作成コストの管理¶

Cortex Search Serviceのインデックスコストを管理する上で、以下のヒントが役に立つでしょう：

ウェアハウスの最小化: ほとんどのサービスでは、 LARGE ウェアハウス以上のインデックスパフォーマンスの向上は見られず、多くのサービスでは MEDIUM だけが必要です。インデックスを構築する際に使用される計算時間のほとんどは、テキスト埋め込み関数によって消費されます。すでに十分なリソースがある場合、コア数を増やしたりメモリを追加したりしても、その恩恵は受けられません。
鮮度が重要でない場合はインデックス作成を一時停止: ドキュメントの変更を即座に検索サービスに反映させる必要がない場合（つまり、ある期間において鮮度がそれほど重要でない場合）は、インデックス作成を一時停止します（またはターゲットラグを増やします）。
ビジネス要件に応じたターゲット・ラグのセット: すべての検索アプリケーションがリアルタイムインデックスを必要とするわけではありません。ターゲット・ラグが低すぎると、インデックスが必要以上に頻繁に更新される可能性があります。例えば、ソースデータは5分ごとに更新されるが、データのコンシューマーは検索サービスに1時間に1回しかクエリしない場合、ターゲットラグは5分ではなく1時間にセットします。
変更をバンドルする: アップデートのコストには固定要素があるため、より頻繁で小規模なアップデートよりも、より少量で大規模なアップデートの方がコストは低くなります。同様に、行内の値に変更があると、その行の検索列がトリガーされ、その検索列内のデータが変更されていなくても、再度組み込まれます。そのため、単一のアップデートを1行に全ての変更を収集する方が良いです。
ソースデータへの変更を最小化: ソースクエリのスキーマを変更すると、ベクトル埋め込みとインデックスを含むサービスの完全なリフレッシュが行われます。大容量のサービスを作成する場合、後で使用するために追加のペイロード列を含めることを検討してください。そうすれば、列を追加する必要があるときにスキーマを変更して完全なリフレッシュをトリガーする必要がなくなります。追加列のコストは低いです。

Tip

CREATE OR REPLACE コマンドでソース・クエリのテーブル内のデータをマテリアライズすると、サービスはすべてのベクターを完全にリフレッシュして再エンベッドします。ソース・テーブルをインクリメンタルに更新する方が良いでしょう (例えば、 MERGE INTO) 。
ソースクエリはできるだけシンプルにします: 結合やその他の複雑な演算は、インデックス作成コストを増加させます (ETL または別のステージで適用したほうがよいかもしれません)。パイプラインの最適化に関する詳細情報は、Dynamic Tables Best Practices を参照してください。

コスト管理¶

Cortex Search Serviceのサービスコストを管理する上で、以下のヒントが役に立つかもしれません：

クエリに対応していない場合は、サービングを一時停止します。: 実行中の検索サービスは、クエリに対応していなくてもコストが発生します。開発中など不要な場合は、サービスを一時停止してください。通常、停止したサービスを再開するには数分しかかかりません。

コスト観察¶

Cortex Searchサービスのコストについては、以下の Account Usage 表示をご利用ください。

CORTEX_SEARCH_DAILY_USAGE_HISTORY ビューには、サービスごとの EMBED_TEXT トークン計算とサービングクレジットの計算使用状況の日ごとの合計が含まれています。Snowflakeは将来、この表示で仮想ウェアハウスの使用も提供する予定です。
CORTEX_SEARCH_SERVING_USAGE_HISTORY ビュー 1時間あたりのサービスクレジットを含みます。

Snowflakeは、将来的にこの情報をCortex Searchの管理インターフェイスで利用できるようにする予定です。

コストの見積もり¶

EMBED_TEXT トークン計算¶

EMBED_TEXT トークンの計算は、選択された埋め込みモデルのクレジットレートのコストに課金され、ドキュメントごとに、検索列のテキストのトークンごとに課金されます。この計算コストは、 ON 列の各行を含む、挿入または更新される各行に対して、サービスの初期化時およびそれ以降の挿入または更新のたびに発生します。各埋め込みモデルのトークンあたりのコストに関する情報は、 Cortex Search Embedding Models を参照してください。

例えば、1,000万行のソースクエリにサービスを作成し、それぞれが500トークンで、選択されたエンベッディングモデルで100万トークンあたり0.05クレジットが発生する場合、最初のリフレッシュには次のような費用がかかると考えられます。

(100万トークンあたり0.05クレジット) * (10,000,000行) * (1行あたり500トークン) / (1,000,000トークン)

= 250クレジット

その後、行が挿入または更新されるたびに、100万トークンあたり0.05クレジットのコストが発生します。

Tip

近似値として、1トークンは英単語の約3/4、つまり約4文字に相当します。行あたりのトークンの正確な推定値を得るには、実際のデータの代表的なサンプルで COUNT_TOKENS 関数を使用します。

使用中コンピュート¶

インデックスされたデータとは、Cortex Searchのソースクエリに含まれるユーザープロバイダーのデータと、ユーザーに代わって計算されたベクトル埋め込みデータです。これは、サービスの提供が再開されるまでの間、継続的に発生するコストです。このコストは、インデックスされる行数、インデックスされるデータ全体のサイズ、選択されたベクトル埋め込みモデルの次元数に基づいています。各埋め込みモデルの次元に関する情報については、 Cortex Search Embedding Models を参照してください。

例えば、1,000万行のサービスがあり、選択されたエンベッディングモデルのディメンションが768、ソースクエリの各行が約1,000バイト（検索列を含む）、インデックスされたデータの GB/月あたりのクレジットコストが6.3である場合、1ヶ月あたりのコストは以下のようになります。

(GB あたり6.3クレジット) * (10,000,000行) * (768次元 * 次元あたり4バイト＋行あたり1,000バイト) / (1,000,000,000バイト /GB)

= 256.5クレジット/月

注釈

1行あたりのデータサイズは、大文字と小文字によって異なり、列が検索列や属性列として指定されているかにかかわらず、サービスによってインデックスされるデータ量（行と列の数）に応じて増加します。

ウェアハウス・コンピュート¶

Cortex Search Serviceのバーチャルウェアハウス計算コストは、データの変化率、ターゲットラグ、ウェアハウスサイズによって異なります。一般的に、ターゲットラグ値が低く、基になるデータの変更率が高いCortex Search Serviceは、ウェアハウス関連の計算コストが高くなります。

Tip

Cortex Searchパイプラインに関連するウェアハウスのコストを明確に理解するには、専用ウェアハウスを使用してCortex Searchをテストし、Cortex Searchのリフレッシュに起因する仮想ウェアハウスの消費を分離できるようにします。Cortex Search Serviceを共有ウェアハウスに移動するのは、コストベースラインを確立した後でも可能です。

ストレージ¶

Cortex Search Serviceは、検索インデックスと同様に、ソースクエリのマテリアライズされた結果を格納するストレージを必要とします。保存されるデータのサイズは、 CORTEX_SEARCH_DATA_SCAN テーブル関数を使用してソースクエリをテーブルに実体化し、そのテーブルのサイズを調べることで推定できます。

このストレージがどのようにコストを発生させるかについての詳細情報は、ストレージコストについてを参照してください。

クラウドサービス¶

Cortex Search Serviceはクラウドサービスの計算を使用して、基になるベースオブジェクトが変更されたときにリフレッシュをトリガーします。これらのコストは、データの変化率、ターゲットラグ、ウェアハウスサイズによって異なります。Cortex Searchの変更追跡のためのクラウドサービスのコストは、変更率が低いユースケースほど低くなる傾向があります。クラウドサービスのコンピューティングコストには、日次クラウドサービスコストがアカウントの日次ウェアハウスコストの10%より大きい場合にのみ、Snowflakeによって請求されるという制約が適用されます。