qdrant-tenant-scaling

Guide de mise à l'échelle multi-tenant avec Qdrant. À utiliser quand quelqu'un demande « comment faire évoluer les tenants », « une collection par tenant ? », « isolation des tenants », « shards dédiés », ou signale des problèmes de performance liés aux tenants. À utiliser aussi quand les charges de travail multi-tenant dépassent les capacités de 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-locataires

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

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

Le nombre de locataires est autour de 10k

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

Consultez Partition by payload et Calibrate performance pour les bonnes pratiques d'indexation et de performance des requêtes.

Le nombre de locataires est autour de 100k et plus

À cette échelle, le cluster peut être constitué de plusieurs pairs. Pour localiser les données des locataires et améliorer la performance, utilisez le custom sharding pour attribuer les locataires à des shards spécifiques en fonction du hash de l'ID du locataire. Cela localisera les requêtes des locataires à des nœuds spécifiques au lieu de les diffuser à tous les nœuds, ce qui améliore la performance et réduit la charge sur chaque nœud.

Si les locataires ont des tailles inégales

Si certains locataires sont beaucoup plus grands que d'autres, utilisez la tiered multitenancy pour promouvoir les grands locataires à des shards dédiés tout en conservant les petits locataires sur des shards partagés. Cela optimise l'allocation des ressources et la performance pour les locataires de tailles variées.

Besoin d'une isolation stricte des locataires

À utiliser quand : les exigences légales/conformité exigent un chiffrement par locataire 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 locataire
  • Limitez le nombre de collections et utilisez le filtrage de payload au sein de chaque collection
  • C'est l'exception, pas la valeur par défaut. À utiliser uniquement quand la conformité l'exige.

Ce qu'il NE FAUT PAS faire

  • Ne créez pas une collection par locataire sans justification de conformité (ne passe pas à l'échelle au-delà de quelques centaines)
  • N'omettez pas is_tenant=true sur l'index du locataire (tue la performance de lecture séquentielle)
  • Ne construisez pas de HNSW global pour des collections multi-locataires (gaspillage, utilisez payload_m à la place)

Skills similaires