Technologie
Optimale SQL databases in Azure: horizontaal schalen
In een eerder blog legde Maarten Botter uit hoe je ervoor kunt zorgen dat je de meeste performance uit een Azure SQL database kunt halen, door gebruik te maken van Azure’s ondersteunende tooling om trage queries te ontdekken en te optimaliseren op verschillende manieren. Optimalisatie op deze manier kent echter zijn limieten. In bepaalde scenario’s kan dan gekeken worden naar horizontaal schalen.
Wat is horizontaal schalen?
Wanneer je een SQL database horizontaal schaalt, zet je feitelijk één of meerdere extra database instances naast je bestaande database. Deze instances kunnen de belasting verdelen.
Verschillende modellen
Je kunt horizontal scaling op verschillende manieren toepassen. Zo kun je alle data repliceren over verschillende instances, en verschillende processen tegen verschillende instances laten praten om de load te verdelen. Of bijvoorbeeld zware processen tegen de zwaarste instance te laten draaien, zodat je lichtere processen niet bekneld raken. Nadeel van deze aanpak is dat inserts en updates niet automatisch op alle instances terecht komen. Dat vereist handwerk en verkleint de voordelen, aangezien de “lichtere” instances hiermee alsnog zwaar belast kunnen worden.
Geo-replicatie is ook een vorm van horizontal scaling. Hierbij breng je een versie van je database onder verschillende zones in de wereld onder. Dit brengt voordelen met zich mee bij een rampscenario waar één van de datacenters van Azure niet meer werkt. Ook kan hiermee georganiseerd worden dat verzoeken vanuit servers in een bepaalde regio, bij de database in die regio terecht komen. Het zorgt dus feitelijk voor loadbalancing op basis van waar het verkeer op het applicatielandschap vandaan komt.
Sharding
Een andere aanpak voor horizontal scaling is door sharding toe te passen. Bij sharding verdeel je de data over verschillende databases. Dit doe je door een bepaalde sharding-sleutel te definiëren. Dit kan bijvoorbeeld een modulo van de ID kolommen zijn (elke eerste ID staat in database 1, tweede ID in database 2…), maar ook iets complexers.
Het is hierbij wel van belang dat je rekening houdt met foreign key constraints. Gerelateerde data moet wel in dezelfde database blijven staan om relaties in stand te houden. Sommige data zal dus potentieel in alle databases terecht moeten komen.
Een voorbeeld van een use-case van deze implementatie is wanneer je een grote tabel hebt, waarbij 99% van de updates plaatsvinden op data van het afgelopen jaar. Door te sharden op datum en de meest recente data in de sterkste database te plaatsen, zorg je dat oudere data altijd goed bereikbaar blijft.
Het lastige van sharding is dat de applicatiecode er ook op dient aangepast te worden. Een ORM als Entity Framework kan niet zomaar zelf bepalen welke data waar staat. Hiervoor dient dus een slimme abstractielaag tussen de aanroepende code en de database call te worden geplaatst, welke deze bepaling kan uitvoeren.
Wat zijn de voor- en nadelen van vertical scaling over horizontal scaling?
Vertical scaling (het verhogen van de performance van een database server) is de meest eenvoudige manier om performance te winnen. Er hoeft geen rekening gehouden te worden met zaken zoals sharding en je applicatiecode hoeft geen refactor door te maken. Wanneer er zware processen draaien, wordt direct het gehele systeem nauwelijks bedienbaar. Ook blijft alle data op één server bestaan, waardoor er bij een failure in het datacentrum of het netwerk geen database meer beschikbaar is voor je applicatie. Ook zit er een limiet aan hoever je verticaal kunt schalen: een standaard Azure SQL server kan bijvoorbeeld tot maximaal 128 cores worden opgeschaald.
Horizontal scaling biedt de uitkomst voor deze tekortkomingen, maar brengt dus weer meer werk met zich mee. Je moet zelf de verdeling en replicatie van de data inregelen in je database, en logica ontwikkelen waarmee je applicatie(s) hier op de juiste manier bij kunnen komen. Het kan in theorie ook duurder uitvallen dan vertical scaling, omdat je meerdere servers te onderhouden hebt.
Hyperscale
Microsoft heeft een soort database ontwikkeld, die de voordelen van horizontal scaling met zich meebrengt, met geïntegreerde oplossingen voor de meeste nadelen. Deze oplossing heet Azure SQL Hyperscale.
Bij een Hyperscale database worden sharding en load balancing automatisch voor je geregeld. Communicatie met een Hyperscale database werkt zoals je gewend bent met een “normale” SQL database. Entity Framework kan bijvoorbeeld op exact dezelfde manier gebruikt worden. De Hyperscale architectuur van Azure vertaalt je queries vervolgens over de verschillende instances heen, verzamelt de data en geeft deze terug. Ook consistency-uitdagingen wordt uit handen genomen, door bijvoorbeeld automatisch om te kunnen gaan met transacties die meerdere databases overspannen.
Meer weten? Neem contact op!
Michiel Leenaers
Business Development
0614688177
m.leenaers@garansys.nl