Delen via


Uitschalen met Azure SQL Database

van toepassing op:Azure SQL Database-

U kunt eenvoudig databases uitschalen in Azure SQL Database met behulp van de hulpprogramma's voor Elastic Database. 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:

In de volgende afbeelding ziet u een architectuur met de functies van de Elastic Database in relatie tot 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 poolgeplaatst.
  4. Een elastische databasetaak voert T-SQL-scripts uit op alle databases.
  5. Het hulpprogramma voor 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.

diagram van hulpprogramma's voor elastische databases.

Waarom de hulpprogramma's gebruiken?

Het bereiken van elasticiteit en schaal voor cloudtoepassingen is eenvoudig voor VM's en blobopslag. U hoeft alleen eenheden toe te voegen of af te trekken of de kracht te vergroten. Het blijft echter een uitdaging 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.

diagram waarin horizontaal versus verticaal uitschalen wordt uitgelegd.

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 gebruikmaken van horizontaal schalen 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 voor het distribueren van grote hoeveelheden identiek gestructureerde gegevens over veel 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 afzonderlijke databases zijn 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.

Multitenant 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 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 deze taak vereenvoudigen.

diagram van één tenant versus multitenant.

Andere scenario's voegen meerdere tenants samen in databases, in plaats van ze te isoleren in afzonderlijke databases. Dit patroon is een typisch multitenant-shardingpatroon. Dit kan worden veroorzaakt door het feit dat een toepassing grote aantallen kleine tenants beheert. Bij multitenant-sharding 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 voor meer informatie Multitenant-toepassingen met hulpprogramma's voor elastische databases en beveiliging op rijniveau. Het distribueren van gegevens tussen databases kan nodig zijn bij het multitenant shardingpatroon en wordt gefaciliteerd door de tool voor het splitsen en samenvoegen van elastische databases. Zie multitenant SaaS-databasetenancypatronenvoor 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 multitenant-database 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 tijdens de proefperiode gegevens maakt, gebruikt u de splits- en samenvoegtool om de gegevens van de multitenant naar de nieuwe single-tenant database te verplaatsen.

Notitie

Herstellen van multitenant-databases naar één tenant is niet mogelijk.

Voorbeelden en zelfstudies

Zie Aan de slag met elastic database-hulpprogramma'svoor een voorbeeld-app die de clientbibliotheek demonstreert.

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

Zie Prijs- en prestatieoverwegingen voor een elastische poolof maak een nieuwe pool met elastische poolsom de details van de elastische pool te bekijken.

Gebruikt u nog geen hulpprogramma's voor elastische databases? Bekijk onze Aan de slag-handleiding. 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 SQL Database-feedbackforum.