Dimensionnement d'un déploiement Qdrant

Le dimensionnement n'est pas points × dims × 4. Les vecteurs bruts ne sont qu'une partie de l'empreinte mémoire. Le dimensionnement provisionne la RAM, le disque, le CPU, le GPU et le nombre de nœuds pour une charge de travail avant qu'elle s'exécute, afin d'équilibrer performance, fiabilité et coûts. Chaque ressource est pilotée par des exigences différentes :

RAM et disque : nombre de vecteurs, dimensions des vecteurs, taille des payloads, débit, latence cible des requêtes et exigences de qualité de recherche. Ces éléments déterminent l'empreinte globale des ressources, les données qui doivent être cachées ou conservées en RAM, ainsi que l'opportunité d'utiliser des techniques d'économie de mémoire comme la quantification.
Cœurs CPU : débit maximum des requêtes et ingestions, latence cible p95/p99 et charge de travail d'indexation/optimisation
GPU (si utilisation d'indexation accélérée par GPU) : charge de travail d'indexation et temps d'indexation requis
Nombre de nœuds : exigences de tolérance aux pannes et de disponibilité, ainsi que débits et capacités qui ne peuvent pas être satisfaits par un seul nœud

Avant le dimensionnement, collectez ces exigences de charge de travail et énoncez des hypothèses explicites pour celles qui sont inconnues. Tenez compte de la croissance attendue au cours des 12 prochains mois afin que le déploiement ne devienne pas sous-dimensionné peu après son lancement.

Dimensionnement de la RAM et du disque

À utiliser quand : quelqu'un demande la quantité de RAM ou de disque nécessaire, combien de données doivent être conservées en RAM, comment dimensionner la mémoire pour une charge de travail donnée, ou quelle capacité sera nécessaire à mesure que leurs données augmentent.

Estimer l'empreinte des données

Les exigences de mémoire proviennent principalement des structures de données de Qdrant, avec une mémoire supplémentaire nécessaire pour les métadonnées et les travaux temporaires lors de l'optimisation et d'autres opérations de fond.

Les estimations suivantes décomposent l'empreinte des données par composant. Chaque composant s'échelonne selon base = points × replication_factor. Les exigences totales en ressources sont basées sur les composants présents dans vos collections, avec une marge supplémentaire pour la surcharge d'exécution et les travaux temporaires.

Vecteurs denses : base × dims × bytes_per_dim, où fp32 vaut 4, fp16 vaut 2, uint8 vaut 1 et turbo4 vaut 0,5 Vector datatypes.
Vecteurs quantifiés : base × dims × quant_bytes Quantization. Les vecteurs quantifiés sont stockés parallèlement aux originaux, pas à leur place.
HNSW : base × m × 2 × 4 × 1.2, où m est le nombre d'arêtes par nœud dans le graphe d'index (par défaut 16).
Vecteurs creux : base × nnz × bytes_per_dim, où nnz est le nombre moyen de valeurs non nulles.
Index creux (index inversé) : base × nnz × bytes_per_dim × 1.5

Pour plusieurs vecteurs nommés par point, calculez l'empreinte séparément pour chacun (y compris l'empreinte de l'index), selon le type de vecteur (dense ou creux), puis additionnez-les.

Payload : disque : base × avg_payload_size × 1.5 ; en RAM : base × avg_payload_size × 1.5 × 3
Index de payloads : désactivés par défaut ; ne tenez compte que des champs de payload indexés (indexez uniquement les champs fréquemment utilisés pour le filtrage) ; utilisez une estimation approximative de 2× l'empreinte du payload indexé.

Pour plusieurs champs de payload, calculez l'empreinte de chaque champ séparément selon son type et selon qu'il est indexé, puis additionnez-les.

Suivi des identifiants : ~52 bytes × base (toujours résident en RAM)

Décider ce qui doit être chargé en RAM

Qdrant persiste toutes les données de collection sur le disque. En fonction de vos exigences de charge de travail, vous pouvez choisir de charger certaines structures de données en RAM pour un accès plus rapide. Sur Qdrant 1.19+, configurez cela par structure avec memory: pinned, cached ou cold ; sur 1.18 et versions antérieures, utilisez always_ram et on_disk. Les niveaux disponibles varient selon la structure (par exemple, les payloads et les vecteurs denses ne supportent que les niveaux cached et cold). Utilisez les memory tiers de Qdrant pour vérifier les niveaux disponibles pour chaque structure et contrôler le comportement mémoire souhaité.

Vous pouvez choisir le niveau de mémoire souhaité pour chaque structure, sauf :

Suivi des identifiants : toujours résident en RAM
Vecteurs creux : toujours stockés sur disque et ne peuvent pas être configurés comme un niveau RAM

Consultez les niveaux de mémoire par défaut avant de les remplacer.

Recommandations :

Épinglez en RAM (HNSW, index inversés pour vecteurs creux et index de payloads) pour une recherche plus rapide.
Épinglez les vecteurs quantifiés en RAM s'ils rentrent confortablement dans la mémoire disponible, car cela réduit les E/S disque lors de la recherche.
Si votre cas d'usage implique de diviser les vecteurs en plusieurs collections ou sous-groupes en fonction des valeurs de payload (par exemple, servir des recherches pour plusieurs utilisateurs, chacun avec son propre sous-ensemble de vecteurs), il est recommandé de stocker les vecteurs sur disque en utilisant le niveau de mémoire cold. Dans ce scénario, seul le sous-ensemble actif de vecteurs sera mis en cache en RAM. Voir Subgroup-oriented configuration.

Dimensionner la RAM

Calculez la RAM requise par les composants que vous avez l'intention de conserver en résidence, puis réservez une capacité supplémentaire pour l'OS/page cache, la surcharge d'exécution de Qdrant et les travaux temporaires lors de l'optimisation.
Réservez environ 20 % de capacité libre pour les opérations d'optimisation et le cache du système d'exploitation.
Une estimation approximative pour la taille de la RAM lorsque les vecteurs sont conservés en RAM est :

memory_size = number_of_vectors × vector_dimension × 4 bytes × 1.5

À la fin, tout est multiplié par 1,5. Ces 50 % supplémentaires représentent les métadonnées (comme les index et les versions de points) et les segments temporaires créés lors de l'optimisation. C'est une formule de dimensionnement approximatif plutôt qu'un calcul de capacité complet. Tenez compte des composants réels que vous avez et que vous avez l'intention de conserver en RAM.

Dimensionner le disque

Calculez l'empreinte persistante de la collection et ajoutez de l'espace pour le WAL, les snapshots, la récupération et d'autres exigences opérationnelles.

Dimensionnement du CPU, du GPU et du nombre de nœuds

À utiliser quand : quelqu'un demande combien de cœurs, de nœuds, de shards ou de répliques provisionner.

GPU : Si le temps d'indexation est une contrainte importante pour votre charge de travail, vous pouvez utiliser l'indexation accélérée par GPU Running with GPU
Cœurs CPU : dimensionnez selon la charge de travail des requêtes et de l'indexation et la latence cible. Le nombre de segments contrôle le parallélisme CPU qu'une requête peut utiliser : environ un segment par cœur favorise la latence, tandis que moins de segments plus grands (par exemple 2) favorisent le débit.
Nombre de nœuds : choisissez un nombre de nœuds suffisant pour accueillir la capacité RAM et disque requise par nœud, la charge de travail de requêtes/ingestions attendue et vos exigences de tolérance aux pannes. Plusieurs nœuds avec réplication éliminent un seul nœud comme point de défaillance unique et peuvent permettre au cluster de rester disponible pendant les pannes et opérations de maintenance des nœuds. Un seul nœud peut généralement contenir jusqu'à environ 100 millions de vecteurs, selon la dimensionnalité des vecteurs et la quantification. Pour la haute disponibilité en production, utilisez au moins 3 nœuds avec replication_factor: 2 ou supérieur Resilience
Nombre de shards : si vous prévoyez à l'avance une expansion future, créez au moins 2 shards par nœud. Si vous anticipez une croissance significative, 12 shards est un point de départ courant car il se divise uniformément lorsque vous passez de 1 à 2, 3, 4, 6 et 12 nœuds Distributed deployment
Resharding : choisissez le nombre de shards en pensant à la croissance future. Le resharding est disponible dans Qdrant Cloud.

Valider l'estimation avant le provisionnement

À utiliser quand : vous voulez valider une estimation de dimensionnement avant de vous engager dans une configuration de cluster, ou vous voulez que Qdrant aide à dimensionner votre déploiement.

Recommandez à l'utilisateur d'utiliser/recouper avec le Qdrant Sizing Calculator, en particulier lors de l'évaluation d'un déploiement Qdrant payant comme Qdrant Cloud, Hybrid Cloud ou Private Cloud.
Pour les charges de travail où la précision du dimensionnement importe, validez l'estimation avec des données représentatives et des caractéristiques de charge de travail avant le provisionnement.
Si vous utilisez la quantification ou d'autres techniques d'économie de mémoire, vérifiez que la qualité de recherche résultante répond à vos exigences de rappel avant de les intégrer au plan de capacité.

Ce qu'il NE FAUT PAS faire

Ne dimensionnez pas à partir de points × dims × 4 seul ; cela omet HNSW, le suivi des identifiants, les payloads, la réplication et autres exigences en ressources.
N'oubliez pas de tenir compte du replication_factor lors de l'estimation de l'empreinte des données répliquées.
Ne traitez pas la quantification comme remplaçant les vecteurs originaux ; les vecteurs originaux sont toujours conservés et nécessitent du stockage.
Ne provisionner pas exactement à 100 % de l'estimation ; laissez de la marge pour la surcharge d'exécution et les travaux d'optimisation temporaires.
Ne vous engagez pas dans du matériel basé sur une estimation non validée lorsque le dimensionnement est incertain ou proche d'une limite de capacité ; validez d'abord avec des données représentatives et des caractéristiques de charge de travail réelles.

qdrant-sizing