Delen via

SaaS-apps met meerdere tenants modelleren in Azure Cosmos DB for PostgreSQL

  • Van toepassing op: ✅ PostgreSQL

Belangrijk

Azure Cosmos DB for PostgreSQL wordt niet meer ondersteund voor nieuwe projecten. Gebruik deze service niet voor nieuwe projecten. Gebruik in plaats daarvan een van deze twee services:

Tenant-ID als de shard-sleutel

De tenant-ID is de kolom in de wortel van de werkbelasting of aan de top van de hiërarchie in je gegevensmodel. In dit SaaS-e-commerceschema zou dit bijvoorbeeld de winkel-id zijn:

Diagram van tabellen, met de kolom store_id gemarkeerd.

Dit gegevensmodel zou typisch zijn voor een bedrijf zoals Shopify. Het host sites voor meerdere online winkels, waar elke winkel communiceert met zijn eigen gegevens.

  • Dit gegevensmodel bevat een aantal tabellen: winkels, producten, orders, regelitems en landen.
  • De tabel "Stores" bevindt zich bovenaan de hiërarchie. Producten, orders en regelitems zijn allemaal gekoppeld aan winkels, dus lager in de hiërarchie.
  • De landentabel is niet gerelateerd aan afzonderlijke winkels, deze bevindt zich in alle winkels.

In dit voorbeeld, store_id, dat zich boven aan de hiërarchie bevindt, is de identifier voor de tenant. Het is de juiste shardsleutel. Als u store_id kiest als de shard-sleutel, maakt dat het mogelijk om gegevens over alle tabellen voor één winkel op één werker samen te voegen.

Het coloceren van tabellen per winkel heeft voordelen:

  • Biedt SQL-ondersteuning, zoals vreemde sleutels en JOIN's. Transacties voor één tenant worden gelokaliseerd op één werkknooppunt waar elke tenant bestaat.
  • Realiseert prestaties van enkele milliseconden. Queries voor een enkele tenant worden naar één knooppunt geleid in plaats van geparallelliseerd, wat helpt netwerkhops te optimaliseren en toch de rekenkracht/geheugencapaciteit te schalen.
  • Het is schaalbaar. Naarmate het aantal tenants groeit, kunt u knooppunten toevoegen en de tenants opnieuw verdelen over nieuwe knooppunten, of zelfs grote tenants isoleren naar hun eigen knooppunten. Met tenantisolatie kunt u toegewezen resources leveren.

Diagram van tabellen die zijn gekoppeld aan dezelfde knooppunten.

Optimaal gegevensmodel voor apps met meerdere tenants

In dit voorbeeld moeten we de winkelspecifieke tabellen distribueren op winkel-id, en countries tot een referentietabel maken.

Diagram van tabellen met store_id meer universeel gemarkeerd.

U ziet dat tenantspecifieke tabellen een tenant-id hebben en worden gedistribueerd. In ons voorbeeld worden winkels, producten en line_items gedistribueerd. De rest van de tabellen zijn referentietabellen. In ons voorbeeld is de tabel Landen een referentietabel.

-- 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');

Grote tabellen moeten allemaal de tenant-id hebben.

  • Als u een bestaande app met meerdere tenants migreert naar Azure Cosmos DB for PostgreSQL, moet u mogelijk een beetje denormaliseren en de kolom tenant-id toevoegen aan grote tabellen als deze ontbreekt en de ontbrekende waarden van de kolom opnieuw doorvoeren.
  • Zorg ervoor dat de tenant-id aanwezig is in alle tenantspecifieke tabellen voor nieuwe apps in Azure Cosmos DB for PostgreSQL.

Zorg ervoor dat u de tenant-ID opneemt in primaire, unieke en vreemde sleutelbeperkingen voor gedistribueerde tabellen als onderdeel van een samengestelde sleutel. Als een tabel bijvoorbeeld een primaire sleutel idheeft, kunt u deze omzetten in de samengestelde sleutel (tenant_id,id). U hoeft geen sleutels voor referentietabellen te wijzigen.

Overwegingen bij queries voor de beste prestaties

Gedistribueerde query's die op de tenant-id filteren, worden het efficiëntst uitgevoerd in apps met meerdere tenants. Zorg ervoor dat uw query's altijd zijn afgestemd op één tenant.

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

Het is nodig om het tenant-id-filter toe te voegen, zelfs als de oorspronkelijke filtervoorwaarden de gewenste rijen ondubbelzinnig identificeren. Het tenant-id-filter, terwijl het schijnbaar redundant is, vertelt Azure Cosmos DB for PostgreSQL hoe de query naar één werkknooppunt moet worden gerouteerd.

Als u twee gedistribueerde tabellen samenvoegt, moet u er ook voor zorgen dat beide tabellen zijn afgestemd op één tenant. Het bereik kan worden bereikt door ervoor te zorgen dat joinvoorwaarden de tenant-ID bevatten.

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

Er zijn helperbibliotheken voor verschillende populaire toepassingsframeworks waarmee u eenvoudig een tenant-id in query's kunt opnemen. Hier volgen instructies:

Volgende stappen

Nu zijn we klaar met het verkennen van gegevensmodellering voor schaalbare apps. De volgende stap is het verbinden en opvragen van de database met de programmeertaal van uw keuze.

App-stacks >

  • Last updated on