qdrant-indexing-performance-optimization

Diagnostique et corrige l'indexation lente de Qdrant et l'ingestion de données. À utiliser quand quelqu'un signale « les uploads sont lents », « l'indexation prend une éternité », « l'optimizer est bloqué », « le temps de construction HNSW est trop long », ou « les données ont été uploadées mais la recherche est mauvaise ». À utiliser également quand le statut de l'optimizer affiche des erreurs, que les segments ne fusionnent pas, ou quand des questions sur le seuil d'indexation se posent.

npx skills add https://github.com/qdrant/skills --skill qdrant-indexing-performance-optimization

Que faire quand l'indexation Qdrant est trop lente

Qdrant ne construit PAS les index HNSW immédiatement. Les petits segments utilisent la recherche par force brute jusqu'à ce qu'ils dépassent indexing_threshold_kb (par défaut : 20 MB). La recherche pendant cette fenêtre est intentionnellement plus lente, ce n'est pas un bug.

Les uploads/l'ingestion sont trop lents

À utiliser quand : les appels API d'upload ou d'upsert sont lents. Identifier le goulot d'étranglement : côté client (réseau, batching) ou côté serveur (CPU, I/O disque)

Pour le côté client, optimiser le batching et le parallélisme :

  • Utiliser les upserts par lot (64-256 points par requête) Points API
  • Utiliser 2-4 flux d'upload parallèles

Pour le côté serveur, optimiser la configuration Qdrant et la stratégie d'indexation :

  • Créer plus de shards (3-12), chaque shard dispose d'un worker de mise à jour indépendant Sharding
  • Créer des index de payload avant que HNSW ne se construise (nécessaire pour l'index vectoriel filtrable) Payload index

Approprié pour le chargement initial en masse de grands ensembles de données :

  • Désactiver HNSW lors du chargement en masse (définir indexing_threshold_kb très haut, restaurer après) Collection params
  • Définir m=0 pour désactiver HNSW est obsolète, utiliser plutôt un indexing_threshold_kb haut

Attention, un upload rapide non indexé pourrait temporairement utiliser plus de RAM et dégrader les performances de recherche jusqu'à ce que l'optimiseur rattrape son retard.

Voir https://search.qdrant.tech/md/documentation/tutorials-develop/bulk-upload/

L'optimiseur est bloqué ou prend trop longtemps

À utiliser quand : l'optimiseur s'exécute depuis des heures, sans finir.

  • Vérifier la progression réelle via le point de terminaison optimizations (v1.17+) Optimization monitoring
  • Les grands fusions et reconstructions HNSW prennent légitimement des heures sur les grands ensembles de données
  • Vérifier l'utilisation du CPU et de l'I/O disque (HNSW est limité par le CPU, la fusion est limitée par l'I/O, le HDD n'est pas viable)
  • Si optimizer_status affiche une erreur, vérifier les journaux pour un disque plein ou des segments corrompus

Le temps de construction HNSW est trop élevé

À utiliser quand : la construction de l'index HNSW domine le temps d'indexation total.

  • Réduire m (par défaut 16, bon pour la plupart des cas, 32+ rarement nécessaire) HNSW params
  • Réduire ef_construct (100-200 suffisent) HNSW config
  • Garder max_indexing_threads proportionnel aux cœurs CPU Configuration
  • Utiliser le GPU pour l'indexation GPU indexing

Index HNSW pour les collections multi-locataires

Si vous avez un cas d'utilisation multi-locataires où toutes les données sont divisées par un champ de payload (par ex. tenant_id), vous pouvez éviter de construire un index HNSW global et vous appuyer plutôt sur payload_m pour construire un index HNSW uniquement pour les sous-ensembles de données. Ignorer l'index HNSW global peut réduire considérablement le temps d'indexation.

Voir Multi-tenant collections pour plus de détails.

Les index de payload supplémentaires sont trop lents

Qdrant construit des liens HNSW supplémentaires pour tous les index de payload afin que la qualité de la recherche vectorielle filtrée ne se dégrade pas. Certains index de payload (par ex. les champs text avec des textes longs) peuvent avoir un très grand nombre de valeurs uniques par point, ce qui peut entraîner un long temps de construction HNSW.

Vous pouvez désactiver la construction de liens HNSW supplémentaires pour un index de payload spécifique et plutôt vous appuyer sur des stratégies légèrement plus lentes au moment de la requête comme ACORN.

En savoir plus sur la désactivation des liens HNSW supplémentaires dans la documentation

En savoir plus sur ACORN dans la documentation

Ce qu'il NE FAUT PAS faire

  • Ne pas créer d'index de payload APRÈS que HNSW soit construit (casse l'index vectoriel filtrable)
  • Ne pas utiliser m=0 pour les uploads en masse dans une collection existante, cela pourrait supprimer le HNSW existant et causer une longue réindexation
  • Ne pas uploader un point à la fois (la surcharge par requête domine)