Implementatieopties uitleggen
Azure SQL Database, een PaaS (Platform as a Service), biedt hoge schaalbaarheid en minimaal onderhoud, waardoor het een uitstekende oplossing is voor specifieke workloads. Het is geschikt voor het ontwikkelen van nieuwe toepassingen, waardoor ontwikkelaars aanzienlijke flexibiliteit hebben bij het bouwen van nieuwe services en het bieden van gedetailleerde implementatieopties op schaal. Deze oplossing met weinig onderhoud is ideaal voor verschillende workloads, waardoor de toepassing efficiënt en effectief kan worden ontwikkeld.
Implementatiemodellen begrijpen
Bij het implementeren van Azure SQL Database zijn er twee primaire implementatiemodellen: individuele database en elastische pools. In het model elastische pools worden resources gedeeld tussen meerdere databases binnen dezelfde pool, terwijl in het individuele databasemodel resources onafhankelijk worden beheerd voor elke database.
Net als bij virtuele machines kan SQL Database worden geïmplementeerd met behulp van verschillende methoden, waaronder PowerShell, Azure CLI of Azure Portal.
Individuele database
Het implementatiemodel voor één database is de eenvoudigste manier om Azure SQL Database te gebruiken. In dit model beheert u elke database afzonderlijk in termen van schaal en gegevensgrootte. Elke database heeft eigen toegewezen resources, zelfs als er meerdere databases op dezelfde logische server worden geïmplementeerd.
U kunt het resourcegebruik van elke database bewaken via Azure Portal. Met deze functie kunt u eenvoudig de prestaties van uw databases bijhouden en beoordelen.
Pools voor Elastic Database
Met elastische pools kunt u opslag- en rekenresources toewijzen aan een groep databases, waardoor het beheer wordt vereenvoudigd in vergelijking met het afzonderlijk verwerken van elke database. Ze zijn eenvoudiger te schalen dan individuele databases, omdat wijzigingen in de elastische pool automatisch resources aanpassen voor alle opgenomen databases.
Dit model is rendabel voor software als een servicetoepassing, omdat resources worden gedeeld tussen alle databases. U kunt resources configureren met behulp van het aankoopmodel op basis van DTU of vCore.
Het is belangrijk om continu resources te bewaken om prestatiepieken te identificeren die van invloed kunnen zijn op andere databases in de pool. Het regelmatig opnieuw bekijken van uw toewijzingsstrategie zorgt voor voldoende resources voor alle databases.
Elastische pools zijn ideaal voor multitenantarchitecturen met een laag gemiddeld gebruik, waarbij elke tenant een eigen databasekopie heeft.
Aankoopmodellen begrijpen
Zodra u het juiste implementatiemodel voor uw SQL Database hebt gekozen, is de volgende stap het aankoopmodel te selecteren dat het beste past bij uw workload- en budgetvereisten. Azure SQL Database biedt twee aankoopmodellen: het vCore-model en het DTU-model. Elk model heeft zijn eigen voordelen, dus het is van cruciaal belang om te begrijpen welke het beste aansluit bij uw workloadvereisten en kostenoverwegingen.
Op vCore gebaseerd
Dit is het aanbevolen aankoopmodel, waarbij reken- en opslagresources worden losgekoppeld. Dit betekent dat u opslag- en rekenresources onafhankelijk van elkaar kunt schalen. Deze flexibiliteit zorgt ervoor dat u resources kunt aanpassen aan uw specifieke behoeften zonder dat dit van invloed is op andere onderdelen.
In het aankoopmodel op basis van vCore zijn uw kosten afhankelijk van verschillende factoren, waaronder de servicelaag, hardwareconfiguratie, het aantal vCores en de hoeveelheid geheugen, gereserveerde databaseopslag en werkelijke back-upopslag.
Notitie
Zie de pagina met prijzen voor Azure SQL Database voor meer informatie.
Een servicelaag is een vooraf gedefinieerde configuratie die de prestaties, het opslagtype, hoge beschikbaarheid, opties voor herstel na noodgevallen en de beschikbaarheid van bepaalde functies voor uw database bepaalt.
Het vCore-aankoopmodel biedt drie opties voor de servicelaag:
| Servicelaag | Mogelijkheid |
|---|---|
| Algemeen gebruik | Deze servicelaag is ontworpen voor minder intensieve bewerkingen en biedt een rendabele balans tussen reken- en opslagopties. Het omvat zowel ingerichte als serverloze rekenlagen, die flexibiliteit bieden om te voldoen aan verschillende workloadvereisten terwijl het budget wordt geoptimaliseerd. |
| Bedrijfskritiek | Deze laag is ideaal voor toepassingen die lage latentie en opslag met hoge prestaties vereisen. Het ondersteunt In-Memory OLTP en bevat een ingebouwde alleen-lezen replica. Daarnaast biedt het meer geheugen per kern en maakt het gebruik van lokale SSD-opslag, waardoor het ideaal is voor prestatiegevoelige workloads. |
| Hyperscale | Deze laag is afgestemd op toepassingen met grote databases en hoge doorvoervereisten. Hyperscale introduceert geavanceerde functies voor horizontaal schalen, waardoor rekenknooppunten kunnen worden toegevoegd wanneer de gegevensgrootte toeneemt. Het wordt uitsluitend ondersteund voor individuele SQL-databases en maakt aanzienlijke schaalaanpassing van opslag- en rekenresources mogelijk buiten de limieten van de servicelagen Algemeen gebruik en Bedrijfskritiek. |
Op basis van DTU
In het DTU-model zijn er drie servicelagen: Basic, Standard en Premium. Reken- en opslagresources zijn afhankelijk van het DTU-niveau en bieden een scala aan prestatiemogelijkheden met vaste opslaglimieten, back-upretentie en kosten.
Als uw database bijvoorbeeld de maximale opslaglimiet bereikt, moet u de DTU-capaciteit verhogen, zelfs als het rekengebruik laag is. Bovendien kunnen schaalbewerkingen in Azure SQL Database korte verbindingsonderbrekingen veroorzaken aan het einde van het proces. Dit kan gebeuren volgens twee hoofdscenario's:
- Het initiëren van een schaalbewerking waarvoor een interne failover is vereist.
- Databases toevoegen aan of verwijderen uit de elastische pool.
Notitie
Als u verbindingsfouten wilt afhandelen, implementeert u de juiste logica voor opnieuw proberen in uw toepassing.
Inzicht in de interactie tussen implementatie- en aankoopmodellen is van cruciaal belang voor het optimaliseren van prestaties en kostenefficiëntie. Door zorgvuldig de juiste combinatie te selecteren, kunt u ervoor zorgen dat uw Azure SQL Database-implementatie voldoet aan de vereisten van uw toepassing terwijl u binnen het budget blijft.
Als u bijvoorbeeld kiest voor het implementatiemodel voor één database, geeft u mogelijk de voorkeur aan het vCore-aankoopmodel voor de flexibiliteit van het onafhankelijk schalen van reken- en opslagresources. Als u echter het implementatiemodel voor elastische pools kiest, kan het aankoopmodel op basis van DTU rendabeler zijn, omdat u hiermee resources kunt delen tussen meerdere databases in de pool.
Back-up en herstel uitvoeren
Azure biedt naadloze back-up- en herstelmogelijkheden voor SQL Database. Hier volgen enkele belangrijke functies:
Continue back-up
Azure SQL Database zorgt voor regelmatige back-ups, waarbij ze continu worden gekopieerd naar geografisch redundante opslag met leestoegang (RA-GRS). Volledige back-ups vinden wekelijks plaats, differentiële back-ups elke 12 tot 24 uur en back-ups van transactielogboeken om de 5 tot 10 minuten.
Geo-herstel
Met geografisch redundante back-ups kunt u databases standaard eenvoudig herstellen naar verschillende regio's, handig voor minder strikte scenario's voor herstel na noodgevallen. Back-upopslag wordt afzonderlijk gefactureerd, maar wordt zonder extra kosten gemaakt met de maximale grootte van de geselecteerde gegevenslaag. De duur van geo-herstel is afhankelijk van de grootte van de database, transactielogboeken en gelijktijdige herstelaanvragen.
Notitie
Geo-herstel is beschikbaar wanneer de eigenschap voor redundantie van back-up opslag is ingesteld op geo-redundante back-up opslag.
Herstel naar een bepaald tijdstip (PITR)
Hiermee kunt u een specifiek bewaarbeleid voor een bepaald tijdstip voor elke database configureren, variërend van 1 tot 35 dagen (standaard is zeven dagen). U kunt databases ook herstellen naar een specifiek tijdstip binnen dezelfde server met behulp van Azure Portal, PowerShell, CLI of REST API.
Langetermijnretentie (LTR)
Langetermijnretentie is handig voor scenario's waarvoor u het bewaarbeleid moet instellen buiten wat wordt aangeboden door Azure. U kunt een bewaarbeleid instellen voor maximaal 10 jaar en deze optie is standaard uitgeschakeld.
Automatisch instellen inschakelen
Automatisch afstemmen is een krachtige ingebouwde functie die machine learning toepast om uw queryprestaties te optimaliseren. Er worden automatisch afstemmingskansen geïdentificeerd en geïmplementeerd om de efficiëntie van uw database te verbeteren.
Op dit moment bevat automatisch afstemmen de volgende functies:
- Dure query's identificeren
- Het laatste goede uitvoeringsplan afdwingen
- Indexen toevoegen
- Indexen verwijderen
Azure-services gebruiken geavanceerde algoritmen om de beste indexen voor uw querypatronen te bepalen. Deze indexen worden in eerste instantie getest op een kopie van uw database voordat ze worden toegepast op de liveomgeving, waardoor er minimale onderbrekingen worden gegarandeerd.
Alle databases nemen hun configuratie over van de bovenliggende server en u kunt deze functie eenvoudig uitschakelen indien nodig. Dankzij deze flexibiliteit kunnen ontwikkelaars de controle behouden en profiteren van geautomatiseerde prestatieverbeteringen.
Elastische query gebruiken
Met elastische query kunt u T-SQL-query's uitvoeren op meerdere databases in SQL Database. Deze functie is handig voor toepassingen die gebruikmaken van drie- en vierdelige namen die niet kunnen worden gewijzigd en die de draagbaarheid verbeteren door migratie te vergemakkelijken.
Elastische query's ondersteunen de volgende partitioneringsscenario's:
| Servicelaag | Mogelijkheid |
|---|---|
| Verticale partitionering | Ook wel bekend als query's voor meerdere databases. Gegevens worden verticaal gepartitioneerd over meerdere databases met verschillende schema's. U hebt bijvoorbeeld één database voor klantgegevens en een andere database voor betalingsgegevens. Met verticale partitionering kunt u query's voor meerdere databases uitvoeren tussen deze databases. |
| Horizontale partitie | Ook wel sharding genoemd. Gegevens worden horizontaal gepartitioneerd om rijen te verdelen over verschillende uitgeschaalde databases, allemaal met hetzelfde schema. Deze topologie ondersteunt zowel modellen met één tenant als meerdere tenants. |
Deze flexibiliteit maakt elastische query's een krachtig hulpprogramma voor het beheren en opvragen van gegevens in meerdere databases.
Elastische taken configureren
De functie elastische taak fungeert als de vervanging van SQL Server Agent voor Azure SQL Database, vergelijkbaar met de functie Multi Server Administration in een on-premises SQL Server-exemplaar.
Met elastische taken kunt u T-SQL-opdrachten uitvoeren in verschillende doelimplementaties, waaronder SQL Databases, elastische POOLS van SQL Database en SQL Databases in shard-toewijzingen. Deze databasebronnen kunnen verschillende Azure-abonnementen en -regio's omvatten. De parallelle uitvoeringsmogelijkheid is handig voor het automatiseren van databaseonderhoudstaken, waardoor efficiëntie en consistentie in uw implementaties worden gegarandeerd.
Gegevens verplaatsen met SQL Data Sync
SQL Data Sync maakt incrementele synchronisatie van gegevens in meerdere databases mogelijk, ongeacht of ze worden uitgevoerd op SQL Database of on-premises SQL Server. Deze functie is handig voor het offloaden van intensieve productieworkloads naar een afzonderlijke database voor analyse- of ongeplande bewerkingen.
Data Sync werkt op een hubtopologie, waarbij één database in de synchronisatiegroep wordt aangewezen als de hub. De synchronisatiegroep kan meerdere liddatabases bevatten en synchronisatie vindt plaats tussen de hub en afzonderlijke liddatabases. Wijzigingen worden bijgehouden met triggers voor invoegen, bijwerken en verwijderen via een historische tabel die is gemaakt in de gebruikersdatabase.
Wanneer u een synchronisatiegroep maakt, moet u een database opgeven om de metagegevens van de synchronisatiegroep op te slaan. Deze metagegevensdatabase kan nieuw of bestaand zijn, zolang deze zich in dezelfde regio bevindt als uw synchronisatiegroep.
Zie zelfstudie: SQL Data Sync instellen tussen databases in Azure SQL Database en SQL Server voor meer informatie over het configureren van SQL Data Sync.