Av min erfarenhet är Amazon Aurora olämplig för att köra en databas med tung skrivtrafik. Åtminstone i dess implementering cirka 2017. Kanske kommer det att förbättras med tiden.
Jag arbetade på några riktmärken för en skrivtung applikation tidigare under 2017, och vi fann att RDS (icke-Aurora) var mycket överlägsen Aurora när det gäller skrivprestanda, med tanke på vår applikation och databas. I grund och botten var Aurora två storleksordningar långsammare än RDS. Amazons påståenden om hög prestanda för Aurora är tydligen helt marknadsföringsdrivet skitsnack.
I november 2016 deltog jag i Amazon re:Invent-konferensen i Las Vegas. Jag försökte hitta en kunnig Aurora-ingenjör för att svara på mina frågor om prestanda. Allt jag kunde hitta var junioringenjörer som hade blivit beordrade att upprepa påståendet att Aurora magiskt är 5-10 gånger snabbare än MySQL.
I april 2017 deltog jag i Percona Live-konferensen och såg en presentation om hur man utvecklar en Aurora-liknande distribuerad lagringsarkitektur med standard MySQL med CEPH för ett distribuerat lager med öppen källkod. Det finns ett webbseminarium om samma ämne här:https://www.percona. com/resources/webinars/mysql-and-ceph , medpresenterad av Yves Trudeau, ingenjören jag såg tala på konferensen.
Det som blev tydligt med att använda MySQL med CEPH är att ingenjörerna var tvungna att inaktivera MySQL-ändringsbuffert eftersom det inte finns något sätt att cachelagra ändringar till sekundära index, samtidigt som lagringen distribueras. Detta orsakade enorma prestandaproblem för skrivningar till tabeller som har sekundära (icke-unika) index.
Detta överensstämde med de prestandaproblem vi såg när vi jämförde vår applikation med Aurora. Vår databas hade många sekundära index.
Så om du absolut måste använda Aurora för en databas som har hög skrivtrafik rekommenderar jag att det första du måste göra är att släppa alla dina sekundära index.
Uppenbarligen är detta ett problem om indexen behövs för att optimera några av dina frågor. Både SELECT-frågor förstås, men även vissa UPDATE- och DELETE-frågor kan använda sekundära index.
En strategi kan vara att göra en icke-Aurora-läsreplika av ditt Aurora-kluster och skapa de sekundära indexen endast i den lästa repliken för att stödja dina SELECT-frågor. Jag har aldrig gjort det här, men tydligen är det möjligt, enligt https://aws.amazon.com/premiumsupport/knowledge-center/enable-binary-logging-aurora/
Men detta hjälper fortfarande inte fall där dina UPDATE/DELETE-satser behöver sekundära index. Jag har inget förslag på det scenariot. Du kanske har tur.
Min slutsats är att jag inte skulle välja att använda Aurora för en skrivtung applikation. Kanske kommer det att ändras i framtiden.
Uppdatering april 2021:
Sedan jag skrev ovanstående har jag kört sysbench benchmarks mot Aurora version 2. Jag kan inte dela de specifika siffrorna, men jag drar slutsatsen att nuvarande Aurora-förbättringar är bättre för skrivtung arbetsbelastning. Jag körde tester med massor av sekundära index för att vara säker. Men jag uppmuntrar alla som är seriösa med att anta Aurora att köra sina egna benchmarks.
Åtminstone är Aurora mycket bättre än konventionell Amazon RDS för MySQL med EBS-lagring. Det är förmodligen där de hävdar att Aurora är 5 gånger snabbare än MySQL. Men Aurora är inte snabbare än några andra alternativ jag testat, och kan faktiskt inte matcha:
-
MySQL Server installerade mig själv på EC2-instanser med lokal lagring, speciellt i3-instanser med lokalt ansluten NVMe. Jag förstår att instanslagring inte är pålitlig, så man skulle behöva köra redundanta noder.
-
MySQL Server installerade mig själv på fysiska värdar i vårt datacenter, med hjälp av direktansluten SSD-lagring.
Värdet av att använda Aurora som en hanterad molndatabas handlar inte bara om prestanda. Den har också automatiserad övervakning, säkerhetskopior, failover, uppgraderingar, etc.