Delen via

Multitenancy en Azure Cosmos DB

  • Artikel

In dit artikel worden de functies van Azure Cosmos DB beschreven die u kunt gebruiken voor multitenant-systemen. Het biedt richtlijnen en voorbeelden over het gebruik van Azure Cosmos DB in een multitenant-oplossing.

Multitenancyvereisten

Wanneer u een multitenant-oplossing plant, hebt u twee belangrijke vereisten:

  • Zorg voor een sterke isolatie tussen tenants en voldoen aan strenge beveiligingsvereisten voor degenen die ze nodig hebben.
  • Onderhoud een lage kosten per tenant. Als provider moet u ervoor zorgen dat de kosten voor het uitvoeren van de toepassing duurzaam blijven naarmate deze wordt geschaald.

Deze twee behoeften kunnen vaak conflicteren en een afweging veroorzaken waarbij u een andere prioriteit moet geven. De richtlijnen in dit artikel kunnen u helpen beter inzicht te krijgen in de afwegingen die u moet maken om aan deze behoeften te voldoen. Dit artikel helpt u bij het navigeren door deze overwegingen, zodat u weloverwogen beslissingen kunt nemen wanneer u uw multitenant-oplossing ontwerpt.

Isolatiemodellen

Bepaal het isolatieniveau dat u nodig hebt tussen uw tenants. Azure Cosmos DB ondersteunt een reeks isolatiemodellen, maar voor de meeste oplossingen raden we u aan een van de volgende strategieën te gebruiken:

  • Een partitiesleutel per tenant wordt vaak gebruikt voor volledig multitenant oplossingen, zoals business-to-consumer software as a service -oplossingen (B2C SaaS).
  • Een databaseaccount per tenant wordt vaak gebruikt voor SaaS-oplossingen (business-to-business) (B2B).

Als u het meest geschikte isolatiemodel wilt kiezen, moet u rekening houden met uw bedrijfsmodel en de vereisten van de tenants. Sterke prestatie-isolatie is bijvoorbeeld geen prioriteit voor sommige B2C-modellen waarbij een bedrijf een product of service rechtstreeks aan een individuele klant verkoopt. B2B-modellen kunnen echter prioriteit geven aan sterke beveiligings- en prestatieisolatie en vereisen dat tenants hun eigen ingerichte databaseaccount hebben.

U kunt ook meerdere modellen combineren om aan verschillende klantbehoeften te voldoen. Stel dat u een B2B SaaS-oplossing bouwt die u verkoopt aan zakelijke klanten en u een gratis proefversie biedt voor potentiële nieuwe klanten. U kunt een afzonderlijk databaseaccount implementeren voor betaalde enterprise-tenants die sterke garanties voor beveiliging en isolatie nodig hebben. En u kunt een databaseaccount delen en partitiesleutels gebruiken om proefklanten te isoleren.

Het model partition-key-per-tenant en het database-account-per-tenant-model zijn de meest voorkomende isolatiemodellen voor multitenant-oplossingen. Deze modellen bieden de beste balans tussen tenantisolatie en kostenefficiëntie.

Partition-key-per-tenant-model

Als u uw tenants op partitiesleutel isoleren, wordt de doorvoer gedeeld tussen tenants en beheerd binnen dezelfde container.

Notitie

Een aanvraageenheid (RU) is een logische abstractie van de kosten van een databasebewerking of query. Normaal gesproken richt u een gedefinieerd aantal aanvraageenheden per seconde (RU/s) in voor uw workload, wat wordt aangeduid als doorvoer.

Vergoedingen

  • Kostenefficiëntie: u plaatst alle tenants in één container, die wordt gepartitioneerd door de tenant-id. Deze benadering heeft slechts één factureerbare resource die RU's inricht en deelt tussen meerdere tenants. Dit model is meestal rendabeler en eenvoudiger te beheren dan het hebben van afzonderlijke accounts voor elke tenant.

  • Vereenvoudigd beheer: u hebt minder Azure Cosmos DB-accounts die u kunt beheren.

Afwegingen

  • Resourceconflict: gedeelde doorvoer (RU/s) tussen tenants die zich in dezelfde container bevinden, kan leiden tot conflicten tijdens piekgebruik. Deze conflicten kunnen problemen met ruis en prestatieproblemen veroorzaken als uw tenants hoge of overlappende workloads hebben. Gebruik dit isolatiemodel voor workloads die gegarandeerde RU's op één tenant nodig hebben en die doorvoer kunnen delen.

  • Beperkte isolatie: deze benadering biedt logische isolatie, niet fysieke isolatie. Het voldoet mogelijk niet aan strikte isolatievereisten vanuit het perspectief van prestaties of beveiliging.

  • Minder flexibiliteit: u kunt functies op accountniveau, zoals geo-replicatie, herstel naar een bepaald tijdstip en door de klant beheerde sleutels, niet aanpassen voor elke tenant als u isoleert op partitiesleutel of database of container.

Azure Cosmos DB-functies voor multitenancy

  • Uw doorvoer beheren: verken functies die u kunnen helpen bij het beheren van het probleem met ruis wanneer u een partitiesleutel gebruikt om tenants te isoleren. Gebruik functies zoals het opnieuw toewijzen van doorvoer, burstcapaciteit en doorvoerbeheer in de Java SDK.

  • Hiërarchische partitiesleutels: Gebruik Azure Cosmos DB, zodat elke logische partitie kan toenemen tot 20 GB. Als u één tenant hebt die meer dan 20 GB aan gegevens moet opslaan, kunt u overwegen de gegevens over meerdere logische partities te spreiden. In plaats van één partitiesleutel te Contosohebben, kunt u de partitiesleutels bijvoorbeeld distribueren door meerdere partitiesleutels te maken voor een tenant, zoals Contoso1 en Contoso2.

    Wanneer u gegevens opvraagt voor een tenant, kunt u de WHERE IN component gebruiken om alle partitiesleutels te vinden. U kunt ook hiërarchische partitiesleutels gebruiken om grote tenants opslag te bieden die groter is dan 20 GB als u een hoge kardinaliteit van tenants hebt. U hoeft geen synthetische partitiesleutels of meerdere partitiesleutelwaarden per tenant te gebruiken voor deze methode.

    Stel dat u een workload hebt waarmee tenants worden geïsoleerd op partitiesleutel. Eén tenant, Contoso, is groter en meer schrijfintensief dan andere, en blijft steeds groter. U kunt hiërarchische partitiesleutels gebruiken om te voorkomen dat u meer gegevens voor deze tenant kunt opnemen. Geef TenantID op als de eerste niveausleutel en voeg vervolgens een tweede niveau toe, zoals UserId. Als u verwacht dat de TenantID en UserID combinatie logische partities produceren die de limiet van 20 GB overschrijden, kunt u verder omlaag partitioneren naar een ander niveau, zoals SessionID. Query's die beide TenantID of beide TenantID opgeven en UserID effectief worden doorgestuurd naar alleen de subset van fysieke partities die de relevante gegevens bevatten, waardoor een volledige fan-outquery wordt voorkomen. Als de container 1000 fysieke partities heeft, maar een specifieke TenantId waarde zich slechts op vijf fysieke partities bevindt, wordt de query doorgestuurd naar het kleinere aantal relevante fysieke partities.

    Als uw eerste niveau onvoldoende kardinaliteit heeft en u de limiet voor logische partities van 20 GB voor uw partitiesleutel bereikt, kunt u overwegen een synthetische partitiesleutel te gebruiken in plaats van een hiërarchische partitiesleutel.

Database-account-per-tenantmodel

Als u uw tenants per databaseaccount isoleren, heeft elke tenant een eigen doorvoer die is ingericht op databaseniveau of containerniveau.

Vergoedingen

  • Hoge isolatie: Deze benadering voorkomt conflicten of interferentie vanwege toegewezen Azure Cosmos DB-accounts en -containers die RU's per unieke tenant hebben ingericht.

  • Aangepaste serviceovereenkomsten (SLA's): elke tenant heeft een eigen account, zodat u specifieke op maat gemaakte resources, klantgerichte SLA's en garanties kunt bieden, omdat u het databaseaccount van elke tenant onafhankelijk voor doorvoer kunt afstemmen.

  • Verbeterde beveiliging: fysieke gegevensisolatie zorgt voor robuuste beveiliging, omdat klanten door klanten beheerde sleutels op accountniveau per tenant kunnen inschakelen. De gegevens van elke tenant worden geïsoleerd door een account, in plaats van zich in dezelfde container te bevinden.

  • Flexibiliteit: Tenants kunnen functies op accountniveau inschakelen, zoals geo-replicatie, herstel naar een bepaald tijdstip en door de klant beheerde sleutels, indien nodig.

Afwegingen

  • Verhoogd beheer: deze benadering is complexer omdat u meerdere Azure Cosmos DB-accounts beheert.

  • Hogere kosten: Meer accounts betekenen dat u doorvoer moet inrichten voor elke resource, zoals databases of containers, binnen het account voor elke tenant. Telkens wanneer een resource RU's in richt, nemen uw Azure Cosmos DB-kosten toe.

  • Querybeperkingen: alle tenants bevinden zich in verschillende accounts, zodat toepassingen die query's uitvoeren op meerdere tenants meerdere aanroepen in de logica van de toepassing vereisen.

Azure Cosmos DB-functies voor multitenancy

  • Beveiligingsfuncties: Dit model biedt verbeterde isolatie van gegevenstoegang via Azure RBAC. Dit model biedt ook beveiligingsisolatie voor databaseversleuteling op tenantniveau via door de klant beheerde sleutels.

  • Aangepaste configuratie: U kunt de locatie van het databaseaccount configureren volgens de vereisten van de tenant. U kunt ook de configuratie van Azure Cosmos DB-functies, zoals geo-replicatie en door de klant beheerde versleutelingssleutels, afstemmen op de vereisten van elke tenant.

Wanneer u een toegewezen Azure Cosmos DB-account per tenant gebruikt, kunt u het maximum aantal Azure Cosmos DB-accounts per Azure-abonnement overwegen.

Volledige lijst met isolatiemodellen

Workload vereist Partitiesleutel per tenant (aanbevolen) Container per tenant (gedeelde doorvoer) Container per tenant (toegewezen doorvoer) Database per tenant Databaseaccount per tenant (aanbevolen)
Query's in tenants Eenvoudig (container fungeert als grens voor query's) Hard Hard Hard Hard
Tenantdichtheid Hoog (laagste kosten per tenant) Gemiddeld Beperkt Beperkt Beperkt
Verwijdering van tenantgegevens Eenvoudig Eenvoudig (container neerzetten wanneer de tenant vertrekt) Eenvoudig (container neerzetten wanneer de tenant vertrekt) Eenvoudig (database verwijderen wanneer de tenant vertrekt) Eenvoudig (database verwijderen wanneer de tenant vertrekt)
Beveiligingsisolatie voor gegevenstoegang Moet worden geïmplementeerd binnen de toepassing Container RBAC Container RBAC Database-RBAC RBAC
Geo-replicatie Geo-replicatie per tenant is niet mogelijk Tenants binnen databaseaccounts groeperen op basis van vereisten Tenants binnen databaseaccounts groeperen op basis van vereisten Tenants binnen databaseaccounts groeperen op basis van vereisten Tenants binnen databaseaccounts groeperen op basis van vereisten
Lawaaierige buurpreventie Nee Nee Ja Ja Ja
Latentie voor het maken van nieuwe tenants Direct Snel Snel Gemiddeld Langzaam
Voordelen van gegevensmodellering Geen Colocatie van entiteit Colocatie van entiteit Meerdere containers om tenantentiteiten te modelleren Meerdere containers en databases om tenants te modelleren
Encryptiesleutel Hetzelfde voor alle tenants Hetzelfde voor alle tenants Hetzelfde voor alle tenants Hetzelfde voor alle tenants Door de klant beheerde sleutel per tenant
Doorvoervereisten >0 RU's per tenant >100 RU's per tenant >100 RU's per tenant (met alleen automatisch schalen, anders >400 RU's per tenant) >400 RU's per tenant >400 RU's per tenant
Voorbeeld van een toepassing B2C-apps Standaardaanbieding voor B2B-apps Premium-aanbieding voor B2B-apps Premium-aanbieding voor B2B-apps Premium-aanbieding voor B2B-apps

Container-per-tenantmodel

U kunt toegewezen containers inrichten voor elke tenant. Toegewezen containers werken goed wanneer u de gegevens kunt combineren die u voor uw tenant opslaat in één container. Dit model biedt betere isolatie van prestaties dan het model partition-key-per-tenant. Het biedt ook verbeterde isolatie van gegevenstoegangsbeveiliging via Azure RBAC.

Wanneer u een container voor elke tenant gebruikt, kunt u overwegen om doorvoer met andere tenants te delen door doorvoer op databaseniveau in te richten. Houd rekening met de beperkingen en limieten voor het minimale aantal RU's voor uw database en het maximum aantal containers in de database. Overweeg ook of uw tenants een gegarandeerd prestatieniveau vereisen en of ze vatbaar zijn voor het probleem met ruis. Wanneer u doorvoer deelt op databaseniveau, moet de workload of opslag voor alle containers relatief uniform zijn. Anders hebt u mogelijk een probleem met ruis als u een of meer grote tenants hebt. Plan indien nodig deze tenants te groeperen in verschillende databases die zijn gebaseerd op workloadpatronen.

U kunt ook toegewezen doorvoer inrichten voor elke container. Deze aanpak werkt goed voor grotere tenants en voor tenants die risico lopen op het probleem met lawaaierige buren. Maar de basislijndoorvoer voor elke tenant is hoger, dus houd rekening met de minimale vereisten en kosteneffecten van dit model.

Als voor uw tenantgegevensmodel meer dan één entiteit is vereist en als alle entiteiten dezelfde partitiesleutel kunnen delen, kunt u deze in dezelfde container opnemen. Maar als het tenantgegevensmodel complexer is en entiteiten vereist die niet dezelfde partitiesleutel kunnen delen, kunt u de modellen database-per-tenant of database-account-per-tenant overwegen. Zie Model- en partitiegegevens in Azure Cosmos DB voor meer informatie.

Levenscyclusbeheer is over het algemeen eenvoudiger wanneer u containers toedraagt aan tenants. U kunt tenants eenvoudig verplaatsen tussen gedeelde en toegewezen doorvoermodellen. En wanneer u de inrichting van een tenant ongedaan hebt gemaakt, kunt u de container snel verwijderen.

Database-per-tenantmodel

U kunt databases inrichten voor elke tenant in hetzelfde databaseaccount. Net als het container-per-tenantmodel biedt dit model een betere isolatie van prestaties dan het model partition-key-per-tenant. Het biedt ook verbeterde isolatie van gegevenstoegangsbeveiliging via Azure RBAC.

Net als bij het account-per-tenantmodel biedt deze benadering het hoogste prestatie-isolatieniveau, maar biedt het de laagste tenantdichtheid. Gebruik deze optie als elke tenant een ingewikkelder gegevensmodel vereist dan haalbaar is in het container-per-tenantmodel. Of volg deze benadering als het maken van nieuwe tenants snel of zonder overhead vooraf moet zijn. Voor sommige frameworks voor softwareontwikkeling is het database-per-tenantmodel mogelijk het enige prestatie-isolatieniveau dat door het framework wordt ondersteund. Dergelijke frameworks bieden doorgaans geen ondersteuning voor isolatie op entiteitsniveau (container) en colocatie van entiteiten.

Functies van Azure Cosmos DB die ondersteuning bieden voor multitenancy

Partitionering

Gebruik partities met uw Azure Cosmos DB-containers om containers te maken die meerdere tenants delen. Doorgaans gebruikt u de tenant-id als partitiesleutel, maar u kunt ook overwegen om meerdere partitiesleutels voor één tenant te gebruiken. Een goed geplande partitioneringsstrategie implementeert effectief het Sharding-patroon. Wanneer u grote containers hebt, verspreidt Azure Cosmos DB uw tenants over meerdere fysieke knooppunten om een hoge schaal te bereiken.

Overweeg hiërarchische partitiesleutels om de prestaties van uw multitenant-oplossing te verbeteren. Gebruik hiërarchische partitiesleutels om een partitiesleutel te maken die meerdere waarden bevat. U kunt bijvoorbeeld een hiërarchische partitiesleutel gebruiken die de tenant-id bevat, zoals een GUID met hoge kardinaliteit, om bijna niet-afhankelijke schaal mogelijk te maken. U kunt ook een hiërarchische partitiesleutel opgeven die een eigenschap bevat die vaak wordt gebruikt. Deze aanpak helpt u bij het voorkomen van query's tussen partities. Gebruik hiërarchische partitiesleutels om te schalen buiten de limiet voor logische partities van 20 GB per partitiesleutelwaarde en om dure fan-outquery's te beperken.

Voor meer informatie raadpleegt u de volgende bronnen:

RU's beheren

Het prijsmodel van Azure Cosmos DB is gebaseerd op het aantal RU/s dat u inricht of verbruikt. Azure Cosmos DB biedt verschillende opties voor het inrichten van doorvoer. In een omgeving met meerdere tenants is uw selectie van invloed op de prestaties en prijs van uw Azure Cosmos DB-resources.

Voor tenants waarvoor gegarandeerde prestatie- en beveiligingsisolatie is vereist, raden we u aan tenants te isoleren per databaseaccount en RU's toe te wijzen aan de tenant. Voor tenants met minder strenge vereisten raden we u aan tenants te isoleren op basis van een partitiesleutel. Gebruik dit model om RU's te delen tussen uw tenants en de kosten per tenant te optimaliseren.

Een alternatief tenancymodel voor Azure Cosmos DB omvat het implementeren van afzonderlijke containers voor elke tenant in een gedeelde database. Gebruik Azure Cosmos DB om RU's in te richten voor een database, zodat alle containers de RU's delen. Als uw tenantworkloads doorgaans niet overlappen, kan deze aanpak helpen uw operationele kosten te verlagen. Deze benadering is echter vatbaar voor het probleem met ruis, omdat de container van één tenant een onevenredige hoeveelheid van de gedeelde ingerichte RU's verbruikt. Om dit probleem te verhelpen, moet u eerst de luidruchtige tenants identificeren. Vervolgens kunt u eventueel ingerichte doorvoer instellen voor een specifieke container. De andere containers in de database blijven hun doorvoer delen, maar de luidruchtige tenant verbruikt hun eigen toegewezen doorvoer.

Azure Cosmos DB biedt ook een serverloze laag, die geschikt is voor workloads met onregelmatig of onvoorspelbaar verkeer. U kunt ook automatisch schalen gebruiken om beleidsregels te configureren waarmee de schaal van ingerichte doorvoer wordt opgegeven. U kunt ook profiteren van azure Cosmos DB-burstcapaciteit om het gebruik van uw ingerichte doorvoercapaciteit te maximaliseren, wat anders wordt beperkt door frequentielimieten. In een multitenant-oplossing kunt u al deze benaderingen combineren om verschillende typen tenants te ondersteunen.

Notitie

Houd rekening met de servicequota en -limieten wanneer u uw Azure Cosmos DB-configuratie plant.

Als u de kosten wilt bewaken en beheren die aan elke tenant zijn gekoppeld, moet u er rekening mee houden dat elke bewerking die gebruikmaakt van de Azure Cosmos DB-API de verbruikte RU's bevat. U kunt deze informatie gebruiken om de werkelijke RU's te aggregeren en te vergelijken die elke tenant verbruikt. Vervolgens kunt u tenants identificeren die verschillende prestatiekenmerken hebben.

Voor meer informatie raadpleegt u de volgende bronnen:

Door klant beheerde sleutels

Voor sommige tenants is mogelijk het gebruik van hun eigen versleutelingssleutels vereist. Azure Cosmos DB biedt een door de klant beheerde sleutelfunctie. U past deze functie toe op het niveau van een Azure Cosmos DB-account. Dus als tenants hun eigen versleutelingssleutels vereisen, moet u toegewezen Azure Cosmos DB-accounts gebruiken om de tenants te implementeren.

Zie Door de klant beheerde sleutels configureren voor uw Azure Cosmos DB-account met Azure Key Vault voor meer informatie.

Medewerkers

Dit artikel wordt onderhouden door Microsoft. De tekst is oorspronkelijk geschreven door de volgende Inzenders.

Belangrijkste auteurs:

Andere Inzenders:

Als u niet-openbare LinkedIn-profielen wilt zien, meldt u zich aan bij LinkedIn.

Volgende stappen

Meer informatie over multitenancy en Azure Cosmos DB:

Raadpleeg enkele van onze andere architectuurscenario's van Azure Cosmos DB: