Que faire quand Qdrant doit passer à l'échelle verticale

L'évolution verticale consiste à 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 avant d'envisager une évolution horizontale. L'évolution verticale est plus simple, évite la complexité des systèmes distribués et est réversible.

• L'évolution 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 passer à l'échelle verticale

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

• Utilisation de RAM approchant 80 % de la mémoire disponible (l'éviction du cache des pages du système d'exploitation commence, dégradation grave des performances)
• Saturation du CPU lors de la requête ou de l'indexation
• Espace disque en cours d'épuisement pour les vecteurs et charges utiles sur disque
• Un seul nœud peut gérer jusqu'à environ 100 M de vecteurs selon les dimensions et la quantification
• Pour les charges de travail hors production, tolérantes à un point de défaillance unique et ne nécessitant pas une haute disponibilité

Comment passer à l'échelle verticale dans Qdrant Cloud

L'évolution verticale est gérée via la Qdrant Cloud Console.

• Connectez-vous à 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 progressif sans interruption de service si la réplication est configurée
• Assurez-vous que replication_factor: 2 ou plus avant de redimensionner pour maintenir la disponibilité lors du redémarrage progressif

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

Directives de dimensionnement de la RAM

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

• L'estimation exacte de l'utilisation de la RAM est difficile ; utilisez cette formule approximative simple : num_vectors * dimensions * 4 bytes * 1.5 pour les vecteurs en pleine précision 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 la surcharge 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 Monitoring

Quand l'évolution verticale ne suffit plus

Reconnaissez ces signaux qu'il est temps de passer à l'horizontale :

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

Quand vous atteignez ces limites, consultez Horizontal Scaling 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 test de charge préalable (é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 de redimensionner dans Cloud (redémarrage progressif sans répliques = interruption de service)
• Ne passez pas directement à l'évolution horizontale avant d'épuiser les options verticales (ajoute une complexité opérationnelle permanente)
• Ne supposez pas que plus de CPU aide toujours (les charges de travail limitées par les IOPS n'amélioreront pas avec plus de cœurs)