Que faire quand l'indexation Qdrant est trop lente

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

• Comprendre l'optimiseur d'indexation Indexing optimizer

Les uploads/ingestions sont trop lents

À utiliser quand : les appels API upload ou upsert sont lents. Identifier le goulot : côté client (réseau, batching) vs côté serveur (CPU, E/S disque)

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

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

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

• Créer plus de shards (3-12), chaque shard a un worker d'update indépendant Sharding
• Créer des payload indexes avant que HNSW se construise (nécessaire pour un index de vecteurs filtrable) Payload index

Adapté pour le chargement en masse initial de grands datasets :

• Désactiver HNSW pendant le 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, utilisez plutôt un indexing_threshold_kb élevé

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 le 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 l'endpoint optimizations (v1.17+) Optimization monitoring
• Les grandes fusions et reconstructions HNSW prennent légitimement des heures sur les gros datasets
• Vérifier le CPU et l'E/S disque (HNSW est limité par le CPU, la fusion est limitée par l'E/S, HDD n'est pas viable)
• Si optimizer_status affiche une erreur, vérifiez les logs pour un disque plein ou des segments corrompus

Le temps de construction de HNSW est trop élevé

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

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

Index HNSW pour les collections multi-locataires

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

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

Les payload indexes supplémentaires sont trop lents

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

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

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

Lire plus sur ACORN dans la documentation

Ce qu'il NE FAUT PAS faire

• Ne pas créer de payload indexes APRÈS la construction de HNSW (casse l'index de vecteurs 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 upload un point à la fois (le surcoût par requête domine)