MySQL HeatWave moet een native gebruikerservaring opleveren voor AWS-klanten en belooft veel betere prestaties dan het aanbod van AWS zelf, tegen beduidend lagere kosten.

Naast regelmatige updates aan de eigen OCI-omgeving, heeft Oracle zichzelf ook duidelijk als doel gesteld om ook op andere public clouds Oracle-diensten aan te bieden. Recent zagen we daar een voorbeeld van met de uitbreiding van Interconnect for Azure met de Database Service for Azure. Hiermee is het mogelijk om Oracle-databases te draaien zonder de Azure-omgeving te verlaten. De aankondiging van vandaag kun je zien als een soortgelijke stap. Alleen gaat het nu niet om Microsoft Azure, maar om AWS. Dat is toch net wat saillanter natuurlijk, omdat Oracle en AWS niet de beste vrienden zijn. Dat wil zeggen, er worden over en weer regelmatig wat opmerkingen gemaakt door de een over de ander.

In een ideale wereld zou Oracle aankondigingen zoals die van vandaag en eerder ook die rondom Interconnect for Azure niet hoeven doen. In het geval van HeatWave heeft Oracle het ongetwijfeld veel liever dat klanten deze query accelerator afneemt binnen OCI. Maar dat is nu eenmaal niet de realiteit. De kosten die AWS rekent om data uit hun omgeving ergens anders heen te brengen zijn behoorlijk hoog. Daarnaast zijn er ook simpelweg veel klanten die de nodige andere diensten gebruiken uit het AWS-ecosysteem. Die willen dus helemaal niet migreren. Vandaar dat Oracle de stap heeft gezet om MySQL HeatWave nu dus native beschikbaar te maken op AWS.

Even opfrissen: wat is MySQL HeatWave ook alweer?

Eerder dit jaar hebben we een artikel geschreven over de toevoeging van Machine Learning aan MySQL HeatWave. Daarin hebben we ook uitgelegd wat HeatWave nu eigenlijk is. Je kunt dat artikel natuurlijk nog even een keertje doornemen door hier te klikken. We reproduceren een deel van onze uitleg uit dat artikel hieronder voor het gemak ook nog een keer.

HeatWave is een zogeheten query accelerator. Zoals die term al aangeeft, is het doel van HeatWave om MySQL-queries sneller te laten verlopen. Het is ook onderdeel van de MySQL-database, die van origine is ontworpen voor transactionele doeleinden, niet per se voor de hoogste prestaties op het gebied van de queries zelf. Vandaar dat gebruikers voor zaken als de beste prestaties en schaalbaarheid vaak meerdere databases naast elkaar gebruiken. En dus ook veel data tussen databases moeten migreren. Als MySQL HeatWave doet wat het belooft, is dat nu niet meer nodig.

Een query accelerator toevoegen aan een transactionele MySQL-database klinkt wellicht niet zo ingewikkeld. Oracle heeft echter meer dan tien jaar aan MySQL HeatWave gewerkt. Het is dus in ieder geval een stevige klus geweest. Het doel was dan ook om MySQL HeatWave massively parallel en massively partitioned te maken. Dat zijn de twee voorwaarden om zowel uitstekende prestaties als schaalbaarheid te kunnen bieden. Data wordt eerst in partities verdeeld, die vervolgens parallel aan elkaar worden verwerkt. Aan het einde voegt HeatWave de partities weer samen. Hieronder zie je hoe dat schematisch in elkaar zit.

Stevige beloftes van Oracle over MySQL HeatWave on AWS

Oracle heeft met het beschikbaar maken van MySQL HeatWave on AWS een optie gecreëerd om transactionele workloads, analytics en machine learning binnen AWS in een enkele database te doen. Daarvoor hoeft een klant overigens niet zelf een instance op AWS te provisionen en af te rekenen. Dat neemt Oracle allemaal voor zijn rekening, horen we van een woordvoerder tijdens een briefing eerder vandaag. Dat wil zeggen, je kunt de AWS-instance in gebruik nemen via cloud.mysql.com. Oracle regelt het verder allemaal achter de schermen. Hieronder zie je schematisch hoe dit werkt.

Naast het relatief eenvoudig opzetten van MySQL HeatWave on AWS, doet Oracle ook nog de nodige beloftes en uitspraken over de prestaties en de kosten. Op basis van een standaard TPC-H-benchmark die Oracle heeft gedraaid is MySQL HeatWave on AWS niet minder dan twintig keer sneller dan de Redshift-database van AWS zelf. Daarbovenop claimt Oracle dat het ook nog eens zeven keer goedkoper is. Hieronder zie je twee grafieken met de verhoudingen tussen de grote spelers in de markt.

MySQL Autopilot

Een belangrijk onderdeel van MySQL, met name voor de prijs-prestatieverhouding ten opzichte van de concurrentie, is Autopilot. Daar staat de woordvoerder tijdens de briefing dan ook uitgebreid bij stil. MySQL Autopilot is in de basis aan automation feature. Met behulp van machine learning moet Autopilot ervoor zorgen dat iedere workload optimaal presteert. Het doet dit voor de volledige lifecycle van de applicatie: provisioning, datamanagement, query execution en failure handling. Het voert te ver hier om deze functionaliteit volledig te bespreken. We houden het bij de twee nieuwe features die er vandaag bijkomen; auto thread pooling en auto shape prediction.

Auto thread pooling moet ervoor zorgen dat de throughput zo hoog mogelijk is en ook niet inzakt bij hogere concurrency. Autopilot bepaalt het optimale aantal transacties om deze prestaties te kunnen blijven leveren.

Auto shape prediction doet wat de naam aangeeft. Autopilot bepaalt de optimale grootte (shape) die moet worden ingezet om tot de beste prijs-prestatieverhouding te komen. Is er sprake van overprovisioning, dan zal Autopilot het advies geven om de downgraden, bij underprovisioning is het advies om juist te upgraden.

Al met al heeft Oracle vandaag weer een nieuwe stap gezet in het beschikbaar maken van haar clouddiensten aan een steeds groter wordend publiek. Of dat publiek deze diensten ook gaat afnemen, is uiteraard de vraag. Als de prijs-prestatieverhoudingen die Oracle ons heeft voorgerekend representatief zijn en dus ook voor andere benchmarks en workloads gelden, dan ligt het in ieder geval niet aan het kostenplaatje als klanten alsnog besluiten om hun workloads ergens anders te draaien.

Lees meer