Delen via

Gegevens voor SaaS-workloads in Azure

  • Artikel

Gegevens behandelen als de meest waardevolle asset van uw oplossing. Als onafhankelijke softwareleverancier (ISV) bent u verantwoordelijk voor het beheren van de gegevens van uw klanten. Uw strategie voor het ontwerpen van gegevens en de keuze van gegevensopslag kan aanzienlijk van invloed zijn op uw klanten.

Dit artikel bevat richtlijnen voor het waarborgen van gegevensintegriteit en vertrouwelijkheid voor uw klanten, terwijl ze voldoen aan de bedrijfsprestatievereisten. Het markeert belangrijke overwegingen om u te helpen deze doelen effectief te bereiken.

Een gegevensarchief selecteren

Het gegevensarchief in een SaaS-oplossing (Software as a Service) is van invloed op de architectuur, prestaties, betrouwbaarheid en transactionele complexiteit. Vergelijk de mogelijkheden van beheerde Azure-services met vergelijkbare niet-Microsoft-aanbiedingen. In sommige situaties kunt u ook overwegen opensource-producten uit te voeren op virtuele machines.

Ontwerpoverwegingen

  • Onderscheid maken tussen uw transactionele en analytische bewerkingen. Transactionele gegevensarchieven zijn ontworpen ter ondersteuning van uw toepassingen en analytische gegevensarchieven worden gebruikt voor rapportage en taken zoals machine learning. Deze winkels zijn gebouwd met gespecialiseerde producten en hebben unieke behoeften voor prestaties, toegangspatronen, schema's en gebruiksvoorbeelden.

    Deze handleiding is gericht op transactionele gegevensarchieven.

  • Inzicht in uw gegevensbehoeften. Schat het volume, de frequentie waarmee het kan worden gewijzigd en het type gegevens dat u moet opslaan.

    Verwacht dat gegevens na verloop van tijd aanzienlijk toenemen. Voor SaaS-oplossingen vindt groei plaats in meerdere dimensies. Verwacht een toename van het volume en de typen gegevens naarmate het aantal klanten toeneemt. Zorg ervoor dat u die groei plant en investeert in technologieën die deze kunnen ondersteunen.

    Bepaal tussen een relationeel of niet-relationeel gegevensplatform op basis van de aard van uw gegevens. Voor veel transactionele workloads is een relationele database een goede optie voor het modelleren van toepassingsentiteiten als discrete tabellen. Met deze benadering kunnen query's worden uitgevoerd in het relationele gegevensmodel. Als uw gegevens op natuurlijke wijze bij een documentmodel passen of een grafiekstructuur volgen, is een niet-relationele benadering mogelijk geschikter.

    Zie SQL versus NoSQL-gegevensplatforms voor meer informatie.

  • Minimaliseer de typen gegevensarchieven. Het opslaan van verschillende typen gegevens in meerdere, afzonderlijke gegevensarchieven kan nuttig zijn voor volwassen organisaties die expertise hebben op verschillende gegevensplatforms. Deze benadering introduceert echter vaak onnodige complexiteit voor start-ups en kleinere organisaties. Het is effectiever om u te richten op een of een klein aantal gegevensarchieven.

    Als u niet beschikt over de zakelijke reden voor het gebruik van meerdere gegevensarchieven, kunt u zich richten op een of een klein aantal gegevensarchieven.

  • Gebruik wat je weet en investeer erin. Als uw team al ervaring heeft met een specifiek gegevensarchief, is het vaak beter om dat gegevensarchief te gebruiken in plaats van te investeren in het leren van nieuwe vaardigheden. Gegevensarchieven en platforms zijn complex en ontwerpbeslissingen kunnen moeilijk omkeren.

    Houd echter rekening met de potentiële groei. Als uw huidige gegevensarchief niet meer aan uw vereisten voldoet, kiest u een gegevensarchief dat de prestaties, tolerantie, beveiliging en operationele efficiëntie van uw oplossing kan verbeteren. Het moet uw team ook helpen hun expertise te verdiepen.

Ontwerpaanaanvelingen

Aanbeveling Voordeel
Scheid transactionele gegevensarchieven voor dagelijkse bewerkingen uit analytische en rapportagegegevensarchieven. Het combineren van de intentie van uw gegevensarchieven kan leiden tot onnodige complexiteit. Gegevenssegmentatie verbetert de operationele efficiëntie en maximaliseert het gebruik van elk gegevensarchief.
Kies tussen een relationele of niet-relationele gegevensstructuur op basis van uw vereisten. Begin met een of een klein aantal gegevensarchieven.

Prioriteit geven aan beheerde gegevensarchieven. Veelvoorkomende keuzes zijn Azure Cosmos DB, Azure SQL, MySQL, MongoDB en PostgreSQL.		 Deze aanpak helpt de complexiteit te minimaliseren en zorgt ervoor dat u het juiste product gebruikt om de efficiëntie te maximaliseren. Beheerde gegevensarchieven bieden flexibiliteit bij het beheren van resources en kosten elastisch en schalen met uw behoeften. Het gebruik van beheerde gegevensarchieven zorgt voor minder beheerlast dan het implementeren van uw eigen gegevensarchief in uw eigen infrastructuur.
Investeer in het leren van uw gekozen technologie. Zorg ervoor dat uw team de hoge schaalvereisten en andere complexiteit van SaaS-oplossingen beheert. Meer informatie over de hulpprogramma's die u gebruikt en hun bredere ecosysteem, zodat u uw gegevensplatform effectief kunt gebruiken wanneer u schaalt.
Gebruik flexibiliteit in uw gegevensontwerp. Naarmate uw SaaS-oplossing groeit of uw vereisten veranderen, kunt u zich aanpassen door gegevensarchieven toe te voegen of te wijzigen. Dankzij deze flexibiliteit kunt u beginnen met één gegevensarchief en zich in de loop van de tijd ontwikkelen om aan uw behoeften te voldoen.

Tenancymodel en databasestrategie

Een belangrijk aspect van het gegevensontwerp is de beslissing om resources te hosten namens uw klanten of om resources in hun omgeving te hosten. De meeste SaaS-providers hosten resources voor alle klanten, wat flexibiliteit biedt in databasebeheer. Als u resources host in de omgeving van de klant, kunt u overwegen hoe u deze resources opent en beheert.

Ontwerpoverwegingen

  • Plan de databasesegmentatie. In SaaS-oplossingen (business-to-business) wordt u aangeraden speciale databases te maken voor elke klant. Deze aanpak verbetert de gegevensbeveiliging door strikte isolatie tussen klanten te handhaven, waardoor het risico op gegevensmixing wordt verminderd en door de klant beheerde versleutelingssleutels wordt ondersteund. Het helpt u ook om te voldoen aan wettelijke nalevingsvereisten voor sommige klanten.

    Door klantgegevens in afzonderlijke databases te scheiden, kunnen de prestaties worden verbeterd door problemen met lawaaierige buren te minimaliseren. Sommige beheerde gegevensarchieven omvatten beheeropties voor resourcetoewijzing om deze problemen te verhelpen, kostenefficiëntie te bieden en hulpprogramma's op te nemen voor het beheren van meerdere databases op schaal.

    In sommige gevallen is het handig om de gegevens van meerdere klanten op te slaan in één gegevensarchief. In B2C-oplossingen (Business-to-Consumer) kunt u bijvoorbeeld gegevens opslaan in één archief met logische partitionering op basis van klant-id. In B2B-oplossingen die onderdelen delen, kunt u één gegevensarchief gebruiken voor specifieke onderdelen, zoals een gebeurtenisarchief, terwijl u ervoor zorgt dat u klant-id's op elke gebeurtenis opneemt.

  • Collocate-gegevensarchieven met toepassingsonderdelen. Als u resources host namens de klant, implementeert u deze in dezelfde Azure-regio om uitgaande bandbreedtekosten en latentie te voorkomen. Wanneer u toepassingen en gegevensarchieven host in de omgeving van een klant, implementeert u deze samen in dezelfde omgeving om complexe omgevingen te voorkomen.

  • Standaardiseer het beheer van gegevensarchieven net zo veel als praktisch. Uniformiteit is essentieel voor het beheren van gegevens voor klanten. Naarmate uw bedrijf groeit, vergroten de verschillen tussen klanten het risico en de complexiteit. Deze verschillen kunnen ook productiestoringen waarschijnlijker maken en het oplossen van problemen moeilijker maken.

    Vermijd eenmalige wijzigingen in uw beheer om individuele klanten te ondersteunen. Als u bijvoorbeeld door de klant beheerde metagegevens wilt ondersteunen, moet u schemawijzigingen voorkomen, zoals het toevoegen van extra kolommen aan uw database. Bouw in plaats daarvan functionaliteit voor klanten om hun eigen metagegevens toe te voegen. Als u voor verschillende klanten verschillende niveaus van databaseprestaties wilt opgeven, maakt u één proces dat u kunt gebruiken om verschillende configuraties toe te passen op verschillende lagen van klanten.

Zie voor meer informatie over hoe uw tenancymodel van invloed is op uw gegevensstrategie.

Ontwerpaanaanvelingen

Aanbeveling Voordeel
Evalueer of u databases wilt delen tussen meerdere klanten of een gedeeld gegevensplatform wilt bieden.

Implementeer waar nodig één database voor de gegevens van elke klant. Versoepeling van deze strategie als strikte isolatie geen vereiste is, zoals in B2C-oplossingen.		 Deze aanpak minimaliseert problemen met ruis en kan nalevingsvereisten voor sommige klanten ondersteunen.
Implementeer toepassingen en hun databases in dezelfde regio. Deze methode optimaliseert de bandbreedtekosten en latentie die worden gemaakt door databasetoegang tussen regio's.
Ontwerp een gestandaardiseerde benadering voor het opslaan van door de klant gedefinieerde gegevens of metagegevens. Vermijd het wijzigen van het schema voor afzonderlijke klanten of het veroorzaken van verschillende klantomgevingen. Met deze aanpak voorkomt u de operationele last van het beheren van inconsistenties tussen databases voor elke klant.
Plan routineonderhoudsbewerkingen in de door de klant geïmplementeerde omgeving.

Plan hoe u toegang wilt krijgen tot de database voor updates, schemawijzigingen, onderhoud en andere bewerkingen.		 Deze proactieve aanpak minimaliseert problemen vanwege gebrek aan onderhoud en vermindert het risico op downtime en prestatieproblemen.

Capaciteit plannen

Capaciteitsplanning verwijst naar het beheer van resourcegebruik, met een focus op CPU-, geheugen-, opslag- en schijfbewerkingen zoals invoer- en uitvoerbewerkingen per seconde (IOPS). Sommige gegevensarchieven combineren deze resources in een eenvoudige, synthetische metrische gegevens over resourceverbruik, zoals een databasedoorvoereenheid (DTU) in Azure SQL of een aanvraageenheid (RU) in Azure Cosmos DB. Beheerde gegevensarchieven bieden flexibiliteit in resourcebeheer, waardoor wijzigingen in de loop van de tijd mogelijk zijn. Het is van cruciaal belang om een eerste plan op te stellen en te herhalen naarmate uw behoeften zich ontwikkelen.

Ontwerpoverwegingen

  • Inzicht in uw resourcetoewijzingsvereisten. Verschillende klanten in SaaS-oplossingen hebben mogelijk verschillende resourcebehoeften. Kleinere klanten hebben mogelijk minimale resources nodig en grotere klanten hebben mogelijk meer nodig. Grotere klanten betalen vaak meer, wat hogere resourcetoewijzing rechtvaardigt. Door afzonderlijke databases voor elke klant te gebruiken, kunt u de resourcetoewijzing aanpassen op basis van hun grootte en behoeften.

  • Inzicht in de verschillende capaciteitsmodellen die gegevensplatformen bieden. Cloudgegevensplatforms bieden vaak meerdere resourcemodellen. Sommige Azure-services zoals Azure Cosmos DB bieden bijvoorbeeld ingerichte, op doorvoer gebaseerde modellen en serverloze modellen. Azure SQL Database biedt ook elastische pools.

    Voor ingerichte doorvoer is vooraf bepaalde resourcetoewijzing vereist, hetzij vanuit één database of een groep databases. Elastische pools maken het delen van resources tussen meerdere databases mogelijk. Elastische pools worden vaak gebruikt in SaaS-oplossingen.

    Hoewel ingerichte doorvoer vereist dat u vooraf resources toewijst, bieden services zoals Azure Cosmos DB automatisch schalen doorvoer. U kunt regels instellen voor het dynamisch toevoegen of verwijderen van resources op basis van opgegeven triggers.

    Serverloze resourcemodellen worden automatisch geschaald op basis van de vraag. Deze mogelijkheid maakt ze een goed uitgangspunt als u uw capaciteitsvereisten niet van tevoren kunt voorspellen. Ze kunnen echter minder functies ondersteunen en kostenefficiënt worden naarmate u groeit. Serverloze modellen zijn beschikbaar in Azure SQL Database en Azure Cosmos DB.

Ontwerpaanaanvelingen

Aanbeveling Voordeel
Modelleer uw databasevereisten voor elke klant. Bepaal of u veel kleine databases, minder grote databases of een combinatie van de twee moet hebben.

Gebruik een t-shirt-formaatoefening om klanten te categoriseren in kleine, middelgrote en grote buckets.		 Deze benadering biedt een ruwe schatting van de resources die per klant nodig zijn en helpt u klanten toe te wijzen aan uw factureringsmodel.
Segmenteer resourcegroepen op basis van de grootte van de klantdatabases die deze gebruiken.

Gebruik ingerichte capaciteit in uw voordeel. U kunt bijvoorbeeld een gedeelde elastische SQL-pool maken voor kleinere klanten, een afzonderlijke pool voor middelgrote klanten en toegewezen resources voor grote klanten.		 Door resourcegroepen te segmenteren op basis van de databasegrootte van uw klanten, kunt u resourcetoewijzing en kostenefficiëntie optimaliseren.
Profiteer van de ingebouwde schaalmogelijkheden die de beheerde services bieden. U kunt schaalverantwoordelijkheden naar het platform offloaden. Functies zoals elastische pools en automatische schaalaanpassing kunnen helpen bij het optimaliseren van resourcegebruik.
Controleer regelmatig serverloze gegevensarchieven om ervoor te zorgen dat ze blijven voldoen aan uw behoeften. U kunt ervoor zorgen dat het gegevensarchief effectief blijft met uw veranderende behoeften. Optimaliseer de prestaties en kostenefficiëntie naarmate uw vereisten veranderen.

Hoge beschikbaarheid en herstel na noodgevallen

Klanten van SaaS-oplossingen hebben vaak hoge verwachtingen voor hoge beschikbaarheid (HA) en herstel na noodgevallen (DR). Als uw klanten in gereguleerde branches werken of afhankelijk zijn van uw oplossing voor dagelijkse activiteiten, zijn hun vereisten mogelijk nog strenger.

Hoge beschikbaarheid en herstel na noodgevallen zijn geen oplossingen die geschikt zijn voor alle oplossingen en zijn afhankelijk van verschillende factoren. Krijg een duidelijk inzicht in de beschikbare opties die van toepassing zijn op de vereisten van zowel u als uw klanten om weloverwogen beslissingen te nemen over het beperken van verschillende risico's.

Compromis: betrouwbaarheid, kosten en prestaties: Tolerantie voor gegevensservices vereist vaak het distribueren van replica's of kopieën van uw gegevens in een breder geografisch gebied om risico's te beperken. Er zijn echter compromissen. Hoe langer de afstand die gegevens moeten afleggen, hoe meer bescherming u hebt tegen gelokaliseerde fouten. Maar het kopiëren van gegevens over langere afstanden verhoogt de latentie en kost vaak meer. Veel beheerde gegevensarchieven bieden geautomatiseerde gegevensreplicatie, maar ze kunnen limieten opleggen voor de typen replicatie die u op verschillende afstanden kunt uitvoeren om de prestaties te behouden.

Ontwerpoverwegingen

  • Kwantificeren van tolerantie. Meet tolerantievereisten met behulp van serviceniveaudoelstellingen (SLO's), waaronder metrische gegevens zoals uptime, hersteltijd en herstelpunt. Deze metrische gegevens worden aangestuurd door zowel uw zakelijke vereisten als die van uw klanten, die mogelijk verschillende behoeften hebben. Als u grote hoeveelheden gegevens opslaat namens uw klanten, moet uw oplossing voor hoge beschikbaarheid en herstel na noodgevallen mogelijk complexer zijn om te voldoen aan strenge vereisten.

    Zie RE:04-aanbevelingen voor het definiëren van betrouwbaarheidsdoelen voor meer informatie over metrische tolerantiegegevens.

  • Platformfuncties gebruiken. Azure biedt mogelijkheden voor tolerantie binnen een datacenter, binnen een regio met behulp van beschikbaarheidszones en in een breder geografisch gebied met behulp van meerdere regio's. Combineer strategieën zoals beschikbaarheidszones, back-ups tussen regio's en implementaties in meerdere regio's om het juiste tolerantieniveau voor uw oplossing te bereiken. Voor hoge tolerantievereisten kunt u een multiregion-, actief-passieve architectuur met asynchrone gegevensreplicatie tussen regio's overwegen. Deze benadering kan leiden tot gegevensverlies tijdens een catastrofale storing.

    Compromis: multiregio-, actief-actieve ontwerpen met replicatie zijn de meest tolerante, maar zijn complex om te bouwen en te testen. Voor de meeste actief-actieve oplossingen moet u een conflictoplossingsbenadering ontwerpen die rekening houden met vertragingen in gegevenssynchronisatie. De meeste oplossingen hebben deze mate van tolerantie niet nodig.

    Raadpleeg RE:05-aanbevelingen voor het gebruik van beschikbaarheidszones en regio's.

  • Gebruik implementatiestempels om de straalstraal van onderdelen te isoleren. Het patroon implementatiestempels wordt veel gebruikt in SaaS-oplossingen, omdat het voordelen biedt voor implementatie, beheer, prestaties en tolerantie. Als u bijvoorbeeld één stempel implementeert in de Verenigde Staten en een andere stempel in Europa, zorgt u ervoor dat klanten in de ene regio worden geïsoleerd van storingen in de andere regio en onafhankelijk kunnen werken.

Ontwerpaanaanvelingen

Aanbeveling Voordeel
Richt u op tolerantievereisten terwijl u nadenkt over de algemene gegevensvereisten voor uw en uw klanten. Door uw ontwerpbeslissingen in deze vereisten te onderbouwen, kunt u ervoor zorgen dat u de juiste compromissen neemt en te weinig of te veel engineering voor uw behoeften vermijdt.
Geef verschillende niveaus van tolerantie weer in uw factureringsmodel.

Stel verwachtingen in bij uw klanten. Geen gegevensverlies tijdens catastrofale storingen of 100% uptime kan onrealistisch zijn.		 Factureringsmodellen kunnen uw klanten helpen te begrijpen voor hoeveel gegarandeerde tolerantie ze zich registreren. Met een lagere laag krijgen klanten bijvoorbeeld minimale garanties. In een hogere laag krijgen klanten meer tolerantie omdat u zich kunt veroorloven om hun resources in meerdere regio's te repliceren.
Azure-beschikbaarheidszones gebruiken voor productieoplossingen. Gebruik indien mogelijk zoneredundante gegevensarchieven. Beschikbaarheidszones bieden tolerantie tegen storingen in datacenters, zonder de kosten, latentie of complexiteit van uw oplossing aanzienlijk te verhogen.
Bewaar back-ups van uw gegevensarchieven in een wereldwijd redundante indeling met behulp van replicatie tussen regio's, indien beschikbaar. Back-ups van gegevens in meerdere regio's voegen een extra tolerantieniveau toe.
Gebruik implementatiestempels om afzonderlijke exemplaren van uw oplossing te maken op geografisch gedistribueerde locaties. Door implementatiestempels te gebruiken om afzonderlijke exemplaren van uw oplossing te maken op geografisch gedistribueerde locaties, kunt u de tolerantie vergroten en meer voordelen bieden, zoals eenvoudiger operationeel beheer.
Evalueer of u implementatie met meerdere regio's nodig hebt en of u een actief-actief ontwerp nodig hebt om te voldoen aan de vereisten.

Houd rekening met de compromissen die hierbij betrokken zijn. Staatloze onderdelen zijn eenvoudiger te repliceren dan stateful onderdelen zoals een gegevensarchief.		 Het spreiden van uw oplossing of stempels in verschillende regio's biedt een hogere mate van tolerantie door gegevens tussen regio's te repliceren.

Beveiliging en naleving

U bent verantwoordelijk voor het waarborgen van de vertrouwelijkheid en integriteit van de gegevens van uw klanten. Houd bij het bouwen van een beveiligingsbasislijn rekening met uw beveiligingsvereisten en beloften. Plan om te voldoen aan de nalevingsbehoeften van uw klanten, inclusief gegevensretentie.

Ontwerpoverwegingen

  • Netwerken: Overweeg wie toegang heeft tot uw gegevensarchief. Normaal gesproken heeft alleen uw toepassing directe communicatie nodig, dus configureer deze voor alleen-privénetwerken.

  • Identiteit: Bedenk hoe uw gegevensarchieven worden geopend. Veel SaaS-oplossingen gebruiken één toepassingsidentiteit voor alle gegevensarchieven, waarbij de toepassingslaag isolatie en autorisatie afdwingt. Voor beveiliging op rijniveau of autorisatie op databaseniveau moet u mogelijk de identiteit van de gebruiker doorgeven aan het gegevensarchief, wat complex is in een omgeving met meerdere tenants.

  • Gegevensretentie: plan vooraf uw bewaarbeleid voor gegevens. Het onderhouden van meer gegevens verhoogt de opslagkosten en beheercomplexiteit. Grote hoeveelheden gegevens in een transactionele database kunnen bijvoorbeeld het uitvoeren van query's en afkappen van processen bemoeilijken.

    Voor langetermijnretentie van gegevens, zoals voor naleving of toekomstige analyses, kunt u overwegen om gegevens te verplaatsen naar een archief dat geschikt is voor langetermijnretentie.

Ontwerpaanaanvelingen

Aanbeveling Voordeel
Configureer uw gegevensarchieven voor het gebruik van privé-eindpunten en schakel openbare eindpunten uit. Deze aanpak verbetert de beveiliging door de toegang tot uw interne netwerk te beperken. Door de toegang te beperken, kunt u het risico op onbevoegde toegang en mogelijke gegevensschendingen beperken.
Gebruik beheerde identiteiten en Microsoft Entra-id voor verificatie. Vermijd het gebruik van databasesleutels of -referenties. Beheerde identiteiten elimineren de noodzaak van databasesleutels of referenties, waardoor het risico op diefstal van referenties wordt verminderd en het toegangsbeheer wordt vereenvoudigd.
Wanneer u met gedeelde gegevensarchieven werkt, moet u ervoor zorgen dat de toepassing alle aanvragen voor één tenant bereikt door de tenant-id in WHERE componenten op te nemen. Dit proces helpt het risico op gegevenslekken of imitatie tussen tenants te beperken.
Plan uw strategie voor gegevensretentie op basis van naleving en bedrijfsbehoeften. Vermijd onnodige historische gegevens. Voor langetermijnretentie verplaatst u gegevens van primaire winkels naar archiveringsopslag. Door onnodige retentie te voorkomen, onderhoudt u een kleiner oppervlak.
Gebruik functies voor gegevensopslag ter ondersteuning van de behoeften van uw gegevenslevenscyclus.

Stel in Azure Cosmos DB de time to live in op documenten. Implementeer in Azure SQL een strategie voor schuifvensters met behulp van tabelpartitionering om de impact van het archiveringsproces op de database te minimaliseren.		 Deze benaderingen zorgen voor efficiënt beheer van de levenscyclus van gegevens, optimaliseren van opslag door verouderde gegevens te archiveren of te verwijderen, en handmatige interventie te verminderen, indien mogelijk.

Operations

SaaS-oplossingen omvatten vaak een groot aantal databases of andere winkels. Het is belangrijk om routineonderhoud op uw vloot te plannen en automatiseringsopties te verkennen om deze taken efficiënt te beheren.

Ontwerpoverwegingen

  • Inzicht in de mogelijkheden van uw team. Als u geen grote teams van databasebeheerders hebt die gedetailleerde analyses kunnen uitvoeren op de databases van afzonderlijke klanten, hebt u een plan om bewerkingen op schaal uit te voeren en waar mogelijk platformhulpprogramma's te gebruiken.

  • Plan uw reguliere onderhoudsprocedures. Vermeld de regelmatige onderhoudswerkzaamheden die nodig zijn en hun frequentie. De specifieke bewerkingen variëren op basis van het type gegevensarchief dat u gebruikt. Voorbeeld:

    • Bewaak de totale hoeveelheid gegevens en gegevens die zich in specifieke entiteiten bevinden, zoals belangrijke tabellen.
    • Indexen opnieuw opbouwen.
    • Indexen maken of verwijderen op basis van het wijzigen van querypatronen.
    • Partities opnieuw verdelen.

    Verken platformfuncties waarmee u regelmatig onderhoud kunt uitvoeren en proactief kunt zoeken naar nieuwe problemen. SQL Database Advisor in Azure SQL Database bewaakt bijvoorbeeld op problemen.

  • Ontwerpen voor automatisering. Geautomatiseerde bewerkingen zijn essentieel voor een SaaS-oplossing om effectief te schalen. Identificeer reguliere en incidentele taken en maak playbooks of automatiseringsscripts voor deze taken. Voor taken die u niet onmiddellijk kunt automatiseren, moet u de processen grondig documenteren om consistentie en duidelijkheid te garanderen.

Ontwerpaanaanvelingen

Aanbeveling Voordeel
Streven naar consistentie tussen de gegevensarchieven van klanten, indien mogelijk.

Als een klant speciale accommodaties nodig heeft, integreert u deze in een algemeen proces in plaats van de configuratie voor die klant aan te passen. Gebruik bijvoorbeeld hetzelfde schema voor elke database en gebruik dezelfde processen om uw resources te implementeren en te beheren.		 Consistentie maakt het eenvoudiger om wijzigingen op schaal aan te brengen en het risico op onbedoelde problemen tijdens implementaties of onderhoudsprocedures te minimaliseren.
Implementeer beperkte resources zorgvuldig en zoek mogelijkheden om bewerkingen te stroomlijnen. U kunt kleine efficiënties voorkomen en beter resourcegebruik en algehele prestaties hebben.
Bouw automatisering voor terugkerende taken. Kies ervoor om geautomatiseerde hulpprogramma's te kopen in plaats van een aangepaste oplossing te bouwen.

Bekijk de opties die het platform en niet-Microsoft-leveranciers bieden.		 Door te investeren in kwaliteitsautomatisering, kunt u deze assets herhaaldelijk gebruiken en handmatige taken verminderen die vaak gevoelig zijn voor fouten. Geautomatiseerde hulpprogramma's zijn waardevol als u geen expert bent in het gegevensarchief dat u gebruikt of als u niet zeker weet wat de benodigde onderhoudstaken zijn.
Implementeer de databasebeheercapaciteit van uw team zorgvuldig. Reserveer menselijke databasebeheerders voor de meest impactvolle activiteiten, zoals het omgaan met grote klanten of het bouwen van automatisering die voor veel klanten kan worden geschaald. Door waardevolle functies te prioriteren, kunt u de efficiëntie maximaliseren.

Klanttoegang tot gegevens

Sommige van uw klanten kunnen directe toegang tot hun gegevens aanvragen voor aangepaste rapportage of analyse. Overweeg zorgvuldig hoe klanten toegang hebben tot gegevens in uw oplossing en of ze deze aanvragen moeten verlenen of alternatieve methoden bieden om aan hun behoeften te voldoen.

Ontwerpoverwegingen

  • Redenen voor directe toegang rechtvaardigen. Begrijp waarom klanten toegang nodig hebben tot onbewerkte gegevens door informatie over hun bedrijfsprobleem op te halen. Werk samen om een oplossing te vinden die aan hun behoeften voldoet zonder risico's voor uw platform te introduceren.

    Zoek alternatieve manieren om te voldoen aan de vereisten in plaats van directe toegang te verlenen. Als toegang nodig is voor rapportagedoeleinden, hebben methoden voor toepassingslagen de voorkeur. U kunt bijvoorbeeld rapporten voor hen maken met behulp van Microsoft Power BI of u kunt een subset van uw gegevens exporteren naar een bestand dat u aan hen opgeeft. U kunt ook API's maken die ze kunnen gebruiken om toegang te krijgen tot uw gegevens.

  • Beveiligings- en isolatieproblemen evalueren. Het bieden van directe toegang tot een gegevensarchief vormt aanzienlijke beveiligingsrisico's. Vermijd het blootstellen van interne resources aan externe partijen, inclusief klanten. In een SaaS-omgeving met veel klanten die een oplossing delen, zijn de risico's nog hoger omdat de omgeving kan worden misbruikt om toegang te krijgen tot de gegevens van andere klanten.

    Overweeg klanten toegang te geven tot hun gegevens op een veilige, geïsoleerde manier die geen invloed heeft op uw productiesysteem en u kunt interne databaseontwerpwijzigingen aanbrengen zonder de query's van klanten te verbreken.

  • Houd rekening met het effect op prestaties. Het toestaan van directe toegang tot uw transactionele gegevensarchief kan leiden tot prestatieproblemen voor uw hoofdtoepassing. Een klant kan bijvoorbeeld een resource-intensieve query uitvoeren die de functionaliteit van de toepassing verstoort.

Ontwerpaanaanvelingen

Aanbeveling Voordeel
Vermijd directe toegang tot uw gegevensarchieven.

Als u directe toegang moet verlenen, geeft u toegang tot een alleen-lezen replica op als het gegevensplatform dit ondersteunt.		 Met benaderingen voor toepassingslagen kunt u bepalen hoe klanten uw gegevens gebruiken. Als het niet mogelijk is om constructies op de toepassingslaag te maken, vermindert de toegang via alleen-lezen replica's de belasting van de query's van de klant voor uw bewerkingen.
Vermijd het blootstellen van interne implementatiedetails. Door de toegang tot uw gegevensstructuren te beheren, voorkomt u dat klanten veronderstellingen maken over de functionaliteit van uw databaseschema. Dankzij deze flexibiliteit kunt u uw databasestructuur in de loop van de tijd ontwikkelen en optimaliseren zonder de beperkingen van door de klant gebouwde hulpprogramma's of onnauwkeurige veronderstellingen.

Aanvullende bronnen

Multitenancy is een kernbedrijfsmethodologie voor het ontwerpen van SaaS-workloads. Deze artikelen bevatten meer informatie over overwegingen bij het ontwerpen van gegevens:

Volgende stap

Meer informatie over DevOps-overwegingen voor SaaS-workloads, waaronder efficiënt levenscyclusbeheer van klanten en veilige implementatieprocedures.

Ontwerpgebied: DevOps-procedures voor SaaS-workloads in Azure