qdrant-deployment-options

どの Qdrant デプロイメントが必要ですか？

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

はじめて使う場合、またはプロトタイピング

次の場合に使用します：プロトタイプの構築、テストの実行、CI/CD パイプライン、または Qdrant の学習。

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

本番環境への移行（セルフホスト）

次の場合に使用します：インフラストラクチャ、データレジデンシー、またはカスタム構成を完全に制御する必要がある場合。

• Docker が標準のデプロイ方法です。Qdrant Open Source のすべての機能を利用でき、セットアップも最小限です。クイックスタート
• アップグレード、バックアップ、スケーリング、モニタリングなどの運用は自分で行います。
• マルチノードクラスターでは、分散モードを手動でセットアップする必要があります。分散デプロイメント
• 自社のインフラストラクチャ上で Qdrant Cloud の管理機能を利用したい場合は、Hybrid Cloud を検討してください。Hybrid Cloud

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

次の場合に使用します：自分でクラスターを運用せずに、ダウンタイムなしの更新、自動バックアップ、再シャーディングを備えたマネージドインフラストラクチャを利用したい場合。

• Qdrant Cloud がアップグレード、スケーリング、バックアップ、モニタリングを管理します。Qdrant Cloud
• 複数バージョンにまたがるアップグレードを自動でサポートします。
• セルフホストでは利用できない機能を提供します：/sys_metrics、マネージド再シャーディング、事前構成済みのアラート

可能な限り低いレイテンシが必要な場合

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

• Qdrant EDGE：Qdrant のシャードレベル機能へのプロセス内バインディングにより、ネットワークオーバーヘッドがありません。Qdrant EDGE
• サーバーと同じデータ形式を使用します。シャードスナップショットを介してサーバーと同期できます。
• 単一ノードの機能のみを利用できます。分散モードはありません。

避けるべきこと

• 本番環境やベンチマークにローカルモードを使用すること（最適化されておらず、データ形式に互換性がありません）
• モニタリングとバックアップ戦略なしでセルフホストすること（データを失ったり、障害を見逃したりする可能性があります）
• 分散検索が必要なのに EDGE を選ぶこと（単一ノードのみです）
• データレジデンシーの要件がないのに Hybrid Cloud を選ぶこと（Qdrant Cloud で対応できる場合、不要な Kubernetes の複雑さが生じます）