qdrant-vertical-scaling

Guides les décisions de mise à l'échelle verticale Qdrant. À utiliser quand quelqu'un demande « comment augmenter la taille d'un nœud », « besoin de plus de RAM », « augmenter la taille du nœud », « mise à l'échelle verticale », « redimensionner le cluster », « scale up vs scale out », ou quand la mémoire/CPU est insuffisante sur les nœuds actuels. À utiliser également quand quelqu'un veut éviter la complexité de la mise à l'échelle horizontale.

npx skills add https://github.com/qdrant/skills --skill qdrant-vertical-scaling

Que faire quand Qdrant doit se mettre à l'échelle verticalement

La mise à l'échelle verticale signifie augmenter le CPU, la RAM ou le disque sur les nœuds existants plutôt que d'ajouter plus de nœuds. C'est l'étape recommandée en premier avant de considérer une mise à l'échelle horizontale. La mise à l'échelle verticale est plus simple, évite la complexité des systèmes distribués et est réversible.

  • La mise à l'échelle verticale pour Qdrant Cloud se fait via la Qdrant Cloud Console
  • Pour les déploiements auto-hébergés, redimensionnez les ressources de la VM ou du conteneur sous-jacent

Quand mettre à l'échelle verticalement

À utiliser quand : les ressources du nœud actuel (RAM, CPU, disque) sont insuffisantes, mais la charge de travail ne nécessite pas encore de distribution.

  • L'utilisation de RAM approche 80 % de la mémoire disponible (l'éviction du cache de page du système d'exploitation commence, dégradation sévère des performances)
  • Saturation du CPU lors de la requête ou de l'indexation
  • L'espace disque s'épuise pour les vecteurs sur disque et les charges utiles
  • Un seul nœud peut gérer jusqu'à ~100M vecteurs selon les dimensions et la quantification
  • Pour les charges de travail non-production, qui tolèrent un point de défaillance unique et ne nécessitent pas une haute disponibilité

Comment mettre à l'échelle verticalement dans Qdrant Cloud

La mise à l'échelle verticale est gérée via la Qdrant Cloud Console.

  • Connectez-vous à la Qdrant Cloud Console ou utilisez l'outil CLI
  • Sélectionnez le cluster à redimensionner
  • Choisissez une configuration de nœud plus grande (plus de RAM, CPU, ou les deux)
  • Le processus de mise à niveau implique un redémarrage roulant sans temps d'arrêt si la réplication est configurée
  • Assurez-vous que replication_factor: 2 ou plus avant de redimensionner pour maintenir la disponibilité pendant le redémarrage roulant

Important : La mise à l'échelle est simple. La réduction à l'échelle nécessite de la prudence -- si l'ensemble de travail ne tient plus en RAM après la réduction, les performances se dégradent sévèrement en raison de l'éviction du cache. Testez toujours avant de réduire à l'échelle.

Lignes directrices pour le dimensionnement de la RAM

La RAM est la ressource la plus critique pour les performances de Qdrant. Utilisez ces lignes directrices pour dimensionner correctement.

  • L'estimation exacte de l'utilisation de la RAM est difficile ; utilisez cette simple formule approximative : num_vectors * dimensions * 4 bytes * 1.5 pour les vecteurs en précision complète en RAM
  • Avec la quantification scalaire : divisez par 4 (INT8 réduit chaque float32 à 1 octet) Quantification
  • Avec la quantification binaire : divisez par 32 Quantification binaire
  • Ajoutez les frais généraux pour l'index HNSW (~20-30 % des données vectorielles), les index de charge utile et le WAL
  • Réservez 20 % de marge pour les opérations d'optimisation et le cache du système d'exploitation
  • Surveillez l'utilisation réelle via Grafana/Prometheus avant et après le redimensionnement Surveillance

Quand la mise à l'échelle verticale ne suffit plus

Reconnaître ces signaux qu'il est temps de passer à l'horizontal :

  • Le volume de données dépasse ce qu'un seul nœud peut contenir même avec la quantification et mmap
  • Les IOPS sont saturées (plus de nœuds = plus d'E/S disque indépendantes)
  • Besoin de tolérance aux pannes (nécessite une réplication entre nœuds)
  • Besoin d'isolation des locataires via des shards dédiés
  • Le CPU d'un seul nœud est maxé et la latence des requêtes est inacceptable
  • L'étape suivante de mise à l'échelle verticale est la plus grande taille de nœud disponible. Vous pourriez avoir besoin de pouvoir augmenter temporairement à la taille de nœud plus grande pour effectuer des opérations de lot ou de récupération. Si vous êtes déjà à la plus grande taille de nœud, vous ne pourrez pas faire cela.

Quand vous atteignez ces limites, consultez Mise à l'échelle horizontale pour des conseils sur le sharding et la planification des nœuds.

Ce qu'il NE FAUT PAS faire

  • Ne réduisez pas la RAM sans tester la charge d'abord (éviction du cache = dégradation sévère de la latence qui peut durer des jours)
  • N'ignorez pas le seuil de 80 % de RAM (falaise de performance, pas une dégradation progressive)
  • Ne sautez pas la réplication avant le redimensionnement dans Cloud (redémarrage roulant sans répliques = temps d'arrêt)
  • Ne sautez pas directement à la mise à l'échelle horizontale avant d'épuiser les options verticales (ajoute une complexité opérationnelle permanente)
  • N'assumez pas que plus de CPU aide toujours (les charges de travail limitées par les IOPS ne s'amélioreront pas avec plus de cœurs)