Vanuit mijn ervaring is Amazon Aurora niet geschikt voor het uitvoeren van een database met veel schrijfverkeer. In ieder geval bij de implementatie rond 2017. Misschien zal het in de loop van de tijd verbeteren.
Ik heb eerder in 2017 aan een aantal benchmarks voor een schrijfzware applicatie gewerkt en we ontdekten dat RDS (niet-Aurora) qua schrijfprestaties veel beter was dan Aurora, gezien onze applicatie en database. Kortom, Aurora was twee orden van grootte langzamer dan RDS. Amazon's beweringen over hoge prestaties voor Aurora zijn blijkbaar volledig door marketing gedreven bullshit.
In november 2016 woonde ik de Amazon re:Invent-conferentie bij in Las Vegas. Ik heb geprobeerd een deskundige Aurora-ingenieur te vinden om mijn vragen over prestaties te beantwoorden. Ik kon alleen maar junior-ingenieurs vinden die de opdracht hadden gekregen om de bewering te herhalen dat Aurora op magische wijze 5-10x sneller is dan MySQL.
In april 2017 woonde ik de Percona Live-conferentie bij en zag een presentatie over het ontwikkelen van een Aurora-achtige gedistribueerde opslagarchitectuur met behulp van standaard MySQL met CEPH voor een open-source gedistribueerde opslaglaag. Er is hier een webinar over hetzelfde onderwerp:https://www.percona. com/resources/webinars/mysql-and-ceph , mede gepresenteerd door Yves Trudeau, de ingenieur die ik op de conferentie zag spreken.
Wat duidelijk werd over het gebruik van MySQL met CEPH, is dat de technici de MySQL-wijzigingsbuffer omdat er geen manier is om wijzigingen in secundaire indexen in de cache op te slaan, terwijl de opslag ook wordt gedistribueerd. Dit veroorzaakte enorme prestatieproblemen bij het schrijven naar tabellen met secundaire (niet-unieke) indexen.
Dit kwam overeen met de prestatieproblemen die we zagen bij het benchmarken van onze applicatie met Aurora. Onze database had veel secundaire indexen.
Dus als je Aurora absoluut moet gebruiken voor een database met veel schrijfverkeer, raad ik je aan om als eerste al je secundaire indexen te laten vallen
Dit is duidelijk een probleem als de indexen nodig zijn om sommige van uw zoekopdrachten te optimaliseren. Beide SELECT-query's natuurlijk, maar ook sommige UPDATE- en DELETE-query's kunnen secundaire indexen gebruiken.
Een strategie kan zijn om een niet-Aurora leesreplica van uw Aurora-cluster te maken en de secundaire indexen alleen in de leesreplica te maken om uw SELECT-query's te ondersteunen. Ik heb dit nog nooit gedaan, maar blijkbaar is het mogelijk, volgens https://aws.amazon.com/premiumsupport/knowledge-center/enable-binary-logging-aurora/
Maar dit helpt nog steeds niet in gevallen waarin uw UPDATE/DELETE-instructies secundaire indexen nodig hebben. Ik heb geen suggestie voor dat scenario. Misschien heb je pech.
Mijn conclusie is dat ik Aurora niet zou gebruiken voor een schrijfzware applicatie. Misschien verandert dat in de toekomst.
Update april 2021:
Sinds ik het bovenstaande heb geschreven, heb ik sysbench-benchmarks uitgevoerd tegen Aurora versie 2. Ik kan de specifieke cijfers niet delen, maar ik concludeer dat de huidige Aurora-verbeteringen beter zijn voor schrijfzware werklast. Ik heb tests uitgevoerd met veel secundaire indexen om zeker te zijn. Maar ik moedig iedereen die serieus bezig is met het adopteren van Aurora aan om hun eigen benchmarks uit te voeren.
Aurora is in ieder geval veel beter dan conventionele Amazon RDS voor MySQL met behulp van EBS-opslag. Dat is waarschijnlijk waar ze beweren dat Aurora 5x sneller is dan MySQL. Maar Aurora is niet sneller dan sommige andere alternatieven die ik heb getest, en kan in feite niet evenaren:
-
MySQL Server installeerde mezelf op EC2-instanties met lokale opslag, vooral i3-instanties met lokaal aangesloten NVMe. Ik begrijp dat instantieopslag niet betrouwbaar is, dus je zou redundante nodes moeten gebruiken.
-
MySQL Server installeerde mezelf op fysieke hosts in ons datacenter, met behulp van direct aangesloten SSD-opslag.
De waarde van het gebruik van Aurora als een beheerde clouddatabase gaat niet alleen over prestaties. Het heeft ook geautomatiseerde monitoring, back-ups, failover, upgrades, enz.