Que faire quand l'indexation Qdrant est trop lente

Qdrant ne construit PAS les indexes 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 période 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 d'upload ou d'upsert sont lents. Identifier le goulot : côté client (réseau, batching) ou côté serveur (CPU, I/O disque)

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

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

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

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

À utiliser pour le chargement en masse initial de grands datasets :

• Désactivez HNSW pendant le chargement en masse (définissez indexing_threshold_kb très haut, restaurez après) Collection params
• Définir m=0 pour désactiver HNSW est hérité, utilisez plutôt un indexing_threshold_kb élevé

Attention, un upload rapide non indexé peut 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 de temps

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

• Vérifiez la progression réelle via le endpoint d'optimisations (v1.17+) Optimization monitoring
• Les grandes fusions et reconstructions HNSW prennent légitimement des heures sur les grands datasets
• Vérifiez le CPU et l'I/O disque (HNSW est limité par le CPU, la fusion par l'I/O, le 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éduisez m (par défaut 16, bon pour la plupart des cas, 32+ rarement nécessaire) HNSW params
• Réduisez ef_construct (100-200 suffisent) HNSW config
• Maintenez max_indexing_threads proportionnel aux cœurs CPU Configuration
• Utilisez le GPU pour l'indexation GPU indexing

Index HNSW pour les collections multi-tenants

Si vous avez un cas d'usage multi-tenant 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 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 index de payload supplémentaires sont trop lents

Qdrant construit des liens HNSW supplémentaires pour tous les index de payload afin de garantir que la qualité de la recherche de vecteurs filtrée ne se dégrade pas. Certains index de payload (par ex. champs text avec de longs textes) 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 vous appuyer plutôt 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 créez pas d'index de payload APRÈS que HNSW soit construit (casse l'index de vecteur filtrable)
• N'utilisez pas m=0 pour les uploads en masse dans une collection existante, cela pourrait supprimer le HNSW existant et causer une longue réindexation
• N'uploadez pas un point à la fois (le surcoût par requête domine)