Multitenancy Qdrant

La multitenancy est la façon dont vous isolez les données entre plusieurs utilisateurs ou tenants au sein d'un seul déploiement Qdrant.

• La question à se poser est : combien de tenants, et à quel point sont-ils de tailles inégales ? La réponse détermine la stratégie d'isolation.
• Comprenez les trois niveaux d'isolation avant de choisir : basés sur les payloads, les shards et les collections.
• Pour presque tout le monde, la bonne valeur par défaut est une seule collection partitionnée par payload, PAS une collection par tenant.

Beaucoup de petits tenants (Par défaut : partitionnement par payload)

À utiliser quand : vous avez de nombreux tenants de taille similaire et modeste. Ceci est la valeur par défaut recommandée pour la plupart des utilisateurs.

Une seule collection contient tous les tenants. Un champ de payload marque la propriété, et un filtre sur ce champ au moment de la requête isole les résultats de chaque tenant.

Fonctionnement

• Créez un index de payload de type keyword sur le champ tenant avec is_tenant=true (ce flag nécessite v1.11+). is_tenant indique à Qdrant que le champ identifie les tenants, de sorte que les vecteurs de chaque tenant sont stockés ensemble et servis par des lectures séquentielles. Consultez .
• Au moment de la requête, isolez chaque tenant avec un filtre must sur le champ tenant. Sans lui, une requête parcourt les données de tous les tenants. Consultez Multitenancy basée sur les payloads.
• Avec cette stratégie, la vitesse d'indexation peut devenir un goulot d'étranglement à grande échelle car chaque tenant s'indexe dans la même collection. Pour éviter cela, vous pouvez désactiver la création globale de HNSW (pour toute la collection) et ne construire que des index par tenant : définissez m=0 et payload_m à une valeur non nulle. Bien que cela accélère le processus d'indexation, gardez à l'esprit que les requêtes sans filtre tenant seront plus lentes car elles doivent scanner tous les groupes. Ne faites donc ce compromis que si vous atteignez le goulot d'étranglement et que la recherche inter-tenants est rare. Calibrez les performances.

Quelques grands tenants plus une longue traîne (Multitenancy hiérarchisée)

À utiliser quand : vous avez une distribution SaaS réaliste : quelques gros clients et beaucoup de petits, possiblement avec des petits tenants qui se développent au fil du temps. Disponible en v1.16+. Cela évite le problème du voisin bruyant, où un grand tenant force tout le cluster à se mettre à l'échelle, augmentant les coûts et dégradant les performances pour tout le monde.

La multitenancy hiérarchisée garde les petits tenants ensemble dans un shard de secours partagé tout en isolant les grands tenants dans leurs propres shards dédiés, le tout dans une seule collection. Elle superpose deux niveaux d'isolation : la tenancy basée sur les payloads pour l'isolation logique, et le sharding personnalisé pour l'isolation physique/basée sur les ressources des grands tenants. Un tenant qui dépasse le shard partagé peut être promu à un shard dédié plus tard sans interruption.

Fonctionnement

• Créez la collection avec un sharding personnalisé (défini par l'utilisateur) et configurez la tenancy basée sur les payloads. Un seul shard de secours partagé contient tous les petits tenants. Si vous avez de grands tenants, créez des shards dédiés (un par tenant). Consultez Multitenancy hiérarchisée.
• Quand promouvoir un tenant ? Si un tenant devient assez grand pour justifier des ressources dédiées (un déclencheur de promotion raisonnable est quand un tenant approche le seuil d'indexation), promouvez-le à un shard dédié. Qdrant déplace ses données vers un nouveau shard de façon transparente, servant les lectures et écritures tout du long. Consultez comment promouvoir un tenant vers un shard dédié.
• Gardez à l'esprit que le re-sharding peut être un processus coûteux et chronophage, alors considérez attentivement vos modèles de croissance des tenants quand vous décidez lesquels doivent recevoir des shards dédiés.
• Il n'est pas recommandé de dépasser environ 1 000 shards dédiés par cluster (surcharge de ressources).
• Le shard de secours (petits tenants) doit tenir sur un seul nœud.
• La méthode de sharding est fixée à la création de la collection : une collection auto-shardée (par défaut) ne peut pas être convertie en sharding personnalisé sur place. S'il y a une chance réaliste que vous ayez besoin d'isoler un grand tenant plus tard, créez la collection avec un sharding personnalisé dès le départ et mettez tous les tenants dans le shard de secours.

Peu de tenants hétérogènes (Collection par tenant)

À utiliser quand : vous avez un nombre limité de tenants avec des modèles d'embedding ou des schémas de collection différents par tenant.

• Vous ne devriez créer plusieurs collections que si vos données ne sont pas homogènes ou si les vecteurs des utilisateurs sont créés par des modèles d'embedding différents.

Résidence des données et isolation géographique (Sharding personnalisé)

À utiliser quand : les données doivent être physiquement ancrées à un endroit, par exemple la conformité régionale pour l'industrie de la santé (les données d'une région au Canada, celles d'une autre en Allemagne). Ceci n'est pas seulement une préoccupation liée aux tenants, un seul tenant peut aussi avoir besoin de séparer ses propres données par région.

• Comme la multitenancy hiérarchisée, ceci utilise le sharding personnalisé ; la différence est ce par quoi vous shardez. Ici, la clé de shard est une région. Les données de chaque clé atterrissent sur des shards spécifiques que vous pouvez placer dans des emplacements spécifiques, tandis que tout reste dans une seule collection. Combinez-le avec le partitionnement par payload si vous avez aussi besoin d'une isolation par tenant au sein d'une région. Consultez Sharding défini par l'utilisateur pour la configuration.
• La résidence géographique ne suit que si les nœuds de votre cluster sont réellement dans les régions cibles.
• Qdrant Cloud déploie un cluster dans une seule région et n'a pas de multi-région géré aujourd'hui.

Ce qu'il NE FAUT PAS faire

• Traiter un filtre de payload comme votre modèle de sécurité complet. Dans Qdrant (sauf si vous utilisez des collections par tenant), l'isolation des tenants est basée sur les payloads. C'est une responsabilité au niveau de l'application, et le filtre n'en est qu'une petite partie.