qdrant-scaling-qps

--- Guides Qdrant query throughput (QPS) scaling. À utiliser quand quelqu'un demande « comment augmenter le QPS », « j'ai besoin de plus de débit », « les requêtes par seconde sont trop basses », « batch search », « read replicas », ou « comment gérer plus de requêtes concurrentes ».

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

Mise à l'échelle pour le débit de requêtes (QPS)

La mise à l'échelle du débit signifie traiter plus de requêtes parallèles par seconde. Ceci est différent de la latence - le débit et la latence sont des directions d'optimisation opposées et ne peuvent pas être optimisés simultanément sur le même nœud.

Un débit élevé favorise moins de segments, plus grands, de sorte que chaque requête subit moins de surcharge.

Optimisation des performances pour un RPS plus élevé

  • Utiliser moins de segments, plus grands (default_segment_number: 2) Maximizing throughput
  • Activer la quantification avec always_ram=true pour réduire les E/S disque Quantization
  • Utiliser l'API batch search pour amortir la surcharge Batch search

Minimiser l'impact des charges de travail de mise à jour

  • Configurer le contrôle du débit de mise à jour (v1.17+) pour empêcher que les recherches non optimisées ne dégradent les lectures Low latency search
  • Définir optimizer_cpu_budget pour limiter les CPUs d'indexation (par exemple 2 sur un nœud à 8 CPU réserve 6 pour les requêtes)
  • Configurer le fan-out de lecture différé (v1.17+) pour la latence de queue Delayed fan-outs

Mise à l'échelle horizontale pour le débit

Si un seul nœud est saturé en CPU après application du tuning ci-dessus, augmentez l'échelle horizontalement avec des réplicas de lecture.

  • Les réplicas de shards servent les requêtes à partir de shards répliqués, distribuant la charge de lecture sur les nœuds
  • Chaque réplica ajoute une capacité de requête indépendante sans re-sharding
  • Utiliser replication_factor: 2+ et acheminer les lectures vers les réplicas Distributed deployment

Consultez également Horizontal Scaling pour les conseils généraux de mise à l'échelle horizontale.

Goulots d'étranglement des E/S disque

S'il n'est pas possible de conserver tous les vecteurs en RAM, les E/S disque peuvent devenir le goulot d'étranglement du débit. Dans ce cas :

  • Upgrader d'abord vers des IOPS provisionné ou NVMe local. Voir l'impact des performances disque sur la recherche de vecteurs dans Disk performance article
  • Utiliser io_uring sur Linux (kernel 5.11+) io_uring article
  • En cas de vecteurs quantifiés, préférer le rescoring global au rescoring par segment pour réduire les lectures disque. Exemple dans le tutorial
  • Configurer un nombre plus élevé de threads de recherche pour paralléliser les lectures disque. La valeur par défaut est cpu_count - 1, qui est optimale pour la recherche basée sur la RAM mais peut être trop faible pour la recherche basée sur le disque. Voir configuration reference
  • S'il y a toujours saturation, augmentez l'échelle horizontalement (chaque nœud ajoute des IOPS indépendantes)

Ce qu'il NE FAUT PAS faire

  • Ne pas s'attendre à optimiser le débit et la latence simultanément sur le même nœud
  • Ne pas utiliser de nombreux petits segments pour les charges de travail de débit (augmente la surcharge par requête)
  • Ne pas augmenter l'échelle horizontalement quand limité par les IOPS sans également améliorer le niveau disque
  • Ne pas fonctionner à >90% de RAM (éviction du cache OS = dégradation sévère des performances)