Azure Elastic Database Pool

Home / Blog / Nieuws / Azure Elastic Database Pool

Microsoft’s cloud oplossing, Azure, kent veel mogelijkheden voor het maken, hosten en onderhouden van applicaties. Op een veilige en kosten efficiënte manier, waarbij een groot deel van het beheer van de infrastructuur uit handen wordt genomen. Op het gebied van data opslag zijn er ook veel mogelijkheden, waaronder Azure SQL databases. Speciaal voor SaaS oplossingen biedt Microsoft Elastic Database pools aan. Met deze oplossing kun je eenvoudig en (kosten)efficiënt je databases onderbrengen in de cloud.

SQL Databases in Azure

Kort door de bocht kun je “Azure SQL Databases” zien als Microsoft SQL Server in de cloud. Voor een Euro of 13 per maand, heb je de beschikking over een SQL database in Azure zonder dat je je druk hoeft te maken over zaken als back-ups, failover, firewalls, updates en licenties.

Het aanmaken van een database is simpel: In de Azure Portal klik je in een paar eenvoudige stappen, je database in elkaar. Afhankelijk van de ‘load’ die je verwacht kies je een capaciteit van de database. Uiteraard, hoe meer je capaciteit je koopt, hoe meer je betaalt. Dat betekent dat je kunt kiezen voor een database van een paar euro tot tienduizenden euro’s per maand. Dit is ook achteraf nog aan te passen, mocht je toch meer of minder verbruiken dan je had verwacht.

Mocht je enkele databases nodig hebben, dan is dit een zeer eenvoudige en goedkope oplossing, zeker als je het vergelijkt met het aanschaffen van een SQL Server licentie. Daar betaal je al snel vele duizenden euro’s voor. Wanneer je zelf een SQL server host, kun je op die server wel zoveel databases installeren als je zelf wilt. Je betaalt in dat geval niet per database, maar gewoon voor je SQL Server licentie. Echter wanneer je bijvoorbeeld een SaaS oplossing maakt waarbij je voor al je klanten een individuele database gebruikt, kan het stiekem toch een duur grapje worden. Om dit scenario ook goed te kunnen ondersteunen biedt Microsoft Azure, Elastic Database Pools.

SaaS oplossingen

Wanneer je een software oplossing maakt voor 1 klant, dan is het werken met databases goed te overzien. Je beheert ergens een database server en plaatst daarop een database. Of waarschijnlijk meerdere databases, bijvoorbeeld om productie data te scheiden van test en acceptatie omgevingen. Wanneer je echter Software as a Service (SaaS) gaat aanbieden, dan wordt het iets ingewikkelder. Je zult in ieder geval moeten bepalen hoe je je data gaat indelen. Je wilt immers voorkomen dat de ene klant de data te zien krijgt van de andere klant. Of je kunt er voor zorgen dat je queries altijd goed geschreven zijn, maar ja software blijft mensen werk en bugjes zullen nu eenmaal altijd voor komen… Een andere overweging is het gemak om data te verwijderen wanneer een klant dit vraagt of wanneer er afscheid genomen wordt van een klant. Of denk eens aan het terugzetten van de data van 1 individuele klant… Daardoor komt het vaak voor dat er gekozen wordt voor losse database(s) per klant.

Elastic database pools

Het idee achter een elastic pool, is dat je een bepaalde hoeveelheid resources (combinatie van CPU, Disk en geheugen) inkoopt en dat alle databases in de pool deze resources delen. Je betaalt voor de resources en niet voor de databases. Op die manier kun je potentieel grote aantallen databases gebruiken voor een relatief laag bedrag. In onderstaand voorbeeld zie je de configuratie voor een Elastic pool, waarin je tot 500 individuele databases kunt onder brengen. Met een prijs van 378 Euro zou dat uitkomen op ongeveer 3 kwartjes per maand per database!!

Delen van resources

Het draait dus om het delen van resources. Niet elke SaaS klant zal op het zelfde moment de database (zwaar) belasten. Over het algemeen gaat het met pieken. Hieronder zie je een voorbeeld van het gebruik van de resources voor 1 database gedurende een uur.

Wil je de performance kunnen bieden die gevraagd wordt, moet je dus de resources inkopen die je piek nodig heeft. Echter is alles boven de blauwe lijn dus overbodig ingekochte resources. Zonde, toch?

Als je de resources gaat verdelen over bijvoorbeeld 5 database zie je dat de pieken over het algemeen op verschillende momenten plaats vindt en dat de resources effectiever gebruikt worden.

Aangezien er dan nog steeds veel ruimte overblijft, kun je nog meer databases toevoegen. In dit voorbeeld vullen we aan tot 20 databases. Het totaal aantal resources at je eigenlijk nodig had, wordt aangegeven door de zwarte lijn. De “ongebruikte” ruimte boven de lijn is significant kleiner geworden.

Database Transaction Units

Tot nu toe heb ik het gehad over “resources”. Bij de instellingen in Azure zie je DTU’s en eDTU’s terug. Dit zijn een soort eenheid voor de gecombineerde resources (CPU, geheugen, netwerk, disk, enz.).

Microsoft heeft bepaald wat een “gemiddelde” query kost aan resources. Dit gemiddelde is bepaald aan de hand van 10 veel voorkomende transacties. Dat zijn bijvoorbeeld eenvoudige select queries, ingewikkelde joins, group by’s, update en insert queries. Daarvan hebben ze gemeten wat de ‘kosten’ voor het gebruik van waren en het gemiddelde hiervan hebben ze 1 Database Transaction Unit genoemd.

Hierdoor kun je een beetje inschatten wat je kunt verwachten van je database of pool wanneer je deze gaat configureren.

In het eerste voorbeeld met de individuele database stond ingesteld dat de database maximaal 10 “gemiddelde” queries per seconde aan kan. Dat zijn 10 DTU’s dus.

Bij de elastic pool stond dat op 200 DTU’s per seconde. Je kunt dus enorme (piek) performance aanbieden aan je klanten, terwijl je een fractie van de kosten kwijt bent!

Mocht je bang zijn dat de ene klant alle resources gebruikt en dat andere klanten daar last van krijgen, dan kun je ook instellen wat het maximum aantal DTU’s per database is, of hoeveel DTU’s per database gegarandeerd beschikbaar moeten zijn.
Een laatste belangrijk punt is dat je databases op elk gewenst moment toe kunt voegen of kunt verwijderen uit een Elastic pool. Zo zou je bijvoorbeeld een freemium klant, die een premium klant wordt, kunnen verplaatsen voor een pool met minder DTU’s naar een pool waar meer DTU’s geconfigureerd zijn.

Schema updates

Een andere uitdaging die komt kijken, wanneer je verschillende databases per klant hebt, is het up-to-date houden van het database schema. Wanneer je bijvoorbeeld een nieuwe feature beschikbaar stelt, waarvoor een database aanpassing nodig is, dan moeten alle databases (tegelijk) aangepast worden. Dat kan een behoorlijke klus zijn.

Er zijn eigenlijk 2 fatsoenlijke oplossingen:
• Elastic queries: hiermee kun je gecentraliseerd queries uitvoeren over verschillende databases in de pool.
• (bijna) geen schema hebben: Doormiddel van de JSON functionaliteit van SQL databases is het mogelijk om een soort no-sql database oplossing te bouwen in SQL Server. Door JSON objecten op te slaan in SQL heb je (nauwelijks) een database schema nodig en dat hoeft dus ook niet te worden aangepast bij wijzigingen in de software. Echter ondersteunt SQL Server indexering van JSON data, zodat zoeken razend snel blijft.

Meer informatie over SaaS oplossingen, Azure of SQL Server?

Neem dan contact op met Christian. Hij wil je er graag alles over vertellen.