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.

Krav för flera innehavare

När du planerar en lösning för flera klientorganisationer finns det två viktiga behov som du kan behöva utforma för:

  • Säkerställa stark isolering mellan klienter och uppfylla stränga säkerhetskrav för dem som behöver dem.
  • Upprätthålla en låg kostnad per klientorganisation. Som provider vill du se till att kostnaden för att köra programmet förblir hållbar allt eftersom den skalar.

Dessa två behov kan ofta vara motstridiga, vilket kräver kompromisser och prioriterar det ena framför det andra. Det finns några riktlinjer som du kan följa för att bättre förstå de kompromisser som ingår i att hantera båda de behov som beskrivs ovan. Det här dokumentet 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

Du måste bestämma isoleringsnivån 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:

  • Partitionsnyckel per klientorganisation, som ofta används för helt multitenantlösningar som de som används i programvara från företag till konsument som en tjänst (B2C SaaS).
  • Databaskonto per klientorganisation, vilket ofta är det. används i saaS (business-to-business).

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 företag säljer direkt till en enskild kund med hjälp av produkten eller tjänsten. B2B-modeller kan dock prioritera stark säkerhets- och prestandaisolering och kan kräva att klientorganisationer har sitt eget databaskonto etablerat.

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 samt tillhandahåller en kostnadsfri utvärderingsversion för potentiella nya kunder. Du kan distribuera ett separat databaskonto för betalda företagsklientorganisationer, som behöver starka säkerhets- och isoleringsgarantier, samtidigt som du delar ett databaskonto och använder partitionsnycklar för att isolera utvärderingskunder.

Partitionsnyckel per klientorganisation

Genom att isolera våra klienter efter partitionsnyckel delas dataflödet mellan klientorganisationer och grupperas i samma container.

Fördelar:

  • Kostnadseffektivitet: Alla klienter placeras i en container, som partitioneras av klientorganisations-ID. Eftersom det bara finns en fakturerbar resurs där RU/s etableras och delas mellan flera klienter är den här metoden vanligtvis mer kostnadseffektiv och enklare att hantera än att ha separata konton per klientorganisation.
  • Förenklad hantering: Färre Azure Cosmos DB-konton att hantera.

Kompromisser:

  • Resurskonkurrens: Delning av dataflöde (RU/s) mellan klienter i samma container kan leda till konkurrens under hög användning, vilket resulterar i problem med bullriga grannar som kan orsaka prestandaproblem om dina klienter har höga eller överlappande arbetsbelastningar. Den här isoleringsmodellen är lämplig för arbetsbelastningar som behöver garanterade RU/s på en enda klientorganisation och som kan dela.
  • Begränsad isolering: Den här metoden ger logisk isolering, inte fysisk isolering. Det kanske inte uppfyller strikta isoleringskrav, oavsett om det gäller prestanda och säkerhet.
  • Mindre flexibilitet: Anpassning av funktioner på kontonivå som geo-replikering, återställning till tidpunkt (PITR) och kundhanterade nycklar (CMK) per klientorganisation är inte tillgängliga om isoleras med partitionsnyckel (eller efter databas/container).

Relevanta Azure Cosmos DB-funktioner:

  • Kontrollera ditt dataflöde: Utforska funktioner som kan hjälpa dig att kontrollera det bullriga grannproblemet när du modellerar klientorganisationen efter partition, till exempel omfördelning av dataflöde, burst-kapacitet och dataflödeskontroll i Java SDK.

  • Hierarkiska partitionsnycklar: 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 (förutsatt att du har hög kardinalitet för klienter), med lagring som är större än 20 GB, utan att behöva använda syntetiska partitionsnycklar eller flera partitionsnyckelvärden per klientorganisation.

    Anta att du har en arbetsbelastning som isolerar klientorganisationer efter partitionsnyckel. En klientorganisation, Contoso, är mycket större och mer skrivintensiv än andra, och den fortsätter att växa i storlek. 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å, SessionIDtill exempel . 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 hade 1 000 fysiska partitioner, men ett specifikt TenantId värde bara fanns på 5 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.

Databaskonto per klientorganisation

Genom att isolera våra klienter efter databaskonto har varje klientorganisation sitt eget dataflöde etablerat på databasnivå eller containernivå.

Fördelar:

  • Hög isolering: Den här metoden undviker konkurrens eller interferens på grund av dedikerade Azure Cosmos DB-konton och containrar med etablerade RU/s per unik klientorganisation.
  • Anpassade serviceavtal: På grund av att varje klientorganisation har ett eget konto kan du tillhandahålla specifika skräddarsydda resurser, kundriktade serviceavtal och garantier eftersom varje klients databaskonto kan justeras separat för dataflöde.
  • Förbättrad säkerhet: Fysisk dataisolering garanterar robust säkerhet eftersom kunder kan aktivera kundhanterade nycklar på kontonivå per klientorganisation. Varje klientorganisations data isoleras efter konto i stället för att vara i samma container.
  • Flexibilitet: Klienter kan aktivera funktioner på kontonivå som geo-replikering, återställning till tidpunkt (PITR) och kundhanterade nycklar (CMK) efter behov.

Kompromisser:

  • Ökad hantering: Den här metoden ger större komplexitet eftersom du hanterar flera Azure Cosmos DB-konton.
  • Högre kostnader: Fler konton innebär etableringsdataflöde (RU/s) för varje resurs (databaser och/eller containrar) i kontot, för varje klientorganisation. Varje gång en resurs etablerar RU/s ökar dina Azure Cosmos DB-kostnader.
  • Frågebegränsningar: Eftersom alla klienter finns inom olika konton krävs flera anrop inom programmets logik till varje klientorganisation när du frågar efter flera klienter.

Relevanta Azure Cosmos DB-funktioner:

  • Säkerhetsfunktioner: Den här modellen ger ökad säkerhetsisolering för dataåtkomst med hjälp av Azure RBAC. Dessutom tillhandahåller den här modellen 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 klient (rekommenderas) Container per klient (delat dataflöde) Container per klient (dedikerat dataflöde) Databas per klient Databaskonto per klientorganisation (rekommenderas)
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 Enkelt 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

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.

På samma sätt som modellen för konto per klientorganisation 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.

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, som ett GUID med hög kardinalitet, för att tillåta nästan obundna skalning. Eller så kan du ange en hierarkisk partitionsnyckel som innehåller en egenskap som ofta används i frågor. Den här metoden hjälper dig att undvika frågor mellan partitioner. Genom att använda hierarkiska partitionsnycklar kan du skala utöver den logiska partitionsgränsen på 20 GB per partitionsnyckelvärde och du begränsar dyra uttjäntas frågor.

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.

För klienter som kräver garanterad prestanda och säkerhetsisolering rekommenderar vi att du isolerar klienter efter databaskonto och allokerar enheter för begäranden till klientorganisationen. För klienter med mindre stränga krav rekommenderar vi att du isolerar klienter efter partitionsnyckel, vilket möjliggör delning av enheter för begäranden mellan dina klienter och hjälper dig att optimera för en låg kostnad per klientorganisation.

En alternativ 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:

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

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: