SaaS-databastenhetsmönster för flera klientorganisationer
Gäller för:
Azure SQL Database
Den här artikeln beskriver de olika innehavarmodeller som är tillgängliga för ett SaaS-program för flera klientorganisationer.
När du utformar ett SaaS-program för flera innehavare måste du noggrant välja den innehavarmodell som bäst passar programmets behov. En innehavarmodell avgör hur varje klients data mappas till lagring. Ditt val av innehavarmodell påverkar programdesign och hantering. Att byta till en annan modell senare är ibland kostsamt.
A. SaaS-begrepp och terminologi
I SaaS-modellen (Software as a Service) säljer företaget inte licenser till din programvara. I stället gör varje kund hyresbetalningar till ditt företag, vilket gör varje kund till en klientorganisation för ditt företag.
I utbyte mot att betala hyra får varje klientorganisation åtkomst till dina SaaS-programkomponenter och har sina data lagrade i SaaS-systemet.
Termen innehavarmodell avser hur klientorganisationens lagrade data organiseras:
- Enskild klientorganisation: Varje databas lagrar data från endast en klientorganisation.
- Flera innehavare: Varje databas lagrar data från flera separata klienter (med mekanismer för att skydda datasekretess).
- Hybriduthyrningsmodeller är också tillgängliga.
B. Så här väljer du lämplig innehavarmodell
I allmänhet påverkar inte innehavarmodellen funktionen för ett program, men det påverkar sannolikt andra aspekter av den övergripande lösningen. Följande kriterier används för att utvärdera var och en av modellerna:
Skalbarhet:
- Antal klienter.
- Lagring per klientorganisation.
- Lagring i aggregerat.
- Arbetsbelastning.
Klientisolering: Dataisolering och prestanda (om en klients arbetsbelastning påverkar andra).
Kostnad per klientorganisation: Databaskostnader.
Utvecklingskomplexitet:
- Ändringar i schemat.
- Ändringar i frågor (krävs av mönstret).
Driftkomplexitet:
- Övervaka och hantera prestanda.
- Schemahantering.
- Återställa en klientorganisation.
- Katastrofåterställning
Anpassningsbarhet: Enkel att stödja schemaanpassningar som är antingen klientspecifika eller klientklassspecifika.
Innehavardiskussionen fokuserar på datalagret . Men överväg för ett ögonblick programlagret . Programlagret behandlas som en monolitisk entitet. Om du delar upp programmet i många små komponenter kan valet av innehavarmodell ändras. Du kan behandla vissa komponenter på ett annat sätt än andra när det gäller både innehavar- och lagringstekniken eller plattformen som används.
C. Fristående app för en klientorganisation med en klientdatabas
Isolering på programnivå
I den här modellen installeras hela programmet upprepade gånger, en gång för varje klientorganisation. Varje instans av appen är en fristående instans, så den interagerar aldrig med någon annan fristående instans. Varje instans av appen har bara en klientorganisation och behöver därför bara en databas. Klientorganisationen har databasen helt för sig själv.
Varje appinstans installeras i en separat Azure-resursgrupp. Resursgruppen kan tillhöra en prenumeration som ägs av antingen programvaruleverantören eller klientorganisationen. I båda fallen kan leverantören hantera programvaran för klientorganisationen. Varje programinstans är konfigurerad för att ansluta till motsvarande databas.
Varje klientdatabas distribueras som en enskild databas. Den här modellen ger den största databasisoleringen. Men isoleringen kräver att tillräckligt med resurser allokeras till varje databas för att hantera den högsta belastningen. Här är det viktigt att elastiska pooler inte kan användas för databaser som distribueras i olika resursgrupper eller till olika prenumerationer. Den här begränsningen gör den här fristående appmodellen för en enskild klient till den dyraste lösningen ur ett övergripande databaskostnadsperspektiv.
Leverantörshantering
Leverantören kan komma åt alla databaser i alla fristående appinstanser, även om appinstanserna är installerade i olika klientprenumerationer. Åtkomsten uppnås via SQL-anslutningar. Den här åtkomsten mellan instanser kan göra det möjligt för leverantören att centralisera schemahantering och frågor mellan databaser i rapporterings- eller analyssyfte. Om den här typen av centraliserad hantering önskas måste en katalog distribueras som mappar klientidentifierare till databas-URI:er. Azure SQL Database tillhandahåller ett fragmenteringsbibliotek som används tillsammans för att tillhandahålla en katalog. Partitioneringsbiblioteket heter formellt Elastic Database-klientbiblioteket.
D. App för flera klientorganisationer med databas per klientorganisation
Det här nästa mönstret använder ett program med flera klientorganisationer med många databaser, som alla är databaser med en klientorganisation. En ny databas etableras för varje ny klientorganisation. Programnivån skalas upp lodrätt genom att lägga till fler resurser per nod. Eller så skalas appen ut vågrätt genom att lägga till fler noder. Skalningen baseras på arbetsbelastningen och är oberoende av antalet eller skalan för de enskilda databaserna.
Anpassa för en klientorganisation
Precis som det fristående appmönstret ger användningen av databaser med en klientorganisation stark klientisolering. I alla appar vars modell endast anger databaser med en enda klientorganisation kan schemat för en viss databas anpassas och optimeras för klientorganisationen. Den här anpassningen påverkar inte andra klienter i appen. En klientorganisation kanske behöver data utöver de grundläggande datafält som alla klienter behöver. Dessutom kan det extra datafältet behöva ett index.
Det är enkelt att anpassa schemat för en eller flera enskilda klienter med databas per klientorganisation. Programleverantören måste utforma procedurer för att noggrant hantera schemaanpassningar i stor skala.
Elastiska pooler
När databaser distribueras i samma resursgrupp kan de grupperas i elastiska pooler. Poolerna är ett kostnadseffektivt sätt att dela resurser i många databaser. Det här poolalternativet är billigare än att kräva att varje databas är tillräckligt stor för att hantera de användningstoppar som den upplever. Även om pooldatabaser delar åtkomst till resurser kan de fortfarande uppnå en hög grad av prestandaisolering.
Azure SQL Database innehåller de verktyg som krävs för att konfigurera, övervaka och hantera delning. Prestandamått på både poolnivå och databasnivå är tillgängliga i Azure-portalen och via Azure Monitor-loggar. Måtten kan ge bra insikter om både aggregerade och klientspecifika prestanda. Enskilda databaser kan flyttas mellan pooler för att tillhandahålla reserverade resurser till en specifik klientorganisation. Med de här verktygen kan du säkerställa bra prestanda på ett kostnadseffektivt sätt.
Driftskala för databas per klientorganisation
Azure SQL Database har många hanteringsfunktioner som är utformade för att hantera ett stort antal databaser i stor skala, till exempel över 100 000 databaser. De här funktionerna gör mönstret database-per-tenant troligt.
Anta till exempel att ett system har en databas med 1 000 klientorganisationer som enda databas. Databasen kan ha 20 index. Om systemet konverteras till att ha 1 000 enklientdatabaser ökar antalet index till 20 000. I Azure SQL Database som en del av automatisk justering är funktionerna för automatisk indexering aktiverade som standard. Automatisk indexering hanterar för dig alla 20 000 index och deras pågående optimering av skapande och släpp. Dessa automatiserade åtgärder sker i en enskild databas och de samordnas inte eller begränsas av liknande åtgärder i andra databaser. Automatisk indexering behandlar index på olika sätt i en upptagen databas än i en mindre upptagen databas. Den här typen av indexhanteringsanpassning skulle vara opraktisk i skalan databas-per-klient om den här enorma hanteringsuppgiften måste utföras manuellt.
Andra hanteringsfunktioner som skalar bra är följande:
- Inbyggda säkerhetskopior.
- Hög tillgänglighet.
- Kryptering på disk.
- Prestandatelemetri.
Automatisering
Hanteringsåtgärderna kan skriptas och erbjudas via en devops-modell . Åtgärderna kan till och med automatiseras och exponeras i programmet.
Du kan till exempel automatisera återställningen av en enskild klient till en tidigare tidpunkt. Återställningen behöver bara återställa den enda klientdatabas som lagrar klientorganisationen. Den här återställningen påverkar inte andra klienter, vilket bekräftar att hanteringsåtgärderna är på den detaljerade nivån för varje enskild klientorganisation.
E. App för flera klientorganisationer med databaser med flera klientorganisationer
Ett annat tillgängligt mönster är att lagra många klienter i en databas med flera klientorganisationer. Programinstansen kan ha valfritt antal databaser med flera klientorganisationer. Schemat för en databas med flera klientorganisationer måste ha en eller flera klientidentifierarkolumner så att data från en viss klientorganisation kan hämtas selektivt. Dessutom kan schemat kräva några tabeller eller kolumner som endast används av en delmängd av klientorganisationer. Statisk kod och referensdata lagras dock bara en gång och delas av alla klienter.
Klientisolering offras
Data: En databas med flera klientorganisationer offrar nödvändigtvis klientisolering. Data för flera klientorganisationer lagras tillsammans i en databas. Under utvecklingen ser du till att frågor aldrig exponerar data från mer än en klientorganisation. SQL Database stöder säkerhet på radnivå, vilket kan framtvinga att data som returneras från en fråga begränsas till en enda klientorganisation.
Bearbetning: En databas med flera klientorganisationer delar beräknings- och lagringsresurser i alla sina klienter. Databasen som helhet kan övervakas för att säkerställa att den fungerar på ett acceptabelt sätt. Azure-systemet har dock inget inbyggt sätt att övervaka eller hantera användningen av dessa resurser av en enskild klientorganisation. Därför medför databasen för flera klientorganisationer en ökad risk att stöta på bullriga grannar, där arbetsbelastningen för en överaktiv klientorganisation påverkar prestandaupplevelsen för andra klienter i samma databas. Ytterligare övervakning på programnivå kan övervaka prestanda på klientorganisationsnivå.
Lägre kostnad
I allmänhet har databaser med flera klientorganisationer den lägsta kostnaden per klientorganisation. Resurskostnaderna för en enskild databas är lägre än för en elastisk pool med motsvarande storlek. För scenarier där klientorganisationer bara behöver begränsad lagring kan potentiellt miljontals klienter lagras i en enda databas. Ingen elastisk pool kan innehålla miljontals databaser. En lösning som innehåller 1 000 databaser per pool, med 1 000 pooler, kan dock nå skalan på miljoner som riskerar att bli svårhanterlig att hantera.
Två varianter av en databasmodell för flera klientorganisationer beskrivs i vad som följer, där den horisontella modellen för flera klientorganisationer är den mest flexibla och skalbara.
F. App för flera klientorganisationer med en enda databas för flera klientorganisationer
Det enklaste databasmönstret för flera klientorganisationer använder en enda databas som värd för data för alla klienter. När fler klienter läggs till skalas databasen upp med fler lagrings- och beräkningsresurser. Den här uppskalning kan vara allt som behövs, även om det alltid finns en slutlig skalningsgräns. Men långt innan den gränsen har nåtts blir databasen svårhanterlig att hantera.
Hanteringsåtgärder som fokuserar på enskilda klienter är mer komplexa att implementera i en databas med flera klientorganisationer. Och i stor skala kan dessa åtgärder bli oacceptabelt långsamma. Ett exempel är en återställning till tidpunkt av data för bara en klientorganisation.
G. App för flera klientorganisationer med shardade databaser med flera klientorganisationer
De flesta SaaS-program har endast åtkomst till data för en klientorganisation i taget. Det här åtkomstmönstret gör att klientdata kan distribueras över flera databaser eller shards, där alla data för en klientorganisation finns i en shard. Kombinerat med ett databasmönster för flera klientorganisationer tillåter en shardad modell nästan obegränsad skalning.
Hantera shards
Horisontell partitionering ökar komplexiteten både för designen och driftshanteringen. En katalog krävs för att underhålla mappningen mellan klientorganisationer och databaser. Dessutom krävs hanteringsprocedurer för att hantera shards och klientorganisationspopulationen. Procedurer måste till exempel utformas för att lägga till och ta bort shards och för att flytta klientdata mellan shards. Ett sätt att skala är att lägga till en ny shard och fylla den med nya klienter. Vid andra tillfällen kan du dela upp en tätbefolkad fragment i två mindre tätbefolkade fragment. När flera klienter har flyttats eller upphört kan du sammanfoga glesbefolkade shards tillsammans. Sammanfogningen skulle resultera i mer kostnadseffektiv resursanvändning. Klienter kan också flyttas mellan shards för att balansera arbetsbelastningar.
SQL Database innehåller ett split/merge-verktyg som fungerar tillsammans med fragmenteringsbiblioteket och katalogdatabasen. Den angivna appen kan dela och sammanfoga shards, och den kan flytta klientdata mellan shards. Appen underhåller också katalogen under dessa åtgärder och markerar berörda klienter som offline innan de flyttas. Efter flytten uppdaterar appen katalogen igen med den nya mappningen och markerar klientorganisationen som online igen.
Mindre databaser hanteras enklare
Genom att distribuera klientorganisationer över flera databaser resulterar den fragmenterade lösningen för flera klientorganisationer i mindre databaser som är enklare att hantera. Om du till exempel återställer en specifik klientorganisation till en tidigare tidpunkt innebär det nu att du återställer en enda mindre databas från en säkerhetskopia i stället för en större databas som innehåller alla klienter. Databasens storlek och antalet klienter per databas kan väljas för att balansera arbetsbelastningen och hanteringsarbetet.
Klientidentifierare i schemat
Beroende på vilken horisontell partitioneringsmetod som används kan ytterligare begränsningar införas i databasschemat. Sql Database-programmet för delning/sammanslagning kräver att schemat innehåller partitioneringsnyckeln, som vanligtvis är klientidentifieraren. Klientidentifieraren är det ledande elementet i primärnyckeln för alla shardade tabeller. Klientidentifieraren gör det möjligt för delnings-/sammanslagningsprogrammet att snabbt hitta och flytta data som är associerade med en specifik klientorganisation.
Elastisk pool för shards
Sharded flera klientdatabaser kan placeras i elastiska pooler. I allmänhet är det lika kostnadseffektivt att ha många enklientdatabaser i en pool som att ha många klienter i några databaser med flera klientorganisationer. Databaser med flera klientorganisationer är fördelaktiga när det finns ett stort antal relativt inaktiva klienter.
H. Hybridshardad databasmodell för flera klientorganisationer
I hybridmodellen har alla databaser klientidentifieraren i sitt schema. Databaserna kan alla lagra fler än en klientorganisation och databaserna kan partitioneras. Så i schema mening är de alla databaser med flera klientorganisationer. Men i praktiken innehåller vissa av dessa databaser bara en klientorganisation. Oavsett har antalet klienter som lagras i en viss databas ingen effekt på databasschemat.
Flytta runt klienter
När som helst kan du flytta en viss klientorganisation till en egen databas med flera klientorganisationer. Och när som helst kan du ändra dig och flytta tillbaka klientorganisationen till en databas som innehåller flera klienter. Du kan också tilldela en klientorganisation till en ny databas med en klientorganisation när du etablerar den nya databasen.
Hybridmodellen lyser när det finns stora skillnader mellan resursbehoven för identifierbara grupper av klienter. Anta till exempel att klienter som deltar i en kostnadsfri utvärderingsversion inte garanteras samma höga prestandanivå som prenumererande klienter är. Principen kan vara att klienter i den kostnadsfria utvärderingsfasen lagras i en databas med flera klientorganisationer som delas mellan alla kostnadsfria utvärderingsklientorganisationer. När en kostnadsfri utvärderingsklient prenumererar på den grundläggande tjänstnivån kan klientorganisationen flyttas till en annan databas med flera klientorganisationer som kan ha färre klienter. En prenumerant som betalar för Premium-tjänstnivån kan flyttas till sin egen nya databas med en enda klientorganisation.
Pooler
I den här hybridmodellen kan databaserna med en klientorganisation för prenumerantklienter placeras i resurspooler för att minska databaskostnaderna per klientorganisation. Detta görs också i modellen database-per-tenant.
I. Innehavarmodeller jämfört
I följande tabell sammanfattas skillnaderna mellan de viktigaste innehavarmodellerna.
| Mått | Fristående app | Databas per klientorganisation | Sharded multi-tenant |
|---|---|---|---|
| Skala | Medium 1–100-talet |
Mycket hög 1-100 000-talet |
Obegränsat 1-1 000 000-talet |
| Klientisolering | Mycket hög | Högst | Låg; utom för en enskild klientorganisation (som är ensam i en MT-databas). |
| Databaskostnad per klientorganisation | Hög; är storleksanpassad för toppar. | Låg; pooler som används. | Lägst för små klienter i MT DBs. |
| Prestandaövervakning och hantering | Endast per klientorganisation | Aggregera + per klientorganisation | Sammanlagda; även om är per klient endast för singlar. |
| Utvecklingskomplexitet | Lägst | Lägst | Medium; på grund av horisontell partitionering. |
| Driftkomplexitet | Låg-hög. Individuellt enkelt, komplext i stor skala. | Låg medelhög. Mönster hanterar komplexitet i stor skala. | Låg-hög. Enskild klientorganisationshantering är komplex. |