Трябва внимателно да сравните Aurora, преди да я обмислите. Стартирайте екземпляр и настройте тестов екземпляр на вашето приложение и вашата база данни. Генерирайте възможно най-високо натоварване. Направих го в последната си компания и открих, че въпреки твърденията на Amazon за висока производителност, Aurora се провали грандиозно. Два порядъка по-бавен от RDS. Приложението ни имаше висок трафик на запис.
Нашето заключение:ако имате вторични индекси и имате голям трафик на запис, Aurora не е подходяща. Обзалагам се, че е добър за трафик само за четене.
(Редактиране:тестването, което описвам, беше извършено през първото тримесечие на 2017 г. Както при повечето услуги на AWS, очаквам Aurora да се подобри с времето. Amazon има изрична стратегия за "Публикувайте идеи на 70% и след това повторете. " От това трябва да заключим, че нов продукт от AWS си заслужава да бъде тестван, но вероятно не е готов за производство поне няколко години след представянето му).
В тази компания препоръчах RDS. Те нямаха специален персонал на DBA и автоматизацията, която RDS ви дава за операции с DB като надстройки и архивиране, беше много полезна. Вие жертвате малко гъвкавост при опциите за настройка, но това не би трябвало да е проблем.
Най-лошото неудобство на RDS е, че не можете да имате потребител на MySQL със СУПЕР привилегия, но RDS предоставя съхранени процеси за най-често срещаните задачи, за които бихте се нуждаели от СУПЕР привилегия.
Сравних екземпляр за RDS с няколко AZ спрямо набор от копия от EC2 екземпляри, управлявани от Orchestrator. Тъй като Orchestrator изисква три възела, за да можете да имате кворум, RDS беше безспорният победител по отношение на разходите тук, както и по лекотата на настройка и операции.
