Partager via

Modéliser des applications SaaS multilocataires dans Azure Cosmos DB for PostgreSQL

  • S’applique à: ✅ PostgreSQL

Important

Azure Cosmos DB pour PostgreSQL n’est plus pris en charge pour les nouveaux projets. N’utilisez pas ce service pour les nouveaux projets. Utilisez plutôt l’un des deux services suivants :

ID de locataire comme clé de partition

L'ID de client est la colonne à la racine de la charge de travail, ou au sommet de la hiérarchie dans votre modèle de données. Par exemple, dans ce schéma de commerce électronique SaaS, il s’agit de l’ID de boutique :

Diagramme des tables avec la colonne store_id mise en évidence.

Ce modèle de données serait typiquement adapté à une entreprise telle que Shopify. Il héberge des sites pour plusieurs boutiques en ligne, où chaque boutique interagit avec ses propres données.

  • Ce modèle de données comporte un ensemble de tables : boutiques, produits, commandes, articles de ligne et pays.
  • La table des boutiques se trouve en haut de la hiérarchie. Les produits, les commandes et les articles de ligne sont tous associés aux boutiques, donc situés plus bas dans la hiérarchie.
  • La table des pays n’est pas liée aux boutiques individuelles, mais à toutes les boutiques.

Dans cet exemple, store_id, qui se trouve en haut de la hiérarchie, est l’identificateur du locataire. C’est la clé de partition appropriée. Choisir store_id en tant que clé de partition active la colocalisation de données entre toutes les tables pour une seule boutique sur un seul Worker.

La colocalisation des tables par boutique présente des avantages :

  • Fournit la couverture SQL comme les clés étrangères, les opérations JOIN. Les transactions pour un seul locataire sont localisées sur un seul nœud Worker où chaque locataire existe.
  • Atteint des performances en milliseconde à un seul chiffre. Les requêtes d’un seul locataire sont routées vers un seul nœud au lieu d’être parallélisées, ce qui permet d’optimiser les tronçons réseau et de mettre à l’échelle le calcul/la mémoire.
  • Elle évolue. À mesure que le nombre de locataires augmente, vous pouvez ajouter des nœuds et rééquilibrer les locataires vers de nouveaux nœuds, ou même isoler les grands locataires sur leurs propres nœuds. L’isolation du locataire vous permet de fournir des ressources dédiées.

Diagramme des tables situées sur les mêmes nœuds.

Modèle de données optimal pour les applications multilocataires

Dans cet exemple, nous devons distribuer les tables spécifiques à une boutique par ID de boutique et désigner countries comme table de référence.

Diagramme des tables avec store_id mis en évidence de manière plus universelle.

Notez que les tables spécifiques du locataire ont l’ID du locataire et sont distribuées. Dans notre exemple, les boutiques, les produits et les articles de ligne sont distribués. Les autres tables sont des tables de référence. Dans notre exemple, la table des pays est une table de référence.

-- Distribute large tables by the tenant ID

SELECT create_distributed_table('stores', 'store_id');
SELECT create_distributed_table('products', 'store_id', colocate_with => 'stores');
-- etc for the rest of the tenant tables...

-- Then, make "countries" a reference table, with a synchronized copy of the
-- table maintained on every worker node

SELECT create_reference_table('countries');

Les grandes tables doivent toutes avoir l’ID du locataire.

  • Si vous migrez une application multi-locataire existante vers Azure Cosmos DB for PostgreSQL, vous devrez peut-être dénormaliser un peu et ajouter la colonne ID de locataire à des tables volumineuses si elle est manquante, puis compléter les valeurs manquantes de la colonne.
  • Pour les nouvelles applications sur Azure Cosmos DB for PostgreSQL, vérifiez que l’ID de locataire est présent sur toutes les tables spécifiques du locataire.

Veillez à inclure l’ID de locataire sur les contraintes de clé primaire, unique et étrangère sur les tables distribuées sous la forme d’une clé composite. Par exemple, si une table a une clé primaire id, transformez-la en clé composite (tenant_id,id). Il n’est pas nécessaire de modifier les clés pour les tables de référence.

Considérations relatives aux requêtes pour optimiser les performances

Les requêtes distribuées filtrées sur l’ID de locataire s’exécutent plus efficacement dans les applications multi-locataire. Vérifiez que vos requêtes sont toujours étendues à un seul locataire.

SELECT *
  FROM orders
 WHERE order_id = 123
   AND store_id = 42;  -- ← tenant ID filter

Il est nécessaire d’ajouter le filtre d’ID de locataire même si les conditions de filtre d’origine identifient sans ambiguïté les lignes souhaitées. Le filtre d’ID de locataire, tout en semblant redondant, indique à Azure Cosmos DB for PostgreSQL comment acheminer la requête vers un seul nœud Worker.

De même, lorsque vous joignez deux tables distribuées, vérifiez que les deux tables sont étendues sur un seul locataire. La définition de l’étendue peut être effectuée en veillant à ce que les conditions de jointure incluent l’ID de locataire.

SELECT sum(l.quantity)
  FROM line_items l
 INNER JOIN products p
    ON l.product_id = p.product_id
   AND l.store_id = p.store_id   -- ← tenant ID in join
 WHERE p.name='Awesome Wool Pants'
   AND l.store_id='8c69aa0d-3f13-4440-86ca-443566c1fc75';
       -- ↑ tenant ID filter

Il existe des bibliothèques d’assistance pour plusieurs frameworks d’application populaires qui facilitent l’intégration d’un ID de locataire dans les requêtes. Voici des instructions :

Étapes suivantes

Nous avons terminé d’explorer la modélisation de données pour les applications scalables. L’étape suivante consiste à connecter et interroger la base de données avec le langage de programmation de votre choix.

Piles d’applications>

  • Last updated on