Fra min erfaring er Amazon Aurora uegnet til at køre en database med tung skrivetrafik. I hvert fald i dens implementering omkring 2017. Måske vil den forbedres med tiden.
Jeg arbejdede på nogle benchmarks for en skrivetung applikation tidligere i 2017, og vi fandt ud af, at RDS (ikke-Aurora) var langt overlegen i forhold til Aurora med hensyn til skriveydeevne, givet vores applikation og database. Grundlæggende var Aurora to størrelsesordener langsommere end RDS. Amazons påstande om høj ydeevne for Aurora er tilsyneladende fuldstændig markedsføringsdrevet bullshit.
I november 2016 deltog jeg i Amazon re:Invent-konferencen i Las Vegas. Jeg forsøgte at finde en kyndig Aurora-ingeniør til at besvare mine spørgsmål om ydeevne. Det eneste, jeg kunne finde, var junioringeniører, der var blevet beordret til at gentage påstanden om, at Aurora på magisk vis er 5-10 gange hurtigere end MySQL.
I april 2017 deltog jeg i Percona Live-konferencen og så en præsentation om, hvordan man udvikler en Aurora-lignende distribueret lagringsarkitektur ved hjælp af standard MySQL med CEPH til et distribueret lagringslag med åben kildekode. Der er et webinar om samme emne her:https://www.percona. com/resources/webinars/mysql-and-ceph , medpræsenteret af Yves Trudeau, ingeniøren jeg så tale på konferencen.
Det, der blev klart ved at bruge MySQL med CEPH, er, at ingeniørerne var nødt til at deaktivere MySQL-ændringsbuffer fordi der ikke er nogen måde at cache ændringer til sekundære indekser, samtidig med at lageret er distribueret. Dette forårsagede enorme ydeevneproblemer for skrivninger til tabeller, der har sekundære (ikke-unikke) indekser.
Dette var i overensstemmelse med de ydeevneproblemer, vi så ved benchmarking af vores applikation med Aurora. Vores database havde en masse sekundære indekser.
Så hvis du absolut skal bruge Aurora til en database, der har høj skrivetrafik, anbefaler jeg, at den første ting du skal gøre er at slette alle dine sekundære indekser.
Dette er naturligvis et problem, hvis indekserne er nødvendige for at optimere nogle af dine forespørgsler. Både SELECT-forespørgsler, selvfølgelig, men også nogle UPDATE- og DELETE-forespørgsler kan bruge sekundære indekser.
En strategi kan være at lave en ikke-Aurora-læse-replika af din Aurora-klynge og kun oprette de sekundære indekser i læsereplikaen for at understøtte dine SELECT-forespørgsler. Jeg har aldrig gjort dette, men det er åbenbart muligt, ifølge https://aws.amazon.com/premiumsupport/knowledge-center/enable-binary-logging-aurora/
Men dette hjælper stadig ikke tilfælde, hvor dine UPDATE/DELETE-sætninger har brug for sekundære indekser. Jeg har ikke noget forslag til det scenarie. Du kan være uheldig.
Min konklusion er, at jeg ikke ville vælge at bruge Aurora til en skrivetung applikation. Måske vil det ændre sig i fremtiden.
Opdatering april 2021:
Siden jeg skrev ovenstående, har jeg kørt sysbench-benchmarks mod Aurora version 2. Jeg kan ikke dele de specifikke tal, men jeg konkluderer, at nuværende Aurora-forbedringer er bedre til skrivetung arbejdsbyrde. Jeg kørte test med masser af sekundære indekser for at være sikker. Men jeg opfordrer alle, der seriøst tager imod Aurora, til at køre deres egne benchmarks.
I det mindste er Aurora meget bedre end konventionel Amazon RDS til MySQL, der bruger EBS-lagring. Det er nok der, de hævder, at Aurora er 5x hurtigere end MySQL. Men Aurora er ikke hurtigere end nogle andre alternativer, jeg testede, og kan faktisk ikke matche:
-
MySQL Server installerede mig selv på EC2-instanser ved hjælp af lokal lagring, især i3-instanser med lokalt tilknyttet NVMe. Jeg forstår, at instanslagring ikke er pålidelig, så man bliver nødt til at køre redundante noder.
-
MySQL Server installerede mig selv på fysiske værter i vores datacenter ved hjælp af direkte tilsluttet SSD-lager.
Værdien af at bruge Aurora som en administreret cloud-database handler ikke kun om ydeevne. Den har også automatiseret overvågning, sikkerhedskopier, failover, opgraderinger osv.