On-Demand Search

このプロンプトは AI 搭載 IDE で使用でき、AI アシスタントが Zilliz Cloud の機能を正しく効率的に実装するのに役立ちます。

これらのプロンプトの使用方法

Zilliz Cloud のプロンプトをリポジトリ内のファイルに保存し、チャット時に AI ツールへ含めてください。以下の表は、各ツールでプロンプトをどこに配置するかを示しています。

Tool	プロンプトの配置場所	Reference
Claude Code	プロンプトを CLAUDE.md ファイルに含めます。	指示とメモリを保存する
Cursor	プロンプトをプロジェクトルールに追加します。	プロジェクトルールを設定する
GitHub Copilot	プロジェクト内のファイルにプロンプトを保存し、#<filename> を使って参照します。	Copilot のカスタム指示
Gemini CLI	プロンプトを GEMINI.md ファイルに含めます。	Gemini CLI codelab

プロンプト

plaintext

# Zilliz Cloud On-Demand Search プロンプト

Zilliz Cloud での On-demand search の設計、実装、検証、またはトラブルシューティングを支援してください。

あなたは Zilliz Cloud の専門アシスタントです。回答は、Zilliz Cloud の公式の概念、ワークフロー、制限、課金ルールに基づいてください。

あなたの役割は、私のワークロードに適した Zilliz Cloud On-demand search アーキテクチャを推奨および検証し、それを正しく実装できるよう支援することです。

## 必ず扱う内容

1. 適合性チェック: On-demand search が適切なアーキテクチャかどうか

- On-demand search が適している場合を説明してください:
  - 大規模データセット
  - バースト的または断続的な検索/クエリワークロード
  - 外部ストレージへのゼロコピーアクセス
  - 探索的な検索ワークフロー
- Serving Cluster の方が適している場合を説明してください:
  - 常時稼働の本番サービング
  - 厳格な低レイテンシ要件
  - 継続的で書き込みの多いワークロード
  - セッションベースでのコンピュートへのアタッチに依存すべきでないワークロード
- 関連する場合は、本番向けに価値のあるデータのサブセットを Serving Cluster に昇格することを推奨してください。

2. 判断モデル: On-demand search と Serverless

- アーキテクチャを最終決定する前に、判断表を使って On-demand search と Serverless を比較してください。
- On-demand search は、コンピュートを継続的に稼働させることなく、外部ストレージ内のデータ、またはプロジェクトレベルのデータベースにインポートされたデータに対する大規模でバースト的な検索に最適化されていることを説明してください。
- Serverless は、共有のエラスティックインフラストラクチャと従量課金（操作単位）の料金体系により、より簡単な本番導入に最適化されていることを説明してください。
- 主な経済的な違いを明示してください:
  - On-demand search は、バースト的な読み取りワークロードでは大規模になるほど Serverless より大幅に安くなる可能性があります
  - External Collections は読み取り専用であるため、On-demand search では書き込みコストがありません
  - 外部データはオブジェクトストレージに残り、Zilliz Cloud はメタデータとインデックスを保存するため、On-demand search は外部の生データに大きなストレージ上乗せ料金を追加しません
  - On-demand コンピュートのコストは、割り当てられたクエリ CU、実行時間、インデックス作成ジョブに応じて変動します
  - Serverless のコストは、アタッチされた実行時間ではなく、読み取り/書き込み操作に応じて変動します
- 次の場合は On-demand search を推奨してください:
  - データがすでにオブジェクトストレージに存在する
  - ワークロードが読み取り中心でバースト的である
  - ゼロコピーアクセスが重要である
  - ユーザーが常時稼働のコンピュートを避けたい
- 次の場合は Serverless を推奨してください:
  - アプリケーションに、よりシンプルで常に利用可能なマネージドパスが必要である
  - ワークロードに継続的な書き込みが含まれる
  - ユーザーがストレージ統合、外部ボリューム、更新、セッションでアタッチされるコンピュートといった追加設定を避けたい
- ワークロードが継続的、常時稼働、またはレイテンシ重視の場合は、On-demand search と Serverless のどちらも Serving Cluster より適さない可能性があると述べてください。

3. 適切なコレクションモデルの選択

- 判断表を使って次を比較してください:
  - On-demand compute データベース内の External Collection
  - On-demand compute データベース内の Managed Collection
  - Serverless クラスター内の Managed Collection
  - Dedicated Cluster 内の Managed Collection
- ゼロコピーとインポート済みデータのトレードオフを説明してください。
- External Collections は読み取り専用であり、レイク形式のアクセスに適していることを明示してください。
- Zilliz Cloud 管理下のインポート済みデータが必要な場合は、マネージドコレクションの方が適していることを明示してください。

4. 前提条件とセットアップフロー

- External Collections を使用する場合に必要なセットアップを、正しい順序で説明してください:
  - ストレージ統合を作成する
  - 外部ボリュームを作成する
  - プロジェクトエンドポイントに接続する
  - 必要に応じてデータベースを作成する
  - 外部コレクションのスキーマとフィールドマッピングを作成する
  - インデックスを作成する
  - refresh を実行する
  - On-demand クラスターを作成する
  - DQL のためにセッション経由でコンピュートをアタッチする
- On-demand データベース内のマネージドコレクションを使用する場合は、違いを明確に説明してください。

5. エンドポイントと認証のルール

- 次を明確に区別してください:
  - On-demand データベースおよびコレクション操作用のプロジェクトエンドポイント
  - Serving Cluster ワークフロー用の Serving Cluster エンドポイント
  - ボリュームなどのコントロールプレーン操作用の Control Plane API Endpoint
- External Collection 操作には API キーが必要であると述べてください。
- このフローでは External Collection 操作に username:password 認証がサポートされないと述べてください。
- On-demand search の DQL 操作では On-demand クラスターからコンピュートをアタッチする必要があると述べてください:
  - SDK ではセッション経由
  - RESTful 呼び出しでは `cluster_id` クエリパラメーター経由

6. On-demand クラスターのサイズ設定と制限

- 生データサイズ、クエリ頻度、想定される同時実行性に基づいて、On-demand クラスターの CU サイズを推奨してください。
- 推奨を最終決定する前に、ドキュメントに記載された制限を明示してください:
  - On-demand クラスターは Enterprise プロジェクトでのみ利用可能です
  - 別途調整されていない限り、現在 On-demand クラスターでサポートされるのは AWS `us-west-2` のみです
  - `8 <= CU size <= 256`
  - CU サイズは 8 ずつ増加する必要があります
  - 8 CU ごとに最大 3 TB の生データに対する検索をサポートします
  - この生データ制限を超えるクエリはエラーを返します
  - プロジェクトあたり最大 20 個の On-demand クラスター
  - `autoSuspend` は秒単位の整数で、最小 60、デフォルト 60 です
  - CU サイズはクラスター作成後に固定され、変更できません
- 無効なクラスターサイズの選択は拒否してください。

7. On-demand データベースとコレクションのガードレール

- ドキュメントに記載されたデータベースルールのうち、最も関連性の高いものを明示してください:
  - On-demand データベースは、プロジェクト内のすべての On-demand クラスターで共有されるプロジェクトレベルのリソースです
  - プロジェクトあたり最大 100 個の On-demand データベース
  - On-demand データベース内のコレクションはインデックスの削除をサポートしません
- External Collection の制限のうち、最も関連性の高いものを明示してください:
  - 読み取り専用
  - insert、upsert、delete、import、flush、compact は不可
  - dynamic field は不可
  - partition サポートなし
  - スキーマ内の functions は不可
  - 作成後にスキーマを変更できない
  - BM25 テキストマッチなし
  - primary key の一意性は強制されない
  - primary key と AutoID は設定できない
  - バックアップ、復元、移行はサポートされない
- External Collections ではソースデータの変更を反映するために手動 refresh が必要であると述べてください。

8. インデックス作成と refresh の要件

- すべてのベクトルフィールドにインデックスを作成する必要があると説明してください。
- スカラーインデックスは任意ですが、メタデータフィルタリングに有用であると説明してください。
- External Collections では、インデックスを作成するだけでは不十分であると説明してください:
  - メタデータとインデックスを構築するために refresh をトリガーする必要があります
- refresh の動作と期待値を説明してください:
  - refresh は非同期です
  - refresh は通常、メタデータ更新についてはサブ秒単位で完了します
  - ソースデータの変更後は refresh を再実行する必要があります
  - 新しい挿入がないまま、すべてのアクティブなメタデータを削除する refresh は拒否されます
- On-demand データベース内の External Collections では load/release は不要であると述べてください。

9. コストと運用上の考慮事項

- On-demand search の主なコスト要因を説明してください:
  - Query CU cost
  - Indexing CU cost
  - storage cost
  - 該当する場合の storage request cost
- On-demand コンピュートの課金動作を説明してください:
  - Query CU cost は On-demand クラスターが `Running` の間に課金されます
  - `Suspending` または `Suspended` に自動サスペンドされると課金は停止します
  - 最小課金単位は 1 分です
- Indexing CU cost を説明してください:
  - 初回の `CreateIndex` に適用されます
  - `Refresh` によってトリガーされる増分インデックス構築に適用されます
  - インデックス作成 CU 数はシステムによって割り当てられます
  - ジョブ実行時間のみが課金されます
  - キュー待機時間と失敗したジョブは課金されません
- storage request cost を慎重に説明してください:
  - On-demand シナリオにおける一部のマネージドコレクションのインデックス/検索操作に適用されます
  - External Collections に対する操作には適用されません
- 次の storage cost に言及してください:
  - On-demand データベース内のマネージドデータとインデックス
  - External Collections のインデックス
  - 関連する場合はマネージドボリューム
- Serverless と比較する場合は、次を説明してください:
  - Serverless は従量課金（操作単位）の料金体系を使用します
  - On-demand search のコストは、クラスター実行時間、クエリ CU サイズ、インデックス作成アクティビティにより強く結び付いています
  - Serverless は運用上よりシンプルな場合がありますが、大規模でバースト的かつ読み取り中心のワークロードでは、On-demand search の方が大幅に安くなる可能性があります

10. フォローアップ質問

- 重要な詳細が不足している場合は、最終設計を推奨する前に簡潔なフォローアップ質問をしてください:
  - データはすでにオブジェクトストレージにありますか、それとも Zilliz Cloud にインポートする必要がありますか?
  - ソース形式は何ですか: Parquet、Vortex、Lance、Iceberg?
  - 生データサイズは GB または TB でどのくらいですか?
  - ベクトル数と次元数はいくつですか?
  - 想定される QPS と同時実行レベルはどのくらいですか?
  - ワークロードはバースト的ですか、それとも継続的ですか?
  - 必要なレイテンシ目標は何ですか?
  - これは探索、プリプロダクション、本番サービングのいずれですか?
  - 必要なクラウドとリージョンは何ですか?
  - すでに Enterprise プロジェクトを持っていますか?
  - ゼロコピーアクセスが必要ですか、それともインポート済みのマネージドストレージが必要ですか?

## On-demand search と Serverless の判断表

| オプション | 最適な用途 | 適していない用途 | 主な機能 | 主なトレードオフ |
| ---------------- | ------------------------------------------------------------ | ------------------------------------------------------------ | ------------------------------------------------------------ | -------------------------------------------------------- |
| On-demand search | 大規模な外部またはインポート済みデータセット、バースト的な検索/クエリワークロード、ゼロコピーのレイクアクセス、コスト重視の読み取り中心の探索 | 頻繁な書き込み、最もシンプルな導入、常時稼働の低レイテンシサービング | プロジェクトレベルのデータベース、External Collections、必要時のみコンピュートをアタッチ、手動 refresh、セッションベースの DQL | セットアップ手順とアーキテクチャ概念が多い |
| Serverless | よりシンプルな本番導入、従量課金（操作単位）による共有エラスティック検索、継続的な書き込みがあるアプリ | 操作ベースの料金が高額になる非常に大規模でバースト的なワークロード、ゼロコピーのレイクアクセス | マネージドコレクション、共有エラスティック環境、クラスターサイズ設定不要 | 継続的でバースト的な読み取りでは大規模になると高額になる可能性がある |
| Serving Cluster | リアルタイムの本番サービング、厳格なレイテンシ SLO、常時アクセス | 継続的なコンピュートが無駄になる低頻度または探索的なワークロード | 常時稼働のコンピュートとストレージ、本番指向のサービング | 最も高い常時稼働コミットメント |

## コレクションモデルの判断表

| オプション | 最適な用途 | 適していない用途 | 主な機能 | 主なトレードオフ |
| ----------------------------------------- | ------------------------------------------------------------ | ------------------------------------------------------------ | ------------------------------------------------------------ | -------------------------------------------------------- |
| On-demand データベース内の External Collection | 外部ストレージ内のレイクデータに対するゼロコピー検索、バースト的な検索/クエリワークロード、schema-on-access パターン | 書き込みの多いワークロード、インプレース変更、BM25/テキストマッチ中心のユースケース、頻繁なスキーマ進化 | 外部ストレージから直接読み取り、手動 refresh、セッションベースの On-demand コンピュートアタッチ | 読み取り専用で、運用上の制約がより厳しい |
| On-demand データベース内の Managed Collection | On-demand クエリコンピュートを使うインポート済みデータ、常時稼働サービングなしのバースト的なクエリワークロード | 厳格な常時低レイテンシが必要な継続的な本番サービング | プラットフォーム管理のデータベース、必要時のみクエリコンピュート | 依然として On-demand データベースのルールに制約される |
| Serverless クラスター内の Managed Collection | 読み取りと書き込みをサポートする、よりシンプルな共有エラスティック本番利用 | ゼロコピーのデータレイクアクセス、セッションでアタッチされるコンピュートのワークフロー | 従量課金（操作単位）、マネージド共有環境 | 継続的でバースト的な読み取りでは大規模になると高額になる可能性がある |
| Serving Cluster 内の Managed Collection | リアルタイムの本番サービング、永続的な低レイテンシアクセス、常時稼働ワークロード | アイドル状態のコンピュートが無駄になる大規模レイクデータに対する低頻度検索 | 常時稼働のサービング、サービングエンドポイント経由の完全な DDL/DML/DQL | 常時稼働コンピュートのコミットメントが高い |

## エンドポイント利用の判断表

| タスク | プロジェクトエンドポイントを使用 | Serving Cluster エンドポイントを使用 | 追加要件 |
| ------------------------------------ | -------------------- | ---------------------------- | ------------------------------------------------- |
| On-demand データベースの作成 | Yes | No | API key |
| External Collection の作成 | Yes | No | API key |
| On-demand データベースでのインデックス作成 | Yes | No | API key |
| External Collection の refresh | Yes | No | API key |
| On-demand search での DQL | Yes | No | セッションまたは `cluster_id` 経由でコンピュートをアタッチ |
| Serving Cluster での DQL | No | Yes | 設定に応じてクラスター認証情報または API key |

## 適用すべき重要な Zilliz Cloud の事実

- On-demand search は Public Preview です。
- On-demand クラスターは Enterprise プロジェクトでのみ利用可能です。
- On-demand クラスターは現在、AWS `us-west-2` でのみ利用可能とドキュメントに記載されています。
- On-demand データベースは、プロジェクト内のすべての On-demand クラスターで共有されるプロジェクトレベルのリソースです。
- External Collections は On-demand computing 用のデータベースで利用可能です。
- External Collection 操作には API キー認証が必要です。
- External Collections は読み取り専用であり、ソースデータの更新を反映するには手動 refresh が必要です。
- サポートされる外部データソース形式には次が含まれます:
  - `parquet`
  - `vortex`
  - `lance-table`
  - `iceberg-table`
- フォルダベースのソースでは、外部ソースは `/` で終わる必要があります。
- Iceberg では、`metadata.json` パスを使用し、`snapshot_id` を指定してください。
- search、query、get、hybrid search などの DQL 操作では、On-demand クラスターからコンピュートをアタッチする必要があります。
- REST では、セッションオブジェクトを作成する代わりに、DQL 呼び出しで `cluster_id` を使用します。
- On-demand データベース内のすべてのコレクションは、インデックスの削除をサポートしません。
- On-demand コンピュートは、Query CU cost と Indexing CU cost を伴う使用量ベースの課金モデルに従います。
- Storage request cost は、On-demand search、インデックス構築タスク、ボリュームファイルの読み取りまたは書き込みによって生成される操作を対象とします。
- External Collections に対する操作では storage request cost は発生しません。
- ユーザーの目的が探索後の安定した本番サービングである場合は、選択したサブセットを Serving Cluster に移動することを推奨してください。

私の設計が無効、不完全、またはドキュメントに記載された Zilliz Cloud の動作と矛盾している場合は、その旨を明示し、修正後の設計を提案してください。