In base alla mia esperienza, Amazon Aurora non è adatto per eseguire un database con traffico di scrittura intenso. Almeno nella sua implementazione intorno al 2017. Forse migliorerà nel tempo.
Ho lavorato su alcuni benchmark per un'applicazione pesante in scrittura all'inizio del 2017 e abbiamo scoperto che RDS (non Aurora) era di gran lunga superiore ad Aurora in termini di prestazioni di scrittura, data la nostra applicazione e il nostro database. Fondamentalmente, Aurora era due ordini di grandezza più lenta di RDS. Le affermazioni di Amazon di prestazioni elevate per Aurora sono apparentemente stronzate completamente basate sul marketing.
Nel novembre 2016 ho partecipato alla conferenza Amazon re:Invent a Las Vegas. Ho cercato di trovare un ingegnere Aurora esperto per rispondere alle mie domande sulle prestazioni. Sono riuscito a trovare solo ingegneri junior a cui era stato ordinato di ripetere l'affermazione secondo cui Aurora è magicamente 5-10 volte più veloce di MySQL.
Nell'aprile 2017, ho partecipato alla conferenza Percona Live e ho assistito a una presentazione su come sviluppare un'architettura di archiviazione distribuita simile ad Aurora utilizzando MySQL standard con CEPH per un livello di archiviazione distribuito open source. C'è un webinar sullo stesso argomento qui:https://www.percona. com/resources/webinars/mysql-and-ceph , co-presentato da Yves Trudeau, l'ingegnere che ho visto parlare alla conferenza.
Ciò che è diventato chiaro sull'utilizzo di MySQL con CEPH è che gli ingegneri hanno dovuto disabilitare Buffer modifiche MySQL perché non c'è modo di memorizzare nella cache le modifiche agli indici secondari, mentre anche lo spazio di archiviazione è distribuito. Ciò ha causato enormi problemi di prestazioni per le scritture su tabelle che hanno indici secondari (non univoci).
Ciò era coerente con i problemi di prestazioni che abbiamo riscontrato durante il benchmarking della nostra applicazione con Aurora. Il nostro database aveva molti indici secondari.
Quindi, se devi assolutamente utilizzare Aurora per un database che ha un traffico di scrittura elevato, ti consiglio che la prima cosa che devi fare è eliminare tutti i tuoi indici secondari.
Ovviamente, questo è un problema se gli indici sono necessari per ottimizzare alcune delle tue query. Entrambe le query SELECT ovviamente, ma anche alcune query UPDATE e DELETE possono utilizzare indici secondari.
Una strategia potrebbe essere quella di creare una replica di lettura non Aurora del tuo cluster Aurora e creare gli indici secondari solo nella replica di lettura per supportare le tue query SELECT. Non l'ho mai fatto, ma a quanto pare è possibile, secondo https://aws.amazon.com/premiumsupport/knowledge-center/enable-binary-logging-aurora/
Ma questo non aiuta ancora i casi in cui le tue istruzioni UPDATE/DELETE necessitano di indici secondari. Non ho alcun suggerimento per quello scenario. Potresti essere sfortunato.
La mia conclusione è che non sceglierei di utilizzare Aurora per un'applicazione pesante in scrittura. Forse questo cambierà in futuro.
Aggiornamento aprile 2021:
Da quando ho scritto quanto sopra, ho eseguito i benchmark di sysbench contro Aurora versione 2. Non posso condividere i numeri specifici, ma concludo che gli attuali miglioramenti di Aurora sono migliori per carichi di lavoro pesanti in scrittura. Ho eseguito test con molti indici secondari per esserne sicuro. Ma incoraggio chiunque sia seriamente intenzionato ad adottare Aurora a eseguire i propri benchmark.
Almeno, Aurora è molto meglio di Amazon RDS convenzionale per MySQL che utilizza lo storage EBS. Probabilmente è qui che affermano che Aurora è 5 volte più veloce di MySQL. Ma Aurora non è più veloce di altre alternative che ho testato, e infatti non può eguagliare:
-
MySQL Server si è installato da solo su istanze EC2 utilizzando l'archiviazione locale, in particolare istanze i3 con NVMe collegato localmente. Comprendo che l'archiviazione delle istanze non è affidabile, quindi è necessario eseguire nodi ridondanti.
-
MySQL Server si è installato su host fisici nel nostro data center, utilizzando l'archiviazione SSD collegata direttamente.
Il valore dell'utilizzo di Aurora come database cloud gestito non riguarda solo le prestazioni. Dispone inoltre di monitoraggio automatizzato, backup, failover, aggiornamenti, ecc.
