Que faire lors de la mise à l'échelle de Qdrant multi-locataire

Ne créez pas une collection par locataire. Cela ne se scale 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-par-repo et a dû migrer vers le partitionnement par payload. Utilisez une collection partagée avec une clé de locataire.

• Comprendre les patterns de multitenancy Multitenancy

Voici un bref résumé des patterns :

Nombre de locataires autour de 10k

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

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

Nombre de locataires autour de 100k et plus

À cette échelle, le cluster peut être composé de plusieurs pairs. Pour localiser les données des locataires et améliorer les performances, utilisez le custom sharding pour assigner les locataires à des shards spécifiques en fonction du hash de l'ID du locataire. Cela va localiser les requêtes des locataires à des nœuds spécifiques au lieu de les broadcaster à tous les nœuds, améliorant les performances et réduisant 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 gardant les petits locataires sur des shards partagés. Cela optimise l'allocation des ressources et les performances pour les locataires de tailles variées.

Besoin d'une stricte isolation des locataires

Utilisez quand : les exigences légales/conformité demandent un chiffrement par locataire ou une isolation stricte au-delà de ce que le filtrage par 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 par payload dans chaque collection
• C'est l'exception, pas la règle par défaut. Utilisez seulement 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 scale pas au-delà de quelques centaines)
• Ne sautez pas is_tenant=true sur l'index du locataire (tue les performances de lecture séquentielle)
• Ne construisez pas de HNSW global pour les collections multi-locataires (gaspilleur, utilisez payload_m à la place)