Dela via

Data för SaaS-arbetsbelastningar i Azure

  • Artikel

Behandla data som den mest värdefulla tillgången i din lösning. Som oberoende programvaruleverantör (ISV) ansvarar du för att hantera dina kunders data. Din strategi för datadesign och val av datalager kan påverka dina kunder avsevärt.

Den här artikeln innehåller vägledning om hur du säkerställer dataintegritet och konfidentialitet för dina kunder samtidigt som du uppfyller kraven på affärsprestanda. Det belyser viktiga överväganden som hjälper dig att uppnå dessa mål på ett effektivt sätt.

Välj ett datalager

Datalagret i en SaaS-lösning (programvara som en tjänst) påverkar dess arkitektur, prestanda, tillförlitlighet och transaktionskomplexitet. Jämför funktionerna i Azure-hanterade tjänster med liknande erbjudanden som inte kommer från Microsoft. I vissa situationer kan du också överväga att köra produkter med öppen källkod på virtuella datorer.

Utformningsbeaktanden

  • Skilja mellan transaktions- och analysåtgärder. Transaktionsdatalager är utformade för att stödja dina program, och analysdatalager används för rapportering och uppgifter som maskininlärning. Dessa butiker är byggda med specialiserade produkter och har unika behov av prestanda, åtkomstmönster, scheman och användningsfall.

    Den här guiden fokuserar på transaktionsdatalager.

  • Förstå dina databehov. Beräkna volymen, hur ofta den kan ändras och vilken typ av data du behöver lagra.

    Förvänta dig att data växer avsevärt över tid. För SaaS-lösningar sker tillväxten i flera dimensioner. Förutse ökningar av volymen och typerna av data i takt med att antalet kunder ökar. Se till att du planerar för den tillväxten och investerar i tekniker som kan stödja den.

    Bestäm mellan en relations- eller icke-relationell dataplattform baserat på typen av data. För många transaktionsarbetsbelastningar är en relationsdatabas ett bra alternativ för att modellera programentiteter som diskreta tabeller. Med den här metoden kan frågor fungera i relationsdatamodellen. Om dina data naturligt passar en dokumentmodell eller följer en grafstruktur kan en icke-relationell metod vara lämpligare.

    Mer information finns i SQL jämfört med NoSQL-dataplattformar.

  • Minimera typerna av datalager. Att lagra olika typer av data i flera distinkta datalager kan vara fördelaktigt för mogna organisationer som har expertis på olika dataplattformar. Den här metoden ger dock ofta onödig komplexitet för nystartade företag och mindre organisationer. Det är mer effektivt att fokusera på ett eller ett litet antal datalager.

    Om du inte har affärsmotiveringen för att använda flera datalager fokuserar du på ett eller ett litet antal datalager.

  • Använd det du vet och investera i det. Om ditt team redan har expertis med ett specifikt datalager är det ofta bättre att använda det datalagret i stället för att investera i att lära sig nya färdigheter. Datalager och plattformar är komplexa, och designbeslut kan vara svåra att ångra.

    Tänk dock på den potentiella tillväxten. Om ditt aktuella datalager inte längre uppfyller dina krav väljer du ett datalager som kan förbättra lösningens prestanda, återhämtning, säkerhet och driftseffektivitet. Det bör också hjälpa ditt team att fördjupa sin expertis.

Designrekommendationer

Rekommendation Förmån
Avgränsa transaktionsdatalager för dagliga åtgärder från analys- och rapporteringsdatalager. Att blanda avsikten med dina datalager kan leda till onödig komplexitet. Datasegmentering förbättrar drifteffektiviteten och maximerar användningen av varje datalager.
Välj mellan en relations- eller icke-relationell datastruktur baserat på dina krav. Börja med ett eller ett litet antal datalager.

Prioritera hanterade datalager. Vanliga alternativ är Azure Cosmos DB, Azure SQL, MySQL, MongoDB och PostgreSQL.		 Den här metoden hjälper till att minimera komplexiteten och ser till att du använder rätt produkt för att maximera effektiviteten. Hanterade datalager ger flexibilitet när det gäller att hantera resurser och kostnader elastiskt och skala efter dina behov. Att använda hanterade datalager skapar mindre hanteringsbelastning än att distribuera ditt eget datalager i din egen infrastruktur.
Investera i att lära dig din valda teknik. Utrusta ditt team för att hantera höga skalningskrav och andra komplexiteter i SaaS-lösningar. Lär dig mer om de verktyg som du använder och deras bredare ekosystem så att du effektivt kan använda din dataplattform när du skalar.
Anta flexibilitet i din datadesign. När Din SaaS-lösning växer eller dina krav ändras kan du anpassa genom att lägga till eller ändra datalager. Med den här flexibiliteten kan du börja med ett datalager och utvecklas över tid för att uppfylla dina behov.

Innehavarmodell och databasstrategi

En viktig aspekt av datadesignen är beslutet att vara värd för resurser åt dina kunder eller att vara värd för resurser i deras miljö. De flesta SaaS-leverantörer är värdar för resurser för alla kunder, vilket ger flexibilitet i databashantering. Om du är värd för resurser i kundens miljö bör du överväga hur du kommer åt och hanterar dessa resurser.

Utformningsbeaktanden

  • Planera databassegmenteringen. I SaaS-lösningar (business-to-business) (B2B) rekommenderar vi att du skapar dedikerade databaser för varje kund. Den här metoden förbättrar datasäkerheten genom att upprätthålla strikt isolering mellan kunder, vilket minskar risken för datablandning och stöder kundhanterade krypteringsnycklar. Det hjälper dig också att uppfylla regelefterlevnadskrav för vissa kunder.

    Att dela upp kunddata i enskilda databaser kan förbättra prestandan genom att minimera bullriga närliggande problem. Vissa hanterade datalager inkluderar resursallokeringskontroller för att minska dessa problem, tillhandahålla kostnadseffektivitet och införliva verktyg för att hantera flera databaser i stor skala.

    I vissa fall är det lämpligt att lagra flera kunders data i ett enda datalager. I till exempel B2C-lösningar (business-to-consumer) kan du spara data i ett enda arkiv med logisk partitionering baserat på kund-ID. I B2B-lösningar som delar komponenter kan du använda ett enda datalager för specifika delar, till exempel ett händelselager, samtidigt som du ser till att du inkluderar kund-ID:n för varje händelse.

  • Samla in datalager med programkomponenter. Om du är värd för resurser åt kunden distribuerar du i samma Azure-region för att undvika utgående bandbreddsavgifter och svarstider. När du är värd för program och datalager i en kunds miljö distribuerar du dem tillsammans i samma miljö för att undvika komplexitet mellan miljöer.

  • Standardisera hantering av datalager så mycket som är praktiskt. Enhetlighet är nyckeln till att hantera data mellan kunder. I takt med att ditt företag växer ökar skillnaderna mellan kunder risker och komplexitet. Dessa skillnader kan också göra produktionsstoppen mer sannolika och felsökningen svårare.

    Undvik engångsändringar i din hantering för att stödja enskilda kunder. Om du till exempel vill stödja kundhanterade metadata kan du undvika schemaändringar som att lägga till extra kolumner i databasen. Skapa i stället funktioner för kunder för att lägga till egna metadata. På samma sätt, om du behöver tillhandahålla olika nivåer av databasprestanda för olika kunder, skapar du en enda process som du kan använda för att tillämpa olika konfigurationer på olika kundnivåer.

Mer information om hur din innehavarmodell påverkar din datastrategi finns i.

Designrekommendationer

Rekommendation Förmån
Utvärdera om du vill dela databaser mellan flera kunder eller tillhandahålla en delad dataplattform.

Distribuera en enskild databas för varje kunds data, där det är lämpligt. Slappna av i den här strategin om strikt isolering inte är ett krav, till exempel i B2C-lösningar.		 Den här metoden minimerar problem med bullriga grannar och kan stödja efterlevnadskrav för vissa kunder.
Distribuera program och deras databaser i samma region. Den här metoden optimerar bandbreddskostnaden och svarstiden för databasåtkomst mellan regioner.
Utforma en standardiserad metod för att lagra kunddefinierade data eller metadata. Undvik att ändra schemat för enskilda kunder eller orsaka att kundmiljöer skiljer sig åt. Den här metoden hjälper dig att undvika den operativa bördan att hantera inkonsekvenser mellan databaser för varje kund.
Planera för rutinmässiga underhållsåtgärder i den kunddistribuerade miljön.

Planera hur du kommer åt databasen för uppdateringar, schemaändringar, underhåll och andra åtgärder.		 Den här proaktiva metoden minimerar problem på grund av bristande underhåll och minskar risken för driftstopp och prestandaproblem.

Planera kapacitet

Kapacitetsplanering avser hantering av resursanvändning, med fokus på processor-, minnes-, lagrings- och diskåtgärder som in- och utdataåtgärder per sekund (IOPS). Vissa datalager kombinerar dessa resurser till ett enkelt, syntetiskt resursförbrukningsmått, till exempel en databasdataflödesenhet (DTU) i Azure SQL eller en enhet för begäran (RU) i Azure Cosmos DB. Hanterade datalager ger flexibilitet i resurshantering, vilket möjliggör ändringar över tid. Det är viktigt att upprätta en första plan och iterera när dina behov utvecklas.

Utformningsbeaktanden

  • Förstå dina resursallokeringskrav. Olika kunder i SaaS-lösningar kan ha olika resursbehov. Mindre kunder kan kräva minimala resurser och större kunder kan behöva mer. Större kunder betalar ofta mer, vilket motiverar högre resursallokering. Genom att använda separata databaser för varje kund kan du justera resursallokeringen baserat på deras storlek och behov.

  • Förstå de olika kapacitetsmodeller som dataplattformar erbjuder. Molnbaserade dataplattformar tillhandahåller ofta flera resursmodeller. Till exempel tillhandahåller vissa Azure-tjänster som Azure Cosmos DB etablerade, dataflödesbaserade modeller och serverlösa modeller. Azure SQL Database tillhandahåller även elastiska pooler.

    Etablerat dataflöde kräver fördefinierad resursallokering, antingen från en enskild databas eller en grupp databaser. Elastiska pooler tillåter resursdelning mellan flera databaser. Elastiska pooler används ofta i SaaS-lösningar.

    Även om etablerat dataflöde kräver att du allokerar resurser i förväg, tillhandahåller tjänster som Azure Cosmos DB autoskalningsdataflöde. Du kan ange regler för att dynamiskt lägga till eller ta bort resurser baserat på angivna utlösare.

    Serverlösa resursmodeller skalas automatiskt baserat på efterfrågan. Den här funktionen gör dem till en bra startpunkt om du inte kan förutsäga dina kapacitetskrav i förväg. De kan dock ha stöd för färre funktioner och bli ineffektiva när du växer. Serverlösa modeller är tillgängliga i Azure SQL Database och Azure Cosmos DB.

Designrekommendationer

Rekommendation Förmån
Modellera dina databaskrav för varje kund. Avgör om du ska ha många små databaser, färre stora databaser eller en blandning av de två.

Använd en t-shirtstorleksövning för att kategorisera kunder i små, medelstora och stora bucketar.		 Den här metoden ger en ungefärlig uppskattning av de resurser som behövs per kund och hjälper dig att mappa kunder till din faktureringsmodell.
Segmentera resurspooler baserat på storleken på de kunddatabaser som använder dem.

Använd etablerad kapacitet till din fördel. Du kan till exempel skapa en delad elastisk SQL-pool för mindre kunder, en separat pool för medelstora kunder och dedikerade resurser för stora kunder.		 Genom att segmentera resurspooler baserat på kundernas databasstorlek kan du optimera resursallokering och kostnadseffektivitet.
Dra nytta av de inbyggda skalningsfunktionerna som de hanterade tjänsterna tillhandahåller. Du kan avlasta skalningsansvaret till plattformen. Funktioner som elastiska pooler och autoskalning kan hjälpa dig att optimera resursanvändningen.
Granska regelbundet serverlösa datalager för att säkerställa att de fortsätter att uppfylla dina behov. Du kan se till att datalagret förblir effektivt med dina föränderliga behov. Optimera prestanda och kostnadseffektivitet när dina krav ändras.

Hög tillgänglighet och haveriberedskap

Kunder med SaaS-lösningar har ofta höga förväntningar på hög tillgänglighet (HA) och haveriberedskap (DR). Om dina kunder arbetar i reglerade branscher eller förlitar sig på din lösning för daglig drift kan deras krav vara ännu strängare.

HA och DR är inte lösningar som passar alla och är beroende av olika faktorer. Ha en tydlig förståelse för de tillgängliga alternativ som gäller både för dig och dina kunders krav för att fatta välgrundade beslut om att minimera olika risker.

Kompromiss: Tillförlitlighet, kostnad och prestanda: Återhämtning för datatjänster kräver ofta att repliker eller kopior av dina data distribueras över ett större geografiskt område för att minska riskerna. Det finns dock kompromisser. Ju längre avståndet data måste färdas, desto mer skydd har du mot lokaliserade fel. Men kopiering av data över längre avstånd ökar svarstiden och kostar ofta mer. Många hanterade datalager tillhandahåller automatiserad datareplikering, men de kan införa gränser för de typer av replikering som du kan utföra på olika avstånd för att upprätthålla prestanda.

Utformningsbeaktanden

  • Kvantifiera återhämtning. Mät återhämtningskrav med hjälp av servicenivåmål (SLO), som omfattar mått som drifttid, återställningstid och återställningspunkt. Dessa mått styrs av både dina affärskrav och dina kunders, som kan ha olika behov. Om du lagrar stora mängder data för dina kunders räkning kan din HA- och DR-lösning behöva vara mer komplex för att uppfylla stränga krav.

    Mer information om återhämtningsmått finns i RE:04-rekommendationer för att definiera tillförlitlighetsmål.

  • Använd plattformsfunktioner. Azure tillhandahåller funktioner för återhämtning i ett datacenter, inom en region med hjälp av tillgänglighetszoner och över ett bredare geografiskt område med hjälp av flera regioner. Kombinera strategier som tillgänglighetszoner, säkerhetskopiering mellan regioner och distributioner i flera regioner för att uppnå rätt återhämtningsnivå för din lösning. För krav på hög återhämtning bör du överväga en arkitektur med flera regioner, aktiv-passiv med asynkron datareplikering mellan regioner. Den här metoden kan leda till viss dataförlust vid ett oåterkalleligt avbrott.

    Kompromiss: Multiregion, aktiv-aktiv design med replikering är de mest motståndskraftiga men är komplexa att bygga och testa. För de flesta aktiva-aktiva lösningar måste du utforma en konfliktlösningsmetod som står för fördröjningar i datasynkronisering. De flesta lösningar behöver inte den här graden av återhämtning.

    Se RE:05 Rekommendationer för användning av tillgänglighetszoner och regioner.

  • Använd distributionsstämplar för att isolera komponenternas explosionsradie. Mönstret för distributionsstämplar används ofta i SaaS-lösningar eftersom det ger fördelar för distribution, hantering, prestanda och återhämtning. Om du till exempel distribuerar en stämpel i USA och en annan stämpel i Europa ser du till att kunder i en region isoleras från avbrott i den andra regionen och kan arbeta oberoende av varandra.

Designrekommendationer

Rekommendation Förmån
Fokusera på återhämtningskrav medan du tänker på de övergripande datakraven för dina och dina kunder. Genom att grunda dina designbeslut i dessa krav kan du se till att du gör lämpliga kompromisser och undviker under- eller överkonstruktion för dina behov.
Återspegla varierande återhämtningsnivåer i din faktureringsmodell.

Ställ in förväntningar med dina kunder. Noll dataförlust vid katastrofala avbrott eller 100 % drifttid kan vara orealistiskt.		 Faktureringsmodeller kan hjälpa dina kunder att förstå hur mycket garanterad återhämtning de registrerar sig för. Med en lägre nivå får kunderna till exempel minimala garantier. På en högre nivå får kunderna mer återhämtning eftersom du har råd att replikera deras resurser i flera regioner.
Använd Azure-tillgänglighetszoner för produktionslösningar. Använd zonredundanta datalager när det är möjligt. Tillgänglighetszoner ger återhämtning mot datacenterstopp, utan att avsevärt öka kostnaden, svarstiden eller komplexiteten i din lösning.
Behåll säkerhetskopior av dina datalager i ett globalt redundant format med hjälp av replikering mellan regioner där det är tillgängligt. Säkerhetskopieringar mellan regioner av data ger en extra återhämtningsnivå.
Använd distributionsstämplar för att skapa separata instanser av lösningen på geografiskt distribuerade platser. Genom att använda distributionsstämplar för att skapa separata instanser av din lösning på geografiskt distribuerade platser kan du öka motståndskraften och ge fler fördelar, till exempel enklare driftshantering.
Utvärdera om du behöver distribution i flera regioner och om du behöver en aktiv-aktiv design för att uppfylla kraven.

Tänk på de kompromisser som är inblandade. Tillståndslösa komponenter är enklare att replikera än tillståndskänsliga komponenter som ett datalager.		 Att sprida lösningen eller stämplarna mellan regioner ger högre återhämtningsnivåer genom att replikera data mellan regioner.

Säkerhet och regelefterlevnad

Du ansvarar för att säkerställa konfidentialiteten och integriteten för dina kunders data. När du skapar en säkerhetsbaslinje bör du överväga dina säkerhetskrav och löften. Planera för att uppfylla kundernas efterlevnadsbehov, inklusive datakvarhållning.

Utformningsbeaktanden

  • Nätverk: Överväg vem som ska komma åt ditt datalager. Vanligtvis behöver bara ditt program direktkommunikation, så konfigurera det för privata nätverk.

  • Identitet: Överväg hur dina datalager ska nås. Många SaaS-lösningar använder en enda programidentitet för alla datalager, där programnivån framtvingar isolering och auktorisering. För säkerhet på radnivå eller auktorisering på databasnivå kan du behöva sprida användarens identitet till datalagret, som är komplext i en miljö med flera klientorganisationer.

  • Datakvarhållning: Planera dina principer för datakvarhållning i förväg. Att underhålla mer data ökar lagringskostnaderna och hanteringskomplexiteten. Till exempel kan stora mängder data i en transaktionsdatabas komplicera fråge- och trunkeringsprocesser.

    För långsiktig datakvarhållning, till exempel för efterlevnad eller framtida analyser, bör du överväga att flytta data till ett lager som är lämpligt för långsiktig kvarhållning.

Designrekommendationer

Rekommendation Förmån
Konfigurera dina datalager så att de använder privata slutpunkter och inaktivera offentliga slutpunkter. Den här metoden förbättrar säkerheten genom att begränsa åtkomsten till ditt interna nätverk. Genom att begränsa åtkomsten kan du minska risken för obehörig åtkomst och potentiella dataintrång.
Använd hanterade identiteter och Microsoft Entra-ID för autentisering. Undvik att använda databasnycklar eller autentiseringsuppgifter. Hanterade identiteter eliminerar behovet av databasnycklar eller autentiseringsuppgifter, vilket minskar risken för stöld av autentiseringsuppgifter och förenklar åtkomsthanteringen.
När du arbetar med delade datalager kontrollerar du att programmet omfångsbegränsar alla begäranden till en enda klientorganisation genom att inkludera klientidentifieraren i WHERE satser. Den här processen hjälper till att minska risken för dataläckage eller personifiering mellan klientorganisationer.
Planera din strategi för datakvarhållning baserat på efterlevnad och affärsbehov. Undvik att behålla onödiga historiska data. Flytta data från primära lager till arkiveringslagring för långsiktig kvarhållning. Genom att undvika onödig kvarhållning underhåller du en mindre yta.
Använd funktioner för datalager för att stödja dina datalivscykelbehov.

I Azure Cosmos DB anger du tiden för att leva på dokument. I Azure SQL implementerar du en strategi för skjutfönster med hjälp av tabellpartitionering för att minimera effekten av arkiveringsprocessen på databasen.		 Dessa metoder säkerställer effektiv datalivscykelhantering, optimerar lagringen genom att arkivera eller ta bort inaktuella data och minska manuella åtgärder när det är möjligt.

Operations

SaaS-lösningar innehåller ofta ett stort antal databaser eller andra butiker. Det är viktigt att planera för rutinmässigt underhåll av din flotta och utforska automatiseringsalternativ för att hantera dessa uppgifter effektivt.

Utformningsbeaktanden

  • Förstå teamets funktioner. Om du inte har stora team av databasadministratörer som kan utföra detaljerade analyser på enskilda kunders databaser, har du en plan för att utföra åtgärder i stor skala och använda plattformsverktyg när det är möjligt.

  • Planera dina regelbundna underhållsprocedurer. Visa en lista över de regelbundna underhållsåtgärder som behövs och deras frekvens. De specifika åtgärderna varierar beroende på vilken typ av datalager du använder. Till exempel:

    • Övervaka den totala mängden data och data som finns i specifika entiteter, till exempel viktiga tabeller.
    • Återskapa index.
    • Skapa eller ta bort index baserat på ändrade frågemönster.
    • Balansera om partitioner.

    Utforska plattformsfunktioner som kan hjälpa dig att utföra regelbundet underhåll och proaktivt leta efter nya problem. Till exempel övervakar SQL Database Advisor i Azure SQL Database problem.

  • Design för automatisering. Automatiserade åtgärder är viktiga för att en SaaS-lösning ska kunna skalas effektivt. Identifiera regelbundna och tillfälliga uppgifter och skapa spelböcker eller automatiseringsskript åt dem. För uppgifter som du inte kan automatisera omedelbart dokumenterar du processerna noggrant för att säkerställa konsekvens och tydlighet.

Designrekommendationer

Rekommendation Förmån
Sträva efter konsekvens mellan kundernas datalager när det är möjligt.

Om en kund behöver särskilda boenden kan du integrera dem i en övergripande process i stället för att anpassa konfigurationen för kunden. Använd till exempel samma schema för varje databas och använd samma processer för att distribuera och hantera dina resurser.		 Konsekvens gör det enklare att göra ändringar i stor skala och minimerar risken för oavsiktliga problem under distributioner eller underhållsförfaranden.
Distribuera begränsade resurser noggrant och sök efter möjligheter att effektivisera åtgärder. Du kan undvika små effektivitetsvinster och få bättre resursanvändning och övergripande prestanda.
Skapa automatisering för repetitiva uppgifter. Välj att köpa automatiserade verktyg i stället för att skapa en anpassad lösning.

Utforska de alternativ som plattformen och icke-Microsoft-leverantörer tillhandahåller.		 Genom att investera i kvalitetsautomatisering kan du upprepade gånger använda dessa tillgångar och minska manuella uppgifter som ofta är felbenägna. Automatiserade verktyg är värdefulla om du inte är expert på det datalager som du använder eller om du är osäker på vilka underhållsaktiviteter som krävs.
Distribuera teamets databasadministrationskapacitet noggrant. Reservera personaldatabasadministratörer för de mest effektfulla aktiviteterna, som att hantera stora kunder eller skapa automatisering som kan skalas över många kunder. Genom att prioritera värdefulla funktioner kan du maximera effektiviteten.

Kundåtkomst till data

Vissa av dina kunder kan begära direkt åtkomst till sina data för anpassad rapportering eller analys. Överväg noggrant hur kunder kan komma åt data i din lösning och om de ska bevilja dessa begäranden eller tillhandahålla alternativa metoder för att uppfylla sina behov.

Utformningsbeaktanden

  • Motivera orsaker till direkt åtkomst. Förstå varför kunder behöver åtkomst till rådata genom att få information om sina affärsproblem. Samarbeta för att hitta en lösning som uppfyller deras behov utan att införa risker för din plattform.

    Hitta alternativa sätt att uppfylla kraven i stället för att ge direkt åtkomst. Om åtkomst behövs i rapporteringssyfte är metoder på programnivå att föredra. Du kan till exempel skapa rapporter åt dem med hjälp av Microsoft Power BI, eller så kan du exportera en delmängd av dina data till en fil som du anger till dem. Du kan också skapa API:er som de kan använda för att komma åt dina data.

  • Utvärdera säkerhets- och isoleringskonsekvenser. Att ge direkt åtkomst till ett datalager innebär betydande säkerhetsrisker. Undvik att exponera interna resurser för externa parter, inklusive kunder. I en SaaS-miljö där många kunder delar en lösning är riskerna ännu högre eftersom miljön kan utnyttjas för att få åtkomst till andra kunders data.

    Överväg att ge kunderna åtkomst till sina data på ett säkert, isolerat sätt som inte påverkar ditt produktionssystem och gör att du kan göra interna ändringar i databasdesignen utan att bryta kundernas frågor.

  • Tänk på effekten på prestanda. Om du tillåter direkt åtkomst till ditt transaktionsdatalager kan det leda till prestandaproblem för huvudprogrammet. En kund kan till exempel köra en resursintensiv fråga som stör programmets funktioner.

Designrekommendationer

Rekommendation Förmån
Undvik att ge direkt åtkomst till dina datalager.

Om du måste ge direkt åtkomst ger du åtkomst till en skrivskyddad replik om dataplattformen stöder den.		 Med metoder på programnivå får du kontroll över hur kunderna använder dina data. Om det inte går att skapa konstruktioner på programnivå minskar åtkomsten via skrivskyddade repliker belastningen på kundens frågor på dina åtgärder.
Undvik att exponera information om intern implementering. Genom att kontrollera åtkomsten till dina datastrukturer hindrar du kunder från att göra antaganden om funktionerna i ditt databasschema. Med den här flexibiliteten kan du utveckla och optimera databasstrukturen över tid utan begränsningar för kundbyggda verktyg eller felaktiga antaganden.

Ytterligare resurser

Multitenancy är en viktig affärsmetod för att utforma SaaS-arbetsbelastningar. De här artiklarna innehåller mer information om datadesignöverväganden:

Gå vidare

Lär dig mer om DevOps-överväganden för SaaS-arbetsbelastningar, inklusive effektiv livscykelhantering för kunder och säkra distributionsmetoder.

Designområde: DevOps-metoder för SaaS-arbetsbelastningar i Azure