Uitbreiden met Azure SQL Database

Van toepassing op: Azure SQL Database

U kunt eenvoudig databases uitschalen in Azure SQL Database met behulp van de elastic database-hulpprogramma's . Met deze hulpprogramma's en functies kunt u de databasebronnen van Azure SQL Database gebruiken om oplossingen te maken voor transactionele workloads, en met name SaaS-toepassingen (Software as a Service). Elastic Database-functies bestaan uit:

• Elastic Database-clientbibliotheek: de clientbibliotheek is een functie waarmee u shard-databases kunt maken en onderhouden. Zie Aan de slag met elastic database-hulpprogramma's.
• Hulpprogramma voor splitsen en samenvoegen van elastische databases: verplaatst gegevens tussen shard-databases. Dit hulpprogramma is handig voor het verplaatsen van gegevens van een database met meerdere tenants naar een database met één tenant (of omgekeerd). Zie de zelfstudie voor het hulpprogramma Split-Merge voor elastische databases.
• Elastische databasetaken (preview): Gebruik taken om grote aantallen databases in Azure SQL Database te beheren. Voer eenvoudig beheerbewerkingen uit, zoals schemawijzigingen, referentiegegevensbeheer, updates van referentiegegevens, het verzamelen van prestatiegegevens of het verzamelen van tenanttelemetriegegevens (klant) met behulp van taken.
• Elastische databasequery (preview): hiermee kunt u een Transact-SQL-query uitvoeren die meerdere databases omvat. Hiermee kunt u verbinding maken met rapportagehulpprogramma's zoals Excel, Power BI, Tableau, enzovoort.
• Elastische transacties: met deze functie kunt u transacties uitvoeren die meerdere databases omvatten. Transacties voor elastische databases zijn beschikbaar voor .NET-toepassingen met behulp van ADO .NET en kunnen worden geïntegreerd met de vertrouwde programmeerervaring met behulp van de System.Transaction-klassen.

In de volgende afbeelding ziet u een architectuur die de functies van Elastic Database bevat ten opzichte van een verzameling databases.

In deze afbeelding vertegenwoordigen kleuren van de database schema's. Databases met dezelfde kleur delen hetzelfde schema.

1. Een set SQL-databases wordt gehost in Azure met behulp van sharding-architectuur.
2. De elastic database-clientbibliotheek wordt gebruikt voor het beheren van een shardset.
3. Een subset van de databases wordt in een elastische pool geplaatst. (Zie Wat is een pool?).
4. Een Elastic Database-taak voert geplande of ad-hoc T-SQL-scripts uit voor alle databases.
5. Het hulpprogramma splitsen en samenvoegen wordt gebruikt om gegevens van de ene shard naar de andere te verplaatsen.
6. Met de elastische databasequery kunt u een query schrijven die alle databases in de shardset omvat.
7. Met elastische transacties kunt u transacties uitvoeren die meerdere databases omvatten.

Waarom de hulpprogramma's gebruiken?

Het bereiken van elasticiteit en schaal voor cloudtoepassingen is heel eenvoudig voor VM's en blobopslag: gewoon eenheden optellen of aftrekken of de kracht verhogen. Maar het is een uitdaging gebleven voor stateful gegevensverwerking in relationele databases. Er zijn uitdagingen ontstaan in deze scenario's:

• De capaciteit voor het relationele databasegedeelte van uw workload vergroten en verkleinen.
• Het beheren van hotspots die zich kunnen voordoen die van invloed kunnen zijn op een specifieke subset van gegevens, zoals een drukke eindklant (tenant).

Normaal gesproken zijn scenario's zoals deze aangepakt door te investeren in grootschalige servers ter ondersteuning van de toepassing. Deze optie is echter beperkt in de cloud waar alle verwerking plaatsvindt op vooraf gedefinieerde basishardware. In plaats daarvan biedt het distribueren van gegevens en verwerking in veel identiek gestructureerde databases (een uitschaalpatroon dat bekend staat als 'sharding') een alternatief voor traditionele opschaalmethoden, zowel wat kosten als elasticiteit betreft.

Horizontaal en verticaal schalen

In de volgende afbeelding ziet u de horizontale en verticale dimensies van schalen. Dit zijn de basis manieren waarop de elastische databases kunnen worden geschaald.

Horizontaal schalen verwijst naar het toevoegen of verwijderen van databases om de capaciteit of algehele prestaties aan te passen, ook wel 'uitschalen' genoemd. Sharding, waarin gegevens worden gepartitioneerd in een verzameling identieke gestructureerde databases, is een veelgebruikte manier om horizontaal schalen te implementeren.

Verticaal schalen verwijst naar het vergroten of verkleinen van de rekenkracht van een afzonderlijke database, ook wel 'omhoog schalen' genoemd.

De meeste databasetoepassingen in de cloud gebruiken een combinatie van deze twee strategieën. Een Software as a Service-toepassing kan bijvoorbeeld horizontaal schalen gebruiken om nieuwe eindklanten en verticale schaalaanpassing in te richten, zodat de database van elke eindgebruiker resources kan vergroten of verkleinen als dat nodig is voor de workload.

• Horizontaal schalen wordt beheerd met behulp van de elastic database-clientbibliotheek.
• Verticaal schalen wordt bereikt met behulp van Azure PowerShell-cmdlets om de servicelaag te wijzigen of door databases in een elastische pool te plaatsen.

Sharding

Sharding is een techniek waarbij grote hoeveelheden identiek gestructureerde gegevens worden gedistribueerd over een aantal onafhankelijke databases. Het is vooral populair bij cloudontwikkelaars die SaaS-aanbiedingen (Software as a Service) maken voor eindgebruikers of bedrijven. Deze eindklanten worden vaak 'tenants' genoemd. Sharding kan om een aantal redenen vereist zijn:

• De totale hoeveelheid gegevens is te groot om binnen de beperkingen van een individuele database te passen
• De transactiedoorvoer van de totale workload overschrijdt de mogelijkheden van een afzonderlijke database
• Tenants vereisen mogelijk fysieke isolatie van elkaar, dus er zijn afzonderlijke databases nodig voor elke tenant
• Verschillende secties van een database moeten zich mogelijk in verschillende geografische gebieden bevinden om naleving, prestaties of geopolitieke redenen.

In andere scenario's, zoals het opnemen van gegevens van gedistribueerde apparaten, kan sharding worden gebruikt om een set databases te vullen die tijdelijk zijn geordend. Een afzonderlijke database kan bijvoorbeeld worden toegewezen aan elke dag of week. In dat geval kan de shardingsleutel een geheel getal zijn dat de datum aangeeft (aanwezig in alle rijen van de shardtabellen) en query's die informatie ophalen voor een datumbereik moeten worden doorgestuurd door de toepassing naar de subset van databases die betrekking hebben op het betreffende bereik.

Sharding werkt het beste wanneer elke transactie in een toepassing kan worden beperkt tot één waarde van een shardingsleutel. Dit zorgt ervoor dat alle transacties lokaal zijn voor een specifieke database.

Meerdere tenants en één tenant

Sommige toepassingen gebruiken de eenvoudigste benadering van het maken van een afzonderlijke database voor elke tenant. Deze benadering is het shardingpatroon voor één tenant dat isolatie, mogelijkheid voor back-up/herstel en het schalen van resources biedt op de granulariteit van de tenant. Bij sharding van één tenant is elke database gekoppeld aan een specifieke tenant-id-waarde (of klantsleutelwaarde), maar die sleutel hoeft niet altijd aanwezig te zijn in de gegevens zelf. Het is de verantwoordelijkheid van de toepassing om elke aanvraag naar de juiste database te routeren. De clientbibliotheek kan dit vereenvoudigen.

Andere scenario's verpakken meerdere tenants in databases, in plaats van ze te isoleren in afzonderlijke databases. Dit patroon is een typisch shardingpatroon voor meerdere tenants. Dit kan worden veroorzaakt door het feit dat een toepassing grote aantallen kleine tenants beheert. Bij sharding met meerdere tenants zijn de rijen in de databasetabellen allemaal ontworpen om een sleutel te dragen die de tenant-id of shardingsleutel identificeert. Ook hier is de toepassingslaag verantwoordelijk voor het routeren van de aanvraag van een tenant naar de juiste database. Dit kan worden ondersteund door de clientbibliotheek van de elastische database. Bovendien kan beveiliging op rijniveau worden gebruikt om te filteren welke rijen elke tenant kan openen. Zie multitenanttoepassingen met hulpmiddelen voor elastische databases en beveiliging op rijniveau voor meer informatie. Het opnieuw distribueren van gegevens tussen databases kan nodig zijn met het shardingpatroon voor meerdere tenants en wordt mogelijk vergemakkelijkt door het hulpprogramma voor splitsen en samenvoegen van elastische databases. Zie Ontwerppatronen voor SaaS-toepassingen met meerdere tenants met behulp van Azure SQL Database voor meer informatie over ontwerppatronen voor SaaS-toepassingen met elastische pools.

Gegevens verplaatsen van meerdere naar databases met één tenant

Wanneer u een SaaS-toepassing maakt, is het gebruikelijk om potentiële klanten een evaluatieversie van de software aan te bieden. In dit geval is het rendabel om een database met meerdere tenants voor de gegevens te gebruiken. Wanneer een prospect echter een klant wordt, is een database met één tenant beter omdat deze betere prestaties biedt. Als de klant gegevens had gemaakt tijdens de proefperiode, gebruikt u het hulpprogramma voor splitsen en samenvoegen om de gegevens van de multitenant naar de nieuwe database met één tenant te verplaatsen.

Notitie

Herstellen van databases met meerdere tenants naar één tenant is niet mogelijk.

Volgende stappen

Zie Aan de slag met hulpprogramma's voor Elastic Database voor een voorbeeld-app die de clientbibliotheek demonstreert.

Als u bestaande databases wilt converteren om de hulpprogramma's te gebruiken, raadpleegt u Bestaande databases migreren om uit te schalen.

Zie Prijs- en prestatieoverwegingen voor een elastische pool of maak een nieuwe pool met elastische pools voor meer informatie over de specifieke kenmerken van de elastische pool.

Aanvullende bronnen

Gebruikt u nog geen hulpprogramma's voor elastische databases? Bekijk de handleiding Aan de slag. Neem voor vragen contact met ons op op de microsoft Q&A-vragenpagina voor SQL Database en voor functieaanvragen, voeg nieuwe ideeën toe of stem op bestaande ideeën in het feedbackforum van SQL Database.