Klientorganisationsmönster för SaaS-databas

GÄLLER FÖR: Azure SQL Database

I den här artikeln beskrivs de olika innehavarmodeller som är tillgängliga för ett SaaS-program för flera innehavare.

När du utformar ett SaaS-program för flera innehavare måste du noggrant välja den innehavarmodell som bäst passar behoven i ditt program. En innehavarmodell avgör hur varje klients data mappas till lagringen. Ditt val av innehavare påverkar programdesign och hantering. Att byta till en annan modell senare är ibland dyrt.

A. Begrepp och terminologi för SaaS

I SaaS-modellen (Programvara som en tjänst) säljer ditt företag inte licenser till din programvara. I stället gör varje kund hyra ut betalningar 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:

• Ett enda innehavare:   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 datasekretessen).
• Hybridhybridmodeller är också tillgängliga.

B. Så här väljer du lämplig innehavaresmodell

I allmänhet påverkar inte innehavare modellen 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 mängd.
  • Arbetsbelastning.

• Klientisolering:   Dataisolering och prestanda (om en klients arbetsbelastning påverkar andra).

• Kostnad per klientorganisation:   Databaskostnader.

• Utvecklingskomplexitet:

  • Ändringar i schemat.
  • Ändringar av frågor (krävs av mönstret).

• Driftskomplexitet:

  • Övervakning och hantering av prestanda.
  • Schemahantering.
  • Återställa en klient.
  • Haveriberedskap.

• Anpassningsbarhet:   Enkelt att stödja schemaanpassningar som antingen är klientspecifika eller klientklassspecifika.

Diskussionen om innehavare fokuserar på datalagret. Men överväg att använda programlagret en stund. Programlagret behandlas som en monolitisk entitet. Om du delar in programmet i många små komponenter kan valet av innehavare ändras. Du kan hantera vissa komponenter på ett annat sätt än andra vad gäller både innehavare och den lagringsteknik eller plattform som används.

C. Fristående app för en enda klient 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 hela databasen till 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 enda databas. Den här modellen ger störst databasisolering. Isoleringen kräver dock att tillräckligt med resurser allokeras till varje databas för att hantera belastningstoppar. 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 den dyraste lösningen ur ett övergripande kostnadsperspektiv för databasen.

Leverantörshantering

Leverantören kan komma åt alla databaser i alla fristående appinstanser, även om appinstanserna är installerade i olika klientorganisationsprenumerationer. Å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 databasfrågor i rapporterings- eller analyssyfte. Om den här typen av centraliserad hantering önskas måste en katalog distribueras som mappar klient-ID:er till databas-URI:er. Azure SQL Database ett bibliotek för horisontell partitionering som används tillsammans för att tillhandahålla en katalog. Sharding-biblioteket har formellt namnet elastisk databas klientbiblioteket.

D. App för flera innehavare med databas per klient

I det här nästa mönstret används ett program för flera innehavare med många databaser, där alla är databaser med en enda klientorganisation. En ny databas etableras för varje ny klientorganisation. Programnivån skalas upp lodrätt genom att fler resurser läggs till 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 mönstret för fristående appar ger användningen av databaser för en enskild klient stark klientisolering. I alla appar vars modell endast anger databaser för en enskild 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.

Med databas-per-klient är det enkelt att anpassa schemat för en eller flera enskilda klienter. 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 mellan flera 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 behövs för att konfigurera, övervaka och hantera delning. Prestandamått på både pool- och databasnivå är tillgängliga i Azure Portal och via Azure Monitor loggar. Måtten kan ge bra insikter om både sammanställda och klientspecifika prestanda. Enskilda databaser kan flyttas mellan pooler för att tillhandahålla reserverade resurser till en specifik klientorganisation. Med dessa verktyg kan du säkerställa bra prestanda på ett kostnadseffektivt sätt.

Operations scale for database-per-tenant (Skala 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 databas-per-klient möjligt.

Anta till exempel att ett system har en databas med 1 000 klienter som enda databas. Databasen kan ha 20 index. Om systemet konverteras till att ha 1 000 databaser för en enskild klientorganisation, ö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 optimeringar för att skapa och släppa. Dessa automatiserade åtgärder sker i en enskild databas och de samordnas inte eller begränsas inte av liknande åtgärder i andra databaser. Automatisk indexering behandlar index annorlunda i en upptagen databas än i en mindre upptagen databas. Den här typen av anpassning av indexhantering skulle vara opraktiskt på databas-per-klient-skala om den här enorma hanteringsuppgiften måste göras manuellt.

Andra hanteringsfunktioner som skalas väl omfattar följande:

• Inbyggda säkerhetskopior.
• Hög tillgänglighet.
• Kryptering på disk.
• Prestandatelemetri.

Automation

Hanteringsåtgärder 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 en databas med en enda klientorganisation som lagrar klientorganisationen. Den här återställningen påverkar inte andra klienter, vilket bekräftar att hanteringsåtgärder är på den detaljerade nivån för varje enskild klientorganisation.

E. App för flera innehavare med databaser för flera innehavare

Ett annat tillgängligt mönster är att lagra många klienter i en databas för flera innehavare. Programinstansen kan ha val annat antal databaser för flera innehavare. Schemat för en databas för flera innehavare måste ha en eller flera kolumner med klientidentifierare 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 klienterna. Statisk kod och referensdata lagras dock bara en gång och delas av alla klienter.

Klientisoleringen har avskilts

Data:   En databas för flera innehavare innebär nödvändigtvis isolering av klientorganisationen. Data för flera klienter lagras tillsammans i en databas. Under utvecklingen ser du till att frågor aldrig exponerar data från mer än en klientorganisation. SQL Database har stöd för säkerhet på radnivå,vilket kan tvinga fram att data som returneras från en fråga är begränsade till en enda klientorganisation.

Bearbetning:   En databas för flera innehavare delar beräknings- och lagringsresurser mellan alla dess 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 innehavare en ökad risk för att stöta på högljudda 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å klientnivå.

Lägre kostnad

I allmänhet har databaser för flera innehavare den lägsta kostnaden per klientorganisation. Resurskostnaderna för en enkel databas är lägre än för en elastisk pool med motsvarande storlek. För scenarier där klienterna bara behöver begränsad lagring kan dessutom 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å upp till miljontals databaser med risk för att bli oskadlig att hantera.

Två varianter av en databasmodell för flera innehavare beskrivs i följande, där den fragmenterade modellen för flera innehavare är den mest flexibla och skalbara.

F. App för flera innehavare med en enda databas för flera innehavare

Det enklaste databasmönstret för flera innehavare 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. Det tar dock lång tid innan den gränsen nås och databasen blir oskadlig att hantera.

Hanteringsåtgärder som fokuserar på enskilda klienter är mer komplexa att implementera i en databas för flera innehavare. Och i stor skala kan dessa åtgärder bli oacceptabelt långsamma. Ett exempel är en återställning till en tidpunkt av data för bara en klientorganisation.

G. App för flera innehavare med fragmenterade databaser för flera innehavare

De flesta SaaS-program har åtkomst till data för endast 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. I kombination med ett databasmönster för flera innehavare möjliggör en horisontell partitionerad modell nästan obegränsad skalning.

Hantera shards

Horisontell partitionering gör både design- och drifthanteringen mer komplex. En katalog krävs för att underhålla mappningen mellan klienter och databaser. Dessutom krävs hanteringsprocedurer för att hantera shards och klientpopulationen. 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 ett kompakt fragment i två mindre kompakta shards. När flera klienter har flyttats eller upphört kan du sammanfoga glesa ifyllda shards. Sammanslagningen skulle resultera i ett mer kostnadseffektivt resursutnyttjande. Klienter kan också flyttas mellan shards för att balansera arbetsbelastningar.

SQL Database ett verktyg för delning/sammanfogning som fungerar tillsammans med shardingbiblioteket och katalogdatabasen. Den tillhandahållna appen kan dela och sammanfoga shards, och den kan flytta klientdata mellan shards. Appen underhåller även 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 klienten som online igen.

Enklare att hantera mindre databaser

Genom att distribuera klienter över flera databaser resulterar den fragmenterade lösningen för flera innehavare i mindre databaser som är enklare att hantera. Att till exempel återställa en specifik klient till en tidigare tidpunkt innebär nu att återställa en enda mindre databas från en säkerhetskopia, i stället för en större databas som innehåller alla klienter. Databasstorleken och antalet klienter per databas kan väljas för att balansera arbetsbelastningen och hanteringsarbetet.

Klientorganisations-ID i schemat

Beroende på vilken metod för horisontell partitionering som används kan ytterligare begränsningar tillämpas på databasschemat. Programmet SQL Database split/merge kräver att schemat innehåller nyckeln för horisontell partitionering, vilket vanligtvis är klient-ID:t. Klient-ID är det inledande elementet i primärnyckeln för alla shardade tabeller. Med klient-ID:t kan delnings-/sammanfogningsprogrammet snabbt hitta och flytta data som är associerade med en specifik klientorganisation.

Elastisk pool för shards

Fragmenterade databaser för flera innehavare kan placeras i elastiska pooler. I allmänhet är det lika kostnadseffektivt att ha många databaser för en enskild klientorganisation i en pool som att ha många klienter i ett fåtal databaser med flera innehavare. Databaser för flera innehavare är fördelaktiga när det finns ett stort antal relativt inaktiva klienter.

H. Horisontell partitionerad databasmodell för flera innehavare

I hybridmodellen har alla databaser klient-ID:t i sitt schema. Alla databaser kan lagra fler än en klientorganisation och databaserna kan partitioneras. Så i schema mening är de alla databaser för flera innehavare. Men i praktiken innehåller vissa av dessa databaser bara en klientorganisation. Oavsett så har antalet klienter som lagras i en viss databas ingen effekt på databasschemat.

Flytta runt klienter

Du kan när som helst flytta en viss klientorganisation till en egen databas för flera innehavare. Och när som helst kan du ändra dig och flytta klienten tillbaka till en databas som innehåller flera klienter. Du kan också tilldela en klientorganisation till en ny databas för en enskild klient när du etablerar den nya databasen.

Hybridmodellen är bäst 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 prestanda som de prenumererande klienterna. Principen kan vara att klienter i den kostnadsfria utvärderingsfasen lagras i en databas för flera innehavare som delas mellan alla kostnadsfria utvärderingsklienter. När en kostnadsfri utvärderingsversion prenumererar på den grundläggande tjänstnivån kan klientorganisationen flyttas till en annan databas för flera innehavare som kan ha färre klienter. En prenumerant som betalar för premiumtjänstnivån kan flyttas till en egen ny databas för en enskild klientorganisation.

Pooler

I den här hybridmodellen kan databaserna för en enskild klientorganisation för prenumerantklienter placeras i resurspooler för att minska databaskostnaderna per klientorganisation. Detta görs också i modellen databas-per-klient.

I. Jämförelse av tenancy-modeller

I följande tabell sammanfattas skillnaderna mellan de huvudsakliga modellerna för innehavare.

Nästa steg

• Distribuera och utforska ett Wingtip-program för flera klienter som använder SaaS-modellen databas per klient – Azure SQL Database

• Välkommen till Wingtip Tickets-exemplet på SaaS Azure SQL Database för innehavare