Z mé zkušenosti je Amazon Aurora nevhodný pro provozování databáze s velkým provozem zápisu. Alespoň v jeho implementaci cca 2017. Možná se to časem zlepší.
Na začátku roku 2017 jsem pracoval na některých benchmarcích pro aplikaci s vysokými nároky na zápis a zjistili jsme, že RDS (non-Aurora) je mnohem lepší než Aurora, pokud jde o výkon zápisu, vzhledem k naší aplikaci a databázi. V podstatě byla Aurora o dva řády pomalejší než RDS. Tvrzení Amazonu o vysokém výkonu pro Auroru jsou zjevně zcela marketingově řízené kecy.
V listopadu 2016 jsem se zúčastnil konference Amazon re:Invent v Las Vegas. Snažil jsem se najít zkušeného inženýra Aurory, aby odpověděl na mé otázky o výkonu. Jediné, co jsem našel, byli mladší inženýři, kteří dostali příkaz opakovat tvrzení, že Aurora je magicky 5-10x rychlejší než MySQL.
V dubnu 2017 jsem se zúčastnil konference Percona Live a viděl jsem prezentaci o tom, jak vyvinout architekturu distribuovaného úložiště typu Aurora pomocí standardního MySQL s CEPH pro vrstvu distribuovaného úložiště s otevřeným zdrojovým kódem. Zde je webinář na stejné téma:https://www.percona. com/resources/webinars/mysql-and-ceph , spoluprezentovaný Yvesem Trudeauem, inženýrem, kterého jsem viděl mluvit na konferenci.
Při používání MySQL s CEPH bylo jasné, že inženýři museli deaktivovat Vyrovnávací paměť změn MySQL protože neexistuje způsob, jak uložit změny do mezipaměti sekundárních indexů a zároveň mít distribuované úložiště. To způsobilo obrovské problémy s výkonem pro zápisy do tabulek, které mají sekundární (nejedinečné) indexy.
To bylo v souladu s problémy s výkonem, které jsme viděli při srovnávání naší aplikace s Aurorou. Naše databáze měla mnoho sekundárních indexů.
Pokud tedy bezpodmínečně musíte použít Auroru pro databázi s vysokým provozem zápisu, doporučuji první věc, kterou musíte udělat, je zrušit všechny sekundární indexy.
Je zřejmé, že je to problém, pokud jsou indexy potřebné k optimalizaci některých vašich dotazů. Oba SELECT dotazy samozřejmě, ale také některé UPDATE a DELETE dotazy mohou používat sekundární indexy.
Jednou strategií může být vytvořit repliku vašeho clusteru Aurora pro čtení, která není Aurora, a vytvořit sekundární indexy pouze ve čtené replice pro podporu vašich SELECT dotazů. Nikdy jsem to nedělal, ale zjevně je to možné, podle https://aws.amazon.com/premiumsupport/knowledge-center/enable-binary-logging-aurora/
To však stále nepomáhá v případech, kdy vaše příkazy UPDATE/DELETE potřebují sekundární indexy. Nemám pro tento scénář žádný návrh. Možná máte smůlu.
Můj závěr je, že bych se nerozhodl používat Auroru pro aplikace náročné na zápis. Možná se to v budoucnu změní.
Aktualizace z dubna 2021:
Od napsání výše uvedeného jsem spouštěl sysbench benchmarky proti Auroře verze 2. Nemohu se s vámi podělit o konkrétní čísla, ale docházím k závěru, že současná vylepšení Aurory jsou lepší pro zátěž s velkým množstvím zápisu. Pro jistotu jsem provedl testy se spoustou sekundárních indexů. Ale doporučuji každému, kdo to myslí vážně s přijetím Aurory, aby spouštěl své vlastní benchmarky.
Přinejmenším je Aurora mnohem lepší než konvenční Amazon RDS pro MySQL využívající úložiště EBS. To je pravděpodobně místo, kde tvrdí, že Aurora je 5x rychlejší než MySQL. Ale Aurora není rychlejší než některé jiné alternativy, které jsem testoval, a ve skutečnosti se jim nemůže rovnat:
-
MySQL Server jsem nainstaloval na instance EC2 pomocí místního úložiště, zejména instance i3 s lokálně připojeným NVMe. Chápu, že úložiště instancí není spolehlivé, takže by bylo potřeba spouštět redundantní uzly.
-
MySQL Server jsem si sám nainstaloval na fyzické hostitele v našem datovém centru pomocí přímo připojeného úložiště SSD.
Hodnota používání Aurory jako spravované cloudové databáze není jen o výkonu. Má také automatické monitorování, zálohování, převzetí služeb při selhání, upgrady atd.