Dela via

Flera klientorganisationer och Azure Cosmos DB

  • Artikel

På den här sidan beskriver vi några av funktionerna i Azure Cosmos DB som är användbara när du arbetar med system med flera klientorganisationer. Vi länkar även till vägledning och exempel för hur du använder Azure Cosmos DB i en lösning med flera klientorganisationer.

Funktioner i Azure Cosmos DB som stöder flera klientorganisationer

Partitionering

Genom att använda partitioner med dina Azure Cosmos DB-containrar kan du skapa containrar som delas mellan flera klienter. 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 horisontell partitioneringsmönstret. Med stora containrar sprider Azure Cosmos DB dina klienter över flera fysiska noder för att uppnå en hög grad av skala.

Vi rekommenderar att du utforskar användningen av hierarkiska partitionsnycklar för att förbättra prestanda för multitenantlösningen. Med hierarkiska partitionsnycklar kan du skapa en partitionsnyckel som innehåller flera värden. Du kan till exempel använda en hierarkisk partitionsnyckel som innehåller klientidentifieraren och den typ av data som du lagrar. Med den här metoden kan du skala över den logiska partitionsgränsen på 20 GB per partitionsnyckelvärde.

Mer information:

Hantera enheter för begäranden

Prismodellen för Azure Cosmos DB baseras på antalet enheter för begäranden per sekund som du etablerar eller använder. En begärandeenhet är en logisk abstraktion av kostnaden för en databasåtgärd eller fråga. Vanligtvis etablerar du ett definierat antal enheter för begäranden per sekund för din arbetsbelastning, vilket kallas dataflöde. Azure Cosmos DB innehåller flera alternativ för hur du etablerar dataflöde. I en miljö med flera klientorganisationer påverkar valet du gör prestanda och pris för dina Azure Cosmos DB-resurser.

En innehavarmodell för Azure Cosmos DB omfattar distribution av separata containrar för varje klientorganisation i en delad databas. Med Azure Cosmos DB kan du etablera enheter för begäranden för en databas och alla containrar delar enheter för begäran. Om dina klientarbetsbelastningar vanligtvis inte överlappar varandra kan den här metoden bidra till att minska driftskostnaderna. Den här metoden är dock känslig för problemet Med bullrig granne eftersom en enskild klients container kan förbruka en oproportionerlig mängd av de delade etablerade enheter för begäranden. Åtgärda problemet genom att först identifiera de bullriga klienterna. Sedan kan du ange etablerat dataflöde på en specifik container. De andra containrarna i databasen fortsätter att dela sitt dataflöde, men den bullriga klientorganisationen förbrukar sitt eget dedikerade dataflöde.

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

Kommentar

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

För att övervaka och hantera de kostnader som är associerade med varje klientorganisation innehåller varje åtgärd som använder Azure Cosmos DB-API:et de enheter för begärande som förbrukas. Du kan använda den här informationen för att aggregera och jämföra de faktiska enheter för begäran som förbrukas av varje klientorganisation, och du kan sedan identifiera klienter med olika prestandaegenskaper.

Mer information:

Kundhanterade nycklar

Vissa klienter kan behöva använda sina egna krypteringsnycklar. Azure Cosmos DB tillhandahåller en kundhanterad nyckelfunktion. Den här funktionen tillämpas på nivån för ett Azure Cosmos DB-konto, så klienter som behöver egna krypteringsnycklar måste distribueras med hjälp av dedikerade Azure Cosmos DB-konton.

Mer information:

Isoleringsmodeller

När du arbetar med ett system med flera klientorganisationer som använder Azure Cosmos DB måste du fatta ett beslut om vilken isoleringsnivå du vill använda. B2B avser försäljning till ett företag. B2C avser försäljning direkt till en enskild kund som använder produkten eller tjänsten. Azure Cosmos DB stöder flera isoleringsmodeller:

Arbetsbelastningsbehov Partitionsnyckel per klientorganisation Container per klient (delat dataflöde) Container per klient (dedikerat dataflöde) Databas per klient Databaskonto per klientorganisation
Frågor mellan klienter Enkelt (containern fungerar som gräns för frågor) Fast Fast Fast Fast
Klientorganisationsdensitet Hög (lägsta kostnad per klientorganisation) Medium Låg Låg Låg
Borttagning av klientdata Fast Enkelt (släpp container när klientorganisationen lämnar) Enkelt (släpp container när klientorganisationen lämnar) Enkelt (ta bort databasen när klientorganisationen lämnar) Enkelt (ta bort databasen när klientorganisationen lämnar)
Säkerhetsisolering för dataåtkomst Måste implementeras i programmet Container RBAC Container RBAC Databas-RBAC RBAC
Geo-replikering Geo-replikering per klientorganisation är inte möjlig Gruppera klientorganisationer i databaskonton baserat på krav Gruppera klientorganisationer i databaskonton baserat på krav Gruppera klientorganisationer i databaskonton baserat på krav Gruppera klientorganisationer i databaskonton baserat på krav
Förebyggande av bullriga grannar Ingen Ingen Ja Ja Ja
Svarstid för skapande av ny klientorganisation Omedelbara Snabbt Snabbt Medium Långsam
Fördelar med datamodellering Ingen entitetssamlokalisering entitetssamlokalisering Flera containrar för att modellera kliententiteter Flera containrar och databaser för att modellera klientorganisationer
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:er per klientorganisation >100 RU:er per klientorganisation >100 RU:er per klientorganisation (endast med autoskalning, annars >400 RU:er per klientorganisation) >400 RU:er per klientorganisation >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

Partitionsnyckel per klientorganisation

När du använder en enda container för flera klientorganisationer kan du använda azure Cosmos DB-partitioneringsstöd. Genom att använda separata partitionsnycklar för varje klientorganisation kan du enkelt köra frågor mot data för en enda klientorganisation. Du kan också fråga mellan flera klienter, även om de finns i separata partitioner. Frågor mellan partitioner har dock en högre ru-kostnad (request unit) än frågor med en partition.

Den här metoden tenderar att fungera bra när mängden data som lagras för varje klientorganisation är liten. Det kan vara ett bra val för att skapa en prismodell som innehåller en kostnadsfri nivå och B2C-lösningar (business-to-consumer). Genom att använda delade containrar uppnår du i allmänhet den högsta tätheten av klienter och därmed det lägsta priset per klientorganisation.

Det är viktigt att tänka på dataflödet för din container. Alla klienter delar containerns dataflöde, så problemet med den bullriga grannen kan orsaka prestandautmaningar om dina klienter har höga eller överlappande arbetsbelastningar. Det här problemet kan ibland åtgärdas genom att gruppera delmängder av klienter i olika containrar och genom att se till att varje klientgrupp har kompatibla användningsmönster. Du kan också överväga en hybridmodell för flera och enstaka klientorganisationer. Gruppera mindre klienter i delade partitionerade containrar och ge stora kunder dedikerade containrar. Det finns också funktioner som kan hjälpa till att styra det bullriga grannproblemet när klientorganisationen modelleras efter partition, till exempel omallokering av dataflöde, burstkapacitet och dataflödeskontroll i Java SDK.

Det är också viktigt att tänka på mängden data som du lagrar i varje logisk partition. Med Azure Cosmos DB kan varje logisk partition växa till 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 salta partitionsnycklarna genom att skapa flera partitionsnycklar för en klientorganisation, till Contoso1exempel , Contoso2och så vidare. När du frågar efter data för en klientorganisation kan du använda WHERE IN -satsen för att matcha alla partitionsnycklar. Hierarkiska partitionsnycklar kan också användas för att stödja stora klienter, med lagring som är större än 20 GB, utan att du behöver använda syntetiska partitionsnycklar eller flera partitionsnyckelvärden per klientorganisation.

Tänk på de operativa aspekterna av din lösning och de olika faserna i klientorganisationens livscykel. När en klientorganisation till exempel flyttas till en dedikerad prisnivå behöver du förmodligen flytta data till en annan container. När en klientorganisation avetableras måste du köra en borttagningsfråga på containern för att ta bort data, och för stora klienter kan den här frågan förbruka en betydande mängd dataflöde medan den körs.

Container per klientorganisation

Du kan etablera dedikerade containrar för varje klientorganisation. Dedikerade containrar fungerar bra när de data som du lagrar för din klientorganisation kan kombineras till en enda container. Den här modellen ger bättre prestandaisolering än modellen partition-key-per-tenant ovan, och den ger även ökad dataåtkomstsäkerhetsisolering via Azure RBAC.

När du använder en container för varje klientorganisation kan du överväga att dela dataflöde med andra klienter genom att etablera dataflöde på databasnivå. Överväg begränsningarna och begränsningarna kring det minsta antalet enheter för begäran 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 problemet Med bullriga grannar. 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 det finns 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 den bullriga grannen. Baslinjedataflödet för varje klientorganisation är dock högre, så tänk på minimikraven och kostnadskonsekvenserna för den här modellen.

Om din klientdatamodell kräver mer än en entitet, så länge alla entiteter kan dela samma partitionsnyckel, kan de samplaceeras 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 nedan. Ta en titt på vår artikel om hur du modellerar och partitioner data i Azure Cosmos DB med hjälp av ett verkligt exempel för mer vägledning.

Livscykelhantering är vanligtvis enklare när containrar är dedikerade till klientorganisationer. Du kan enkelt flytta klientorganisationer mellan delade och dedikerade dataflödesmodeller, och när du avetablerar en klientorganisation kan du snabbt ta bort containern.

Databas per klient

Du kan etablera databaser för varje klientorganisation i samma databaskonto. Precis som container-per-klient-modellen ovan ger den här modellen bättre prestandaisolering än modellen partition-key-per-tenant, och den ger även ökad dataåtkomstsäkerhetsisolering via Azure RBAC.

Precis som modellen för konto per klientorganisation nedan ger den här metoden den högsta nivån av prestandaisolering, men den ger den lägsta klienttätheten. Det här alternativet är dock bäst när varje klientorganisation kräver en mer komplicerad datamodell än vad som är möjligt i container-per-klient-modellen. Eller så bör du följa den här metoden när det är ett krav för att ny klientorganisation ska kunna skapas snabbt och/eller utan kostnader för att skapa klientkonton i förväg. För det specifika ramverket för programvaruutveckling som används kan det också vara så att databas per klientorganisation är den enda prestandaisoleringsnivå som identifieras i det ramverket. Isolering på entitetsnivå (container) och entitetssamlokalisering stöds vanligtvis inte internt i sådana ramverk.

Databaskonto per klientorganisation

Med Azure Cosmos DB kan du etablera separata databaskonton för varje klientorganisation, vilket ger den högsta isoleringsnivån, men den lägsta densiteten. Precis som modellerna container-per-tenant och database-per-tenant ovan ger den här modellen större prestandaisolering än nyckelmodellen partition-key-per-tenant. Det ger också ökad säkerhetsisolering av dataåtkomst via Azure RBAC. Dessutom tillhandahåller den här modellen säkerhetsisolering av databaskryptering på klientnivå via kundhanterade nycklar.

Ett enskilt databaskonto är dedikerat till en klientorganisation, vilket innebär att de inte omfattas av problemet med den bullriga grannen. Du kan konfigurera platsen för databaskontot enligt klientens 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.

Om du använder den här modellen bör du överväga hur snabbt programmet behöver kunna generera nya klienter. Det kan ta några minuter att skapa ett konto i Azure Cosmos DB, så du kan behöva skapa konton i förväg. Om den här metoden inte är möjlig bör du överväga modellen database-per-tenant.

Om du tillåter att klientorganisationer migrerar från ett delat konto till ett dedikerat Azure Cosmos DB-konto bör du överväga den migreringsmetod som du använder för att flytta en klients data mellan de gamla och nya kontona.

Hybridmetoder

Du kan överväga en kombination av ovanstående metoder för att passa olika klientorganisationers krav och din prismodell. Till exempel:

  • Etablera alla kostnadsfria utvärderingskunder i en delad container och använd klientorganisations-ID:t eller en syntetisk nyckelpartitionsnyckel.
  • Erbjud en betald bronsnivå som distribuerar en dedikerad container per klientorganisation, men med delat dataflöde i en databas.
  • Erbjud en högre Silver-nivå som etablerar dedikerat dataflöde för klientorganisationens container.
  • Erbjud den högsta guldnivån och ange ett dedikerat databaskonto för klientorganisationen, vilket också gör det möjligt för klientorganisationer att välja geografi för distributionen.

Deltagare

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

Huvudsakliga författare:

  • Paul Burpo | Huvudkundtekniker, FastTrack för Azure
  • John Downs | Huvudkundtekniker, FastTrack för Azure

Övriga medarbetare:

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

Nästa steg

Granska lagrings- och datametoder för flera klientorganisationer.

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

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