От моя опит, Amazon Aurora не е подходяща за управление на база данни с голям трафик на запис. Поне при прилагането му около 2017 г. Може би ще се подобри с времето.
По-рано през 2017 г. работих върху някои бенчмаркове за приложение с тежко записване и открихме, че RDS (не-Aurora) е много по-добър от Aurora по отношение на производителността на запис, като се има предвид нашето приложение и база данни. По принцип Aurora беше с два порядъка по-бавна от RDS. Твърденията на Amazon за висока производителност за Aurora очевидно са изцяло маркетингови глупости.
През ноември 2016 г. присъствах на конференцията Amazon re:Invent в Лас Вегас. Опитах се да намеря опитен инженер на Aurora, който да отговори на въпросите ми относно производителността. Всичко, което успях да намеря, бяха младши инженери, на които беше наредено да повторят твърдението, че Aurora е магически 5-10 пъти по-бърза от MySQL.
През април 2017 г. присъствах на конференцията на Percona Live и видях презентация за това как да се разработи подобна на Aurora архитектура за разпределено съхранение, използвайки стандартен MySQL с CEPH за слой за разпределено съхранение с отворен код. Тук има уебинар на същата тема:https://www.percona. com/resources/webinars/mysql-and-ceph , представен съвместно от Ив Трюдо, инженерът, когото видях, говори на конференцията.
Това, което стана ясно за използването на MySQL с CEPH е, че инженерите трябваше да деактивират Буфер за промяна на MySQL защото няма начин да се кешират промените във вторичните индекси, като същевременно има разпределено съхранение. Това причини огромни проблеми с производителността за запис в таблици, които имат вторични (неуникални) индекси.
Това беше в съответствие с проблемите с производителността, които видяхме при сравнителния анализ на нашето приложение с Aurora. Нашата база данни имаше много вторични индекси.
Така че, ако абсолютно трябва да използвате Aurora за база данни с голям трафик на запис, препоръчвам първото нещо, което трябва да направите, е да изпуснете всичките си вторични индекси.
Очевидно това е проблем, ако индексите са необходими за оптимизиране на някои от вашите заявки. Разбира се, и двете заявки SELECT, но също и някои заявки UPDATE и DELETE могат да използват вторични индекси.
Една стратегия може да бъде да направите реплика за четене, различна от Aurora, на вашия клъстер Aurora и да създадете вторичните индекси само в репликата за четене, за да поддържате вашите SELECT заявки. Никога не съм правил това, но очевидно е възможно, според https://aws.amazon.com/premiumsupport/knowledge-center/enable-binary-logging-aurora/
Но това все още не помага в случаите, когато вашите UPDATE/DELETE изрази се нуждаят от вторични индекси. Нямам никакво предложение за този сценарий. Може да нямате късмет.
Моето заключение е, че не бих избрал да използвам Aurora за приложение с тежко писане. Може би това ще се промени в бъдеще.
Актуализация април 2021 г.:
Откакто написах горното, използвах бенчмаркове на sysbench срещу Aurora версия 2. Не мога да споделя конкретните числа, но заключавам, че настоящите подобрения на Aurora са по-добри за тежко натоварване на запис. Проведох тестове с много вторични индекси, за да се уверя. Но насърчавам всеки, който е сериозен относно приемането на Aurora, да изпълнява свои собствени показатели.
Поне Aurora е много по-добра от конвенционалния Amazon RDS за MySQL, използвайки EBS съхранение. Вероятно там твърдят, че Aurora е 5 пъти по-бърза от MySQL. Но Aurora не е по-бърза от някои други алтернативи, които тествах, и всъщност не може да съвпадне:
-
MySQL Server се инсталирах на EC2 инстанции, използвайки локално съхранение, особено i3 инстанции с локално прикрепен NVMe. Разбирам, че съхранението на екземпляри не е надеждно, така че ще трябва да стартирате излишни възли.
-
MySQL Server се инсталирах на физически хостове в нашия център за данни, използвайки директно свързано SSD съхранение.
Стойността на използването на Aurora като управлявана облачна база данни не е само в производителността. Той също така има автоматизирано наблюдение, архивиране, отказ, надстройки и т.н.
