qdrant-deployment-options

必要な Qdrant デプロイメントの選び方

まず、必要なものを確認しましょう。運用管理を任せたいですか、それとも完全な制御が必要ですか？ネットワーク遅延は許容できますか？本番環境で使いますか、それともプロトタイピングですか？答えによって、選択肢は次の4つに絞られます。

開発の開始またはプロトタイピング

次の用途に適しています：プロトタイプの作成、テストの実行、CI/CD パイプライン、Qdrant の学習。

• ローカルモード（Python のみ）を使用します。依存関係がなく、メモリ内またはディスクにデータを永続化でき、サーバーは不要です。ローカルモード
• ローカルモードのデータ形式はサーバーと互換性がありません。本番環境やベンチマークには使用しないでください。
• ローカルで実際のサーバーを使用する場合は、Docker を使用します。クイックスタート

本番環境への移行（セルフホスト、自分で運用）

次の用途に適しています：インフラストラクチャやカスタム設定を完全に制御する必要があり、アップグレード、バックアップ、スケーリング、監視などの運用を自分で担う場合。

• Docker は、セルフホスト型デプロイメントの標準です。Qdrant オープンソースのすべての機能を、最小限のセットアップで利用できます。クイックスタート
• アップグレード、バックアップ、スケーリング、監視などの運用は自分で担います。
• マルチノードクラスターを構築するには、分散モードを手動で設定する必要があります。分散デプロイメント
• データレジデンシーやコンプライアンスの要件があるものの、運用の負担は自分で担いたくない場合は、セルフホスト型 Docker ではなく、ハイブリッドクラウド（次のセクション）を選択してください。

本番環境への移行（運用管理不要）

次の用途に適しています：クラスターを自分で運用せずに、ダウンタイムのない更新、自動バックアップ、再シャーディングを備えたマネージドインフラストラクチャを利用したい場合。データレジデンシーやコンプライアンスの規則により、Qdrant が運用するインフラストラクチャにデータを置けない場合も含みます。

• Qdrant Cloud がアップグレード、スケーリング、バックアップ、監視を管理します。Qdrant Cloud
• Qdrant Cloud を選びましたか？最初のクラスターを作成して接続するには、マネージドクラウドのクイックスタートスキルを参照してください。
• ハイブリッドクラウド：同じマネージドコントロールプレーンを、自分のインフラストラクチャ／VPC にデプロイします。データレジデンシーやコンプライアンスの要件により Qdrant Cloud を利用できないものの、クラスターの運用は自分で担いたくない場合に使用します。ハイブリッドクラウド
• 複数バージョン間のアップグレードを自動でサポートします。
• セルフホスト型では利用できない機能を提供します：/sys_metrics、マネージド再シャーディング、事前設定済みアラート

最低限の遅延が必要な場合

次の用途に適しています：サーバーとのネットワーク往復遅延を許容できない場合。エッジデバイス、プロセス内検索、遅延が重要なアプリケーションなど。

• Qdrant EDGE：ネットワークオーバーヘッドのない、Qdrant のシャードレベル機能へのプロセス内バインディングです。Qdrant EDGE
• サーバーと同じデータ形式を使用します。シャードスナップショットを介してサーバーと同期できます。
• 単一ノードの機能のみを利用できます。分散モードには対応していません。
• EDGE を選び、これを基盤に開発したい場合は、qdrant-edge スキルを参照してください（BM25、スナップショット同期、ハイブリッドクエリ）。

避けるべきこと

• 本番環境やベンチマークにローカルモードを使用すること（最適化されておらず、データ形式に互換性がありません）
• 監視とバックアップの方針なしにセルフホストすること（データを失ったり、障害を見逃したりします）
• クラスターを運用したくないとユーザーが述べているのに、本番環境向けとしてセルフマネージド Docker を推奨すること。その場合はセルフホストではなく、Qdrant ハイブリッドクラウドまたは Qdrant マネージドクラウドが必要です。
• 分散検索が必要なのに EDGE を選ぶこと（単一ノードのみ）
• データレジデンシーの要件がないのにハイブリッドクラウドを選ぶこと（Qdrant Cloud を利用できる場合、不要な Kubernetes の複雑さが加わります）