qdrant-deployment-options

--- Guides de sélection du déploiement Qdrant. À utiliser quand quelqu'un demande « comment déployer Qdrant », « Docker vs Cloud », « mode local », « Qdrant intégré », « Qdrant EDGE », « quelle option de déploiement », « auto-hébergé vs cloud », ou « avoir le déploiement avec la plus faible latence ». À utiliser également pour choisir entre les types de déploiement pour un nouveau projet.

npx skills add https://github.com/qdrant/skills --skill qdrant-deployment-options

Quel déploiement Qdrant me faut-il ?

Commencez par ce dont vous avez besoin : des opérations gérées ou un contrôle total ? Une latence réseau acceptable ou non ? Production ou prototypage ? La réponse se réduit à l'une des quatre options.

Démarrer ou faire du prototypage

À utiliser quand : vous construisez un prototype, exécutez des tests, des pipelines CI/CD, ou apprenez Qdrant.

  • Utilisez le mode local (Python uniquement) : zéro dépendance, en mémoire ou persisté sur disque, aucun serveur nécessaire Local mode
  • Le format de données du mode local N'EST PAS compatible avec le serveur. Ne l'utilisez pas pour la production ou les benchmarks.
  • Pour un vrai serveur en local, utilisez Docker Quick start

Passage en production (auto-hébergé)

À utiliser quand : vous avez besoin d'un contrôle total sur l'infrastructure, la résidence des données, ou une configuration personnalisée.

  • Docker est le déploiement par défaut. Ensemble complet des fonctionnalités Qdrant Open Source, setup minimal. Quick start
  • Vous gérez les opérations : mises à jour, sauvegardes, scaling, monitoring
  • Vous devez configurer manuellement le mode distribué pour les clusters multi-nœuds Distributed deployment
  • Considérez Hybrid Cloud si vous voulez la gestion Qdrant Cloud sur votre infrastructure Hybrid Cloud

Passage en production (Zéro opérations)

À utiliser quand : vous voulez une infrastructure gérée avec des mises à jour sans temps d'arrêt, des sauvegardes automatiques, et du resharding sans exploiter vous-même les clusters.

  • Qdrant Cloud gère les mises à jour, le scaling, les sauvegardes, et le monitoring Qdrant Cloud
  • Supporte automatiquement les mises à niveau multi-versions
  • Fournit des fonctionnalités non disponibles en auto-hébergé : /sys_metrics, resharding géré, alertes pré-configurées

Besoin de la latence la plus faible possible

À utiliser quand : la latence réseau round-trip vers un serveur est inacceptable. Appareils edge, recherche in-process, ou applications critiques en latence.

  • Qdrant EDGE : liaisons in-process aux fonctions de shards Qdrant, pas de surcharge réseau Qdrant EDGE
  • Même format de données que le serveur. Peut se synchroniser avec le serveur via des snapshots de shards.
  • Ensemble de fonctionnalités mono-nœud uniquement. Pas de mode distribué.

Ce qu'il NE FAUT PAS faire

  • Utiliser le mode local pour la production ou les benchmarks (non optimisé, format de données incompatible)
  • Auto-héberger sans stratégie de monitoring et de sauvegarde (vous perdrez des données ou manquerez des pannes)
  • Choisir EDGE quand vous avez besoin de recherche distribuée (mono-nœud uniquement)
  • Choisir Hybrid Cloud sauf si vous avez des exigences de résidence des données (complexité Kubernetes inutile quand Qdrant Cloud fonctionne)