qdrant-tenant-scaling

--- Guides pour la mise à l'échelle multi-tenant de Qdrant. À utiliser lorsque quelqu'un demande « comment mettre à l'échelle les tenants », « une collection par tenant ? », « isolation des tenants », « shards dédiés », ou signale des problèmes de performance des tenants. À utiliser également lorsque les charges de travail multi-tenant dépassent l'infrastructure partagée.

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

Que faire lors de la mise à l'échelle de Qdrant Multi-Tenant

Ne créez pas une collection par tenant. Cela ne s'étend pas au-delà de quelques centaines et gaspille les ressources. Une entreprise a atteint la limite de 1000 collections après un an de collection-per-repo et a dû migrer vers le partitionnement de payload. Utilisez une collection partagée avec une clé de tenant.

Voici un court résumé des modèles :

Le nombre de tenants est autour de 10k

Utilisez la stratégie de multitenancy par défaut via le filtrage de payload.

Lisez Partition by payload et Calibrate performance pour les meilleures pratiques en matière d'indexation et de performances des requêtes.

Le nombre de tenants est autour de 100k et plus

À cette échelle, le cluster peut être composé de plusieurs pairs. Pour localiser les données des tenants et améliorer les performances, utilisez custom sharding pour affecter les tenants à des shards spécifiques en fonction du hash de l'ID du tenant. Cela localisera les requêtes des tenants à des nœuds spécifiques au lieu de les diffuser à tous les nœuds, améliorant les performances et réduisant la charge sur chaque nœud.

Si les tenants ont des tailles inégales

Si certains tenants sont beaucoup plus volumineux que d'autres, utilisez tiered multitenancy pour promouvoir les grands tenants vers des shards dédiés tout en gardant les petits tenants sur des shards partagés. Cela optimise l'allocation des ressources et les performances pour les tenants de différentes tailles.

Besoin d'une isolation stricte des tenants

À utiliser quand : les exigences légales/conformité exigent le chiffrement par tenant ou une isolation stricte au-delà de ce que le filtrage de payload fournit.

  • Plusieurs collections peuvent être nécessaires pour les clés de chiffrement par tenant
  • Limitez le nombre de collections et utilisez le filtrage de payload au sein de chaque collection
  • C'est l'exception, pas la règle. À utiliser uniquement si la conformité l'exige.

Ce qu'il NE FAUT PAS faire

  • Ne créez pas une collection par tenant sans justification de conformité (ne s'étend pas au-delà de centaines)
  • N'omettez pas is_tenant=true sur l'index des tenants (tue les performances de lecture séquentielle)
  • Ne construisez pas de HNSW global pour les collections multi-tenant (gaspillant, utilisez payload_m à la place)