Dela via

Multitenans och Azure Cosmos DB

  • Artikel

I den här artikeln beskrivs funktioner i Azure Cosmos DB som du kan använda för system med flera klientorganisationer. Den innehåller vägledning och exempel på hur du använder Azure Cosmos DB i en lösning med flera klientorganisationer.

Krav för flera innehavare

När du planerar en lösning för flera klientorganisationer har du två viktiga krav:

  • Hjälp till att säkerställa stark isolering mellan klienter och uppfylla stränga säkerhetskrav för dem som behöver dem.
  • Underhåll en låg kostnad per hyresgäst. Som provider ser du till att kostnaden för att köra programmet förblir hållbar allt eftersom den skalar.

Dessa två behov kan ofta vara motstridiga och leda till en kompromiss där du måste prioritera det ena framför det andra. Vägledningen i den här artikeln kan hjälpa dig att bättre förstå de kompromisser som du måste göra för att uppfylla dessa behov. Den här artikeln hjälper dig att navigera i dessa överväganden så att du kan fatta välgrundade beslut när du utformar din lösning för flera klienter.

Isoleringsmodeller

Fastställ den isoleringsnivå som du behöver mellan dina klienter. Azure Cosmos DB stöder en rad olika isoleringsmodeller, men för de flesta lösningar rekommenderar vi att du använder någon av följande strategier:

  • En partitionsnyckel per klient används ofta för helt multitenantlösningar, till exempel B2C SaaS-lösningar (programvara som en tjänst från företag till konsument).
  • Ett databaskonto per klientorganisation används ofta för SaaS-lösningar (business-to-business) (B2B).

Om du vill välja den lämpligaste isoleringsmodellen bör du överväga din affärsmodell och klientorganisationens krav. Stark prestandaisolering kanske till exempel inte är en prioritet för vissa B2C-modeller där ett företag säljer en produkt eller tjänst direkt till en enskild kund. B2B-modeller kan dock prioritera stark säkerhets- och prestandaisolering och kan kräva att klientorganisationer har ett eget etablerat databaskonto.

Du kan också kombinera flera modeller för att passa olika kundbehov. Anta till exempel att du skapar en B2B SaaS-lösning som du säljer till företagskunder och ger en kostnadsfri utvärderingsversion för potentiella nya kunder. Du kan distribuera ett separat databaskonto för betalda företagskunder som behöver starkt säkerhets- och isoleringsskydd. Och du kan dela ett databaskonto och använda partitionsnycklar för att isolera utvärderingskunder.

Modellen partition-key-per-tenant och modellen database-account-per-tenant är de vanligaste isoleringsmodellerna för lösningar för flera klienter. Dessa modeller ger den bästa balansen mellan klientisolering och kostnadseffektivitet.

Partitionsnyckel-per-hyresgäst-modell

Om du isolerar dina klienter efter partitionsnyckel delas dataflödet mellan klienter och hanteras i samma container.

Kommentar

En begärandeenhet (RU) är en logisk abstraktion av kostnaden för en databasåtgärd eller fråga. Vanligtvis etablerar du ett definierat antal begärarenheter per sekund (RU/s) för din arbetsbelastning, och detta kallas genomströmning.

Förmåner

  • Kostnadseffektivitet: Du placerar alla hyresgäster i en container, som partitioneras efter hyresgäst-ID:t. Den här metoden har bara en fakturerbar resurs som tillhandahåller och delar RU:er mellan flera hyresgäster. Den här modellen är vanligtvis mer kostnadseffektiv och enklare att hantera än att ha separata konton för varje klientorganisation.

  • Förenklad hantering: Du har färre Azure Cosmos DB-konton att hantera.

Kompromisser

  • Resurskonkurrens: Delat dataflöde (RU/s) mellan klienter som finns i samma container kan leda till konkurrens under hög användning. Den här konkurrensen kan skapa bullriga grannproblem och prestandautmaningar om dina klienter har höga eller överlappande arbetsbelastningar. Använd den här isoleringsmodellen för arbetsbelastningar som behöver garanterade RU:er på en enda klientorganisation och som kan dela dataflöde.

  • Begränsad isolering: Den här metoden ger logisk isolering, inte fysisk isolering. Det kanske inte uppfyller strikta isoleringskrav ur ett prestanda- eller säkerhetsperspektiv.

  • Mindre flexibilitet: Du kan inte anpassa funktioner på kontonivå, till exempel geo-replikering, återställning till en viss tidpunkt och kundhanterade nycklar, för varje klientorganisation om du isolerar efter partitionsnyckel eller efter databas eller container.

Azure Cosmos DB-funktioner för flera klientorganisationer

  • Kontrollera dataflödet: Utforska funktioner som kan hjälpa dig att kontrollera problemet med den bullriga grannen när du använder en partitionsnyckel för att isolera klienter. Använd funktioner som omfördelning av dataflöde, burst-kapacitet och dataflödeskontroll i Java SDK.

  • Hierarkiska partitionsnycklar: Använd Azure Cosmos DB så att varje logisk partition kan öka i storlek upp till 20 GB. Om du har en enda klientorganisation som behöver lagra mer än 20 GB data kan du överväga att sprida data över flera logiska partitioner. I stället för att till exempel ha en enda partitionsnyckel på Contosokan du distribuera partitionsnycklarna genom att skapa flera partitionsnycklar för en klientorganisation, till exempel Contoso1 och Contoso2.

    När du frågar efter data för en hyresgäst kan du använda WHERE IN-satsen för att matcha alla partitionsnycklar. Du kan också använda hierarkiska partitionsnycklar för att ge stora klienter lagring större än 20 GB om du har hög kardinalitet för klienter. Du behöver inte använda syntetiska partitionsnycklar eller flera partitionsnyckelvärden per klientorganisation för den här metoden.

    Anta att du har en belastning som isolerar hyresgäster efter partitionsnyckel. En klientorganisation, Contoso, är större och mer skrivintensiv än andra, och den fortsätter att växa. För att undvika risken för att inte kunna mata in mer data för den här klientorganisationen kan du använda hierarkiska partitionsnycklar. Ange TenantID som den första nivånyckeln och lägg sedan till en andra nivå som UserId. Om du förväntar TenantID dig att kombinationen och UserID ska generera logiska partitioner som överskrider gränsen på 20 GB kan du partitionera längre ned till en annan nivå, till exempel SessionID. Frågor som anger antingen TenantID eller båda TenantID och UserID dirigeras effektivt till endast den delmängd av fysiska partitioner som innehåller relevanta data, vilket undviker en fullständig utsöndrad fråga. Om containern har 1 000 fysiska partitioner men ett specifikt TenantId värde bara finns på fem fysiska partitioner dirigeras frågan till det mindre antalet relevanta fysiska partitioner.

    Om den första nivån inte har tillräckligt hög kardinalitet och du når gränsen på 20 GB logisk partition på partitionsnyckeln kan du överväga att använda en syntetisk partitionsnyckel i stället för en hierarkisk partitionsnyckel.

Databas-konto-per-klientmodell

Om du isolerar dina hyresgäster med hjälp av databaskonton har varje hyresgäst sin egen kapacitet etablerad på databasnivå eller containernivå.

Förmåner

  • Hög isolering: Den här metoden undviker konkurrens eller interferens på grund av dedikerade Azure Cosmos DB-konton och containrar som har etablerat RU:er per unik klientorganisation.

  • Anpassade serviceavtal (SLA): Varje klientorganisation har ett eget konto, så att du kan tillhandahålla specifika skräddarsydda resurser, kundriktade serviceavtal och garantier eftersom du kan justera varje klients databaskonto oberoende av dataflöde.

  • Förbättrad säkerhet: Fysisk dataisolering säkerställer robust säkerhet eftersom kunder kan aktivera kundhanterade nycklar på kontonivå per klientorganisation. Varje användares data är isolerad per konto istället för att vara i samma container.

  • Flexibilitet: Hyresgäster kan aktivera funktioner på kontonivå som geo-replikering, återställning till tidpunkt och kundhanterade nycklar efter behov.

Kompromisser

  • Ökad hantering: Den här metoden är mer komplex eftersom du hanterar flera Azure Cosmos DB-konton.

  • Högre kostnader: Fler konton innebär att du måste etablera dataflöde för varje resurs, till exempel databaser eller containrar, i kontot för varje klientorganisation. Varje gång en resurs etablerar RU:er ökar dina Azure Cosmos DB-kostnader.

  • Frågebegränsningar: Alla hyresgäster finns i olika konton, så program som ställer frågor till flera hyresgäster kräver flera anrop i programmets logik.

Azure Cosmos DB-funktioner för flera klientorganisationer

  • Säkerhetsfunktioner: Den här modellen ger ökad säkerhetsisolering av dataåtkomst via Azure RBAC. Den här modellen tillhandahåller även säkerhetsisolering av databaskryptering på klientnivå via kundhanterade nycklar.

  • Anpassad konfiguration: Du kan konfigurera platsen för databaskontot enligt klientorganisationens krav. Du kan också justera konfigurationen av Azure Cosmos DB-funktioner, till exempel geo-replikering och kundhanterade krypteringsnycklar, så att de passar varje klientorganisations krav.

När du använder ett dedikerat Azure Cosmos DB-konto per klientorganisation bör du överväga det maximala antalet Azure Cosmos DB-konton per Azure-prenumeration.

Fullständig lista över isoleringsmodeller

Arbetsbelastningsbehov Partitionsnyckel per användare (rekommenderas) Container per klient (delat dataflöde) Container per klient (dedikerat dataflöde) Databas per hyresgäst Databaskonto per klientorganisation (rekommenderas)
Förfrågningar mellan klienter Enkelt (containern fungerar som gräns för frågor) Hårt Hård Fast Hård
Hyresgästtäthet Hög (lägsta kostnad per hyresgäst) Medium Låg Låg Låg
Borttagning av klientdata Enkelt Enkelt (avsluta container när hyresgästen flyttar) Enkelt (dumpa container när hyresgästen lämnar) Enkelt (radera databasen när hyresgästen lämnar) Enkelt (ta bort databasen när hyresgästen lämnar)
Säkerhetsisolering för dataåtkomst Behöver implementeras i programmet Container RBAC Container RBAC Databas-RBAC RBAC
Geo-replikering Geo-replikering per klientorganisation är inte möjlig Gruppera användare i databaskonton baserat på krav Gruppera hyresgäster inom databaskonton baserat på krav Gruppera hyresgäster inom databaskonton baserat på kraven Gruppera hyresgäster inom databaskonton utifrån krav
Förebyggande av bullriga grannar Nej Nej Ja Ja Ja
Svarstid för skapande av ny hyresgäst Omedelbara Snabbt Snabbt Medel Långsam
Fördelar med datamodellering Ingen Entitetssamlokalisering Entitetssamlokalisering Flera containrar för att modellera kliententiteter Flera containrar och databaser för att modellera hyresgäster
Krypteringsnyckel Samma för alla klienter Samma för alla klienter Samma för alla klienter Samma för alla klienter Kundhanterad nyckel per klientorganisation
Dataflödeskrav >0 RU per klientorganisation >100 RUs per hyresgäst >100 RUs per hyresgäst (med endast automatiserad skalning, annars >400 RUs per hyresgäst) >400 RUs per hyresgäst >400 RU:er per klientorganisation
Exempel på användningsfall B2C-appar Standarderbjudande för B2B-appar Premium-erbjudande för B2B-appar Premium-erbjudande för B2B-appar Premium-erbjudande för B2B-appar

Container-per-tenant-modell

Du kan etablera dedikerade containrar för varje klientorganisation. Dedikerade containrar fungerar bra när du kan kombinera data som du lagrar för din klientorganisation till en enda container. Den här modellen ger bättre prestandaisolering än modellen partition-key-per-tenant. Det ger också ökad säkerhetsisolering av dataåtkomst via Azure RBAC.

När du använder en container för varje klient, överväg att dela kapacitet med andra klienter genom att tillhandahålla kapacitet på databasnivå. Överväg begränsningarna och gränserna för det minsta antalet RU:er för databasen och det maximala antalet containrar i databasen. Tänk också på om dina klienter kräver en garanterad prestandanivå och om de är mottagliga för det bullriga granneproblemet. När du delar dataflöde på databasnivå bör arbetsbelastningen eller lagringen för alla containrar vara relativt enhetlig. Annars kan du ha problem med en bullrig granne om du har en eller flera stora klienter. Om det behövs planerar du att gruppera dessa klienter i olika databaser som baseras på arbetsbelastningsmönster.

Du kan också etablera dedikerat dataflöde för varje container. Den här metoden fungerar bra för större klienter och för klienter som riskerar att drabbas av problem med bullriga grannar. Men basflödet för varje hyresgäst är högre, så överväg minimikraven och kostnadskonsekvenserna för den här modellen.

Om din klientdatamodell kräver mer än en entitet, och om alla entiteter kan dela samma partitionsnyckel, kan du samplacera dem i samma container. Men om klientdatamodellen är mer komplex och kräver entiteter som inte kan dela samma partitionsnyckel bör du överväga modellerna database-per-tenant eller database-account-per-tenant. Mer information finns i Modell- och partitionsdata i Azure Cosmos DB.

Livscykelhantering är vanligtvis enklare när du dedikerar containrar till klientorganisationer. Du kan enkelt flytta hyresgäster mellan delade och dedikerade kapacitetsmodeller. Och när du avvecklar en klientorganisation kan du snabbt ta bort containern.

Modell med en databas per klient

Du kan etablera databaser för varje klientorganisation i samma databaskonto. Precis som container-per-klient-modellen ger den här modellen större prestandaisolering än modellen partition-key-per-tenant. Det ger också ökad säkerhetsisolering av dataåtkomst via Azure RBAC.

På samma sätt som konto-per-klient-modellen ger den här metoden den högsta nivån av prestandaisolering, men den ger den lägsta klienttätheten. Använd det här alternativet om varje klientorganisation kräver en mer komplicerad datamodell än vad som är möjligt i container-per-klient-modellen. Eller följ den här metoden om skapandet av en ny hyresgäst måste ske snabbt eller utan några initiala kostnader. För vissa ramverk för programutveckling kan modellen database-per-tenant vara den enda nivån av prestandaisolering som ramverket stöder. Sådana ramverk stöder vanligtvis inte isolering på entitetsnivå (container) och entitetssamlokalisering.

Funktioner i Azure Cosmos DB som stöder flera klientorganisationer

Partitionering

Använd partitioner med dina Azure Cosmos DB-containrar för att skapa containrar som flera klienter delar. Vanligtvis använder du klientidentifieraren som en partitionsnyckel, men du kan också överväga att använda flera partitionsnycklar för en enda klientorganisation. En välplanerad partitioneringsstrategi implementerar effektivt Sharding-mönstret. När du har stora containrar sprider Azure Cosmos DB dina klienter över flera fysiska noder för att uppnå en hög grad av skala.

Överväg hierarkiska partitionsnycklar för att förbättra prestandan för multitenantlösningen. Använd hierarkiska partitionsnycklar för att skapa en partitionsnyckel som innehåller flera värden. Exempelvis kan du använda en hierarkisk partitionsnyckel som innehåller klientidentifieraren, såsom ett GUID med hög kardinalitet, för att tillåta nästan obegränsad skalning. Du kan också ange en hierarkisk partitionsnyckel som inkluderar en egenskap som ofta används i frågor. Den här metoden hjälper dig att undvika frågeoperationer mellan partitioner. Använd hierarkiska partitionsnycklar för att skala bortom den logiska partitionsgränsen på 20 GB per partitionsnyckelvärde och begränsa dyra förgreningsfrågor.

Mer information finns i följande resurser:

Hantera RUs

Prismodellen för Azure Cosmos DB baseras på antalet RU/s som du etablerar eller använder. Azure Cosmos DB innehåller flera alternativ för att etablera dataflöde. I en miljö med flera klientorganisationer påverkar ditt val prestanda och pris för dina Azure Cosmos DB-resurser.

För hyresgäster som kräver garanterad prestanda och säkerhetsisolering rekommenderar vi att du isolerar hyresgästerna efter databaskonto och allokerar RU:er till hyresgästen. För hyresgäster som har mindre stränga krav rekommenderar vi att du isolerar hyresgäster genom partitionsnyckel. Använd den här modellen för att dela RU mellan dina hyresgäster och optimera kostnaden per hyresgäst.

En alternativ innehavarmodell för Azure Cosmos DB omfattar distribution av separata containrar för varje klientorganisation i en delad databas. Använd Azure Cosmos DB för att etablera RU:er för en databas så att alla containrar delar ru:erna. Om dina klientarbetsbelastningar vanligtvis inte överlappar varandra kan den här metoden bidra till att minska driftskostnaderna. Men den här metoden är känslig för problemet med den bullriga grannen eftersom en enskild klients container kan förbruka en oproportionerlig mängd av de delade etablerade RU:erna. Du kan åtgärda det här problemet genom att först identifiera de bullriga klienterna. Sedan kan du valfritt ange tilldelad bandbredd för en specifik container. De andra containrarna i databasen fortsätter att dela sin genomströmning, men den högljudda hyresgästen förbrukar sin egen dedikerade genomströmning.

Azure Cosmos DB tillhandahåller också en serverlös nivå som passar arbetsbelastningar som har tillfällig eller oförutsägbar trafik. Du kan också använda automatisk skalning för att konfigurera principer som anger skalning av etablerat dataflöde. Du kan också dra nytta av Azure Cosmos DB-burstkapaciteten för att maximera användningen av din etablerade dataflödeskapacitet, som annars begränsas av hastighetsbegränsningar. I en lösning med flera klienter kan du kombinera alla dessa metoder för att stödja olika typer av klienter.

Anteckning

När du planerar din Azure Cosmos DB-konfiguration bör du överväga tjänstkvoter och -gränser.

Om du vill övervaka och hantera de kostnader som är associerade med varje klientorganisation bör du komma ihåg att varje åtgärd som använder Azure Cosmos DB-API:et innehåller de förbrukade RU:erna. Du kan använda den här informationen för att aggregera och jämföra de faktiska RU:er som varje klientorganisation förbrukar. Du kan sedan identifiera klienter som har olika prestandaegenskaper.

Mer information finns i följande resurser:

Kundhanterade nycklar

Vissa klienter kan behöva använda sina egna krypteringsnycklar. Azure Cosmos DB tillhandahåller en kundhanterad nyckelfunktion. Du använder den här funktionen på nivån för ett Azure Cosmos DB-konto. Om klienterna behöver sina egna krypteringsnycklar måste du använda dedikerade Azure Cosmos DB-konton för att hantera dem.

Mer information finns i Konfigurera kundhanterade nycklar för ditt Azure Cosmos DB-konto med Azure Key Vault.

Deltagare

Den här artikeln underhålls av Microsoft. Det har ursprungligen skrivits av följande medarbetare.

Huvudsakliga författare:

Övriga medarbetare:

Om du vill se icke-offentliga LinkedIn-profiler loggar du in på LinkedIn.

Nästa steg

Läs mer om flera klientorganisationer och Azure Cosmos DB:

Se några av våra andra arkitekturscenarier i Azure Cosmos DB: