Multitenancy en Azure Cosmos DB

  • Artikel
  • 8 minuten om te lezen

Op deze pagina worden enkele van de functies van Azure Cosmos DB beschreven die nuttig zijn bij het werken met systemen met meerderetenant. Daarnaast vindt u hier een koppeling naar richtlijnen en voorbeelden voor het gebruik van Azure Cosmos DB in een multitenant-oplossing.

Functies van Azure Cosmos DB die ondersteuning bieden voor multitenancy

Partitionering

Door partities te gebruiken met uw Cosmos DB containers, kunt u containers maken die worden gedeeld met meerdere tenants. Normaal gesproken gebruikt u de tenant-id als partitiesleutel, maar u kunt ook overwegen om meerdere partitiesleutels voor één tenant te gebruiken. Met een goed geplande partitioneringsstrategie wordt het Sharding-patroon geïmplementeerd. Met grote containers verspreidt Cosmos DB tenants over meerdere fysieke knooppunten om een hoge mate van schaal te bereiken.

Meer informatie:

Aanvraageenheden beheren

Cosmos DB prijsmodel is gebaseerd op het aantal aanvraageenheden per seconde dat u inrichten of verbruikt. Een aanvraageenheid is een logische abstractie van de kosten van een databasebewerking of query. Normaal gesproken moet u een gedefinieerd aantal aanvraageenheden per seconde inrichten voor uw workload, wat doorvoer wordt genoemd. Cosmos DB biedt verschillende opties voor het inrichten van doorvoer. In een multitenant-omgeving is de selectie die u maakt van invloed op de prestaties en prijs van uw Cosmos DB resources.

Eén tenancymodel voor Cosmos DB bestaat uit het implementeren van afzonderlijke containers voor elke tenant binnen een gedeelde database. Cosmos DB kunt u aanvraageenheden inrichten voor een database en alle containers delen de aanvraageenheden. Als uw tenantworkloads doorgaans niet overlappen, kan dit een handige benadering zijn om uw operationele kosten te verlagen. Houd er echter rekening mee dat deze aanpak vatbaar is voor het probleem Noisy Neighbor, omdat de container van één tenant mogelijk een onevenredige hoeveelheid van de gedeelde inrichtende aanvraageenheden verbruikt. Als u dit wilt verhelpen nadat u tenants met ruis hebt geïdentificeerd, kunt u eventueel inrichtende doorvoer instellen voor een specifieke container. De andere containers in de database blijven hun doorvoer delen, maar de tenant met ruis verbruikt zijn eigen toegewezen doorvoer.

Cosmos DB biedt ook een serverloze laag, die geschikt is voor werkbelastingen met af en toe of onvoorspelbaar verkeer. U kunt ook met automatische schaalbaarheid beleidsregels configureren om het schalen van de inrichtende doorvoer op te geven. In een oplossing met meerdere tenants kunt u al deze methoden combineren om verschillende typen tenants te ondersteunen.

Notitie

Bij het plannen van Cosmos DB configuratie, moet u rekening houden met de servicequota en -limieten.

Voor het bewaken en beheren van de kosten die aan elke tenant zijn gekoppeld, omvat elke bewerking met behulp van de Cosmos DB API de verbruikte aanvraageenheden. U kunt deze informatie gebruiken om de werkelijke aanvraageenheden te aggregeren en te vergelijken die door elke tenant worden verbruikt. Vervolgens kunt u tenants met verschillende prestatiekenmerken identificeren.

Meer informatie:

Door klant beheerde sleutels

Sommige tenants vereisen mogelijk het gebruik van hun eigen versleutelingssleutels. Cosmos DB biedt een door de klant beheerde sleutelfunctie. Deze functie wordt toegepast op het niveau van een Cosmos DB-account, zodat tenants die hun eigen versleutelingssleutels nodig hebben, moeten worden geïmplementeerd met behulp van toegewezen Cosmos DB accounts.

Meer informatie:

Isolatiemodellen

Wanneer u werkt met een multitenant-systeem dat gebruikmaakt van Azure Cosmos DB, moet u een beslissing nemen over het isolatieniveau dat u wilt gebruiken. Azure Cosmos DB ondersteunt verschillende isolatiemodellen:

Gedeelde containers met partitiesleutels per tenant Container met gedeelde doorvoer per tenant Container met toegewezen doorvoer per tenant Databaseaccount per tenant
Isolatieopties
  • Deel de doorvoer tussen tenants gegroepeerd per container (geweldig voor het verlagen van de kosten voor 'piekende' tenants).
  • Hiermee kunt u eenvoudige query's uitvoeren voor tenants (containers fungeren als grens voor query's). Een ruis radius van een neighbor-radius (tenants per container groeperen) beperken.
  • Deel de doorvoer tussen tenants die zijn gegroepeerd op database (dit is geweldig voor het verlagen van de kosten voor 'piek' tenants).
  • Eenvoudig beheer van tenants (de container laten vallen wanneer de tenant weggaat).
  • Verminder de ruis in de radius van de buren (groep tenants per database).
  • Onafhankelijke doorvoeropties (de toegewezen doorvoer elimineert ruisende buren).
  • Groepeert tenants binnen databaseaccounts, op basis van regionale behoeften.
  • Onafhankelijke geo-replicatieknoppen.
  • Meerdere doorvoeropties (de toegewezen doorvoer elimineert ruisende buren).
Vereisten voor doorvoer >0 RUs per tenant >100 RUs per tenant >400 RUs per tenant >400 RUs per tenant
Voorbeeld van een toepassing B2C-apps Standaardaanbieding voor B2B-apps Premium aanbieding voor B2B-apps Premium aanbieding voor B2B-apps

Gedeelde container met partitiesleutels per tenant

Wanneer u één container voor meerdere tenants gebruikt, kunt u gebruikmaken van Cosmos DB ondersteuning voor partitionering. Door afzonderlijke partitiesleutels voor elke tenant te gebruiken, kunt u eenvoudig een query uitvoeren op de gegevens voor één tenant. U kunt ook query's uitvoeren op meerdere tenants, zelfs als ze zich in afzonderlijke partities. Query's voor meerdere partities hebben echter hogere kosten voor aanvraageenheden (RU) dan query's met één partitie.

Deze aanpak werkt meestal goed wanneer de hoeveelheid gegevens die voor elke tenant is opgeslagen klein is. Het kan een goede keuze zijn voor het bouwen van een prijsmodel met een gratis laag en voor B2C-oplossingen (business-to-consumer). Over het algemeen bereikt u met behulp van gedeelde containers de hoogste dichtheid van tenants en dus de laagste prijs per tenant.

Het is belangrijk om rekening te houden met de doorvoer van uw container. Alle tenants delen de doorvoer van de container, zodat het probleem met ruis kan leiden tot prestatieproblemen als uw tenants hoge of overlappende workloads hebben. Dit probleem kan soms worden opgelost door subsets van tenants te groeperen in verschillende containers en door ervoor te zorgen dat elke tenantgroep compatibele gebruikspatronen heeft. U kunt ook een hybride model voor meerdere tenants en één tenant overwegen, waarbij kleinere tenants worden gegroepeerd in gedeelde gepartitiefde containers en grote klanten toegewezen containers hebben.

Het is ook belangrijk om rekening te houden met de hoeveelheid gegevens die u in elke logische partitie opgeslagen. Azure Cosmos DB logische partitie kan worden opgeteld tot 20 GB. Als u één tenant hebt die meer dan 20 GB aan gegevens moet opslaan, kunt u overwegen om de gegevens over meerdere logische partities te spreiden. In plaats van dat u bijvoorbeeld één partitiesleutel van hebt, kunt u de partitiesleutels salten door meerdere partitiesleutels te maken voor een tenant, zoals Contoso , Contoso1 Contoso2 enzovoort. Wanneer u de gegevens voor een tenant opvraagt, kunt u de -component gebruiken om overeen te WHERE IN komen met alle partitiesleutels. Hiërarchische partitiesleutels kunnen ook worden gebruikt ter ondersteuning van grote tenants.

Houd rekening met de operationele aspecten van uw oplossing en de verschillende fasen van de levenscyclus van de tenant. Wanneer een tenant bijvoorbeeld wordt verplaatst naar een toegewezen prijscategorie, moet u de gegevens waarschijnlijk verplaatsen naar een andere container. Wanneer deprovisioning van een tenant is verwijderd, moet u een verwijderquery uitvoeren op de container om de gegevens te verwijderen. Voor grote tenants kan deze query een aanzienlijke hoeveelheid doorvoer verbruiken terwijl deze wordt uitgevoerd.

Container per tenant

U kunt toegewezen containers inrichten voor elke tenant. Dit kan goed werken wanneer de gegevens die u voor uw tenant opgeslagen, kunnen worden gecombineerd tot één container.

Wanneer u een container voor elke tenant gebruikt, kunt u overwegen om doorvoer te delen met andere tenants door doorvoer in terichten op databaseniveau. Houd rekening met de beperkingen en limieten voor het minimum aantal aanvraageenheden voor uw database en het maximum aantal containers in de database. Bedenk ook of uw tenants een gegarandeerd prestatieniveau vereisen en of ze vatbaar zijn voor het probleem Noisy Neighbor. Plan zo nodig de groep van tenants in verschillende databases die zijn gebaseerd op workloadpatronen.

U kunt ook toegewezen doorvoer inrichten voor elke container. Dit werkt goed voor grotere tenants en voor tenants die risico lopen op het probleem ruisende buren. De basisdoorvoer voor elke tenant is echter hoger, dus houd rekening met de minimale vereisten en kosten van dit model.

Levenscyclusbeheer is over het algemeen eenvoudiger wanneer containers zijn toegewezen aan tenants. U kunt tenants eenvoudig verplaatsen tussengedeelde en toegewezen doorvoermodellen. Wanneer u deprovisioning van een tenant opzegt, kunt u de container snel verwijderen.

Databaseaccount per tenant

Cosmos DB kunt u afzonderlijke databaseaccounts inrichten voor elke tenant. Dit biedt het hoogste isolatieniveau, maar de laagste dichtheid. Eén databaseaccount is toegewezen aan een tenant, wat betekent dat ze niet onderhevig zijn aan het probleem met ruis. U kunt ook de locatie van het databaseaccount configureren op basis van de vereisten van de tenant en u kunt de configuratie van Cosmos DB-functies, zoals geo-replicatie en door de klant beheerde versleutelingssleutels, afstemmen op de vereisten van elke tenant. Wanneer u een toegewezen account Cosmos DB per tenant, moet u rekening houden met het maximum aantal Cosmos DB accounts per Azure-abonnement.

Als u toestaat dat tenants migreren van een gedeeld account naar een toegewezen Cosmos DB-account, kunt u de migratiebenadering overwegen die u gebruikt om de gegevens van een tenant tussen de oude en nieuwe accounts te verplaatsen.

Hybride benaderingen

U kunt een combinatie van de bovenstaande benaderingen overwegen om te voldoen aan de vereisten van verschillende tenants en uw prijsmodel. Bijvoorbeeld:

  • Alle gratis proefklanten inrichten binnen een gedeelde container en de tenant-id of een synthetische sleutelpartitiesleutel gebruiken.
  • Bied een betaalde bronslaag aan die een toegewezen container per tenant implementeert, maar met gedeelde doorvoer op een database.
  • Bied een hogere Silver-laag aan die toegewezen doorvoer in richt voor de container van de tenant.
  • Bied de hoogste Gold-laag aan en geef een toegewezen databaseaccount voor de tenant op, zodat tenants ook de geografie voor hun implementatie kunnen selecteren.

Volgende stappen

Bekijk Resources voor architecten en ontwikkelaars van multitenant-oplossingen.

  • Azure Cosmos DB en multitenant-systemen:een blogbericht met informatie over het bouwen van een multitenant-systeem dat gebruikmaakt van Azure Cosmos DB.
  • Multitenant-toepassingen met Azure Cosmos DB (video)
  • Een SaaS met meerderetenant bouwen met Azure Cosmos DB en Azure (video): een echte casestudie over hoe Whally, een multitenant SaaS-startup, een modern platform heeft gebouwd op Azure Cosmos DB en Azure. Hier ziet u de ontwerp- en implementatiebeslissingen die ze hebben genomen met betrekking tot partitionering, gegevensmodelleren, veilige multitenancy, prestaties, realtime streaming van de wijzigingsfeed naar SignalR, en meer, die allemaal gebruikmaken van ASP.NET Core op Azure-app Services.