Често чуваме този въпрос:Какво става с Amazon Aurora? Когато определяте най-добре управляваната услуга за база данни за вашата организация, има множество фактори, които трябва да вземете предвид – и обща нишка, минаваща през всички тях, е колко контрол ви е необходим. Amazon хвърля голяма тежест зад предлагането на Aurora DBaaS, но – в зависимост от вашите изисквания и приоритети – изборът да стартирате база данни като MariaDB на Amazon EC2 или друга услуга, която не е на Amazon, може да е по-подходяща за вас.
Ето четири неща, които вероятно не сте знаели за Amazon Aurora.
Остаряла, остаряла база данни
Amazon Aurora 2.x използва стара версия на MySQL 5.7.
Aurora 2.0.1 беше пусната през февруари 2018 г., използвайки MySQL 5.7.12, самата пусната през април 2016 г. Aurora 2.x все още използва стара версия на MySQL 5.7. Въпреки това, Amazon вече не публикува версията за поддръжка, която използва. Това не трябва да е изненада. Има над дузина издания за поддръжка на MySQL от 5.7.12. Колко от корекциите на грешки, съдържащи се в тях, Amazon е пренесъл обратно? 17… от стотици.
- Aurora 2.02.0:Бъг #22833364
- Aurora 2.02.3:Бъгове #24929748, #26867509, #22843444, #25080442
- Aurora 2.03.0:Бъгове #24929748, #26867509, #22843444, #25080442
- Aurora 2.03.3:Бъгове #25361251, #26734162, #27460607, #22343910, #23074801, #25287633
- Aurora 2.04.0:Бъг #26225783
- Aurora 2.04.2:Бъг #24829050
Ако можехте да изберете нова база данни, бихте ли избрали такава, издадена преди повече от три години, такава, на която липсват три години корекции на грешки, корекции за сигурност, подобрения и нови функции?
Необходими престой и прекъсване
Aurora изисква престой за поддръжка. Докато част от поддръжката не е задължителна и може да бъде отложена за неопределено време, друга поддръжка, като корекции за сигурност и надеждност, не само е необходима, но води до прекъсване по време на случаен 30-минутен прозорец за поддръжка. Освен това надстройките на базата данни (т.е. актуализациите на двигателя на базата данни) водят до 20-30 секунди престой, тъй като се извършват на всеки екземпляр на база данни в рамките на клъстер по едно и също време.
Платформата MariaDB, от друга страна, поддържа непрекъснати надстройки с изящни превключвания, позволявайки на DBA да извършват поддръжка с нулев престой при поискване.
Освен поддръжката и надстройките, Aurora може да отнеме до две минути, за да извърши автоматично преминаване при отказ, което води до повече време на престой. Освен това автоматичното преминаване на отказ води до загубени връзки, сесии и транзакции по време на полет.
Платформата MariaDB, за разлика от Aurora, поддържа клъстериране с няколко главни за елиминиране на престоя поради неочакван отказ. В допълнение, платформата MariaDB поддържа миграция на връзка, възстановяване на сесия и повторно възпроизвеждане на транзакции, за да гарантира, че неочаквани неуспехи няма да повлияят на приложенията.
Липса на корпоративна сигурност
Aurora няма много от функциите за корпоративна сигурност, очаквани от съвременните бази данни, включително защитна стена на базата данни, динамично маскиране на данни, роли, ротация на ключове и TLS 1.3.
Aurora поддържа услугата за управление на ключове на Amazon, но не поддържа ротация на ключове за екземпляр на база данни. По-скоро може да се използва псевдоним на ключ за промяна на ключа за нови екземпляри на база данни. Като такъв, дори ако се добави нов ключ, съществуващите екземпляри на база данни ще продължат да криптират и декриптират данни, използвайки стария ключ.
Платформата MariaDB поддържа ротация на ключове и когато се добави нов ключ, тя може автоматично да криптира отново данните с помощта на новия ключ – позволявайки старият ключ да бъде изхвърлен.
Aurora няма мощната защитна стена на базата данни и функциите за динамично маскиране на база данни, налични в платформата MariaDB, и тъй като Aurora е базирана на стара версия на MySQL, липсват и роли. Освен това е ограничен до TLS 1.0, 1.1 и 1.2.
Най-малкият общ знаменател
Aurora предоставя на потребителите обикновена база данни, създадена с помощта на шаблон за изрязване на бисквитки, предназначен да отговаря на най-малкия общ знаменател. Докато платформата MariaDB може да мащабира четене, запис и съхранение с прозрачно споделяне чрез механизма за съхранение на Spider или да се възползва от оптимизирано за запис и пространство съхранение на SSD чрез механизма за съхранение на MyRocks (разработен от Facebook), Aurora няма нито едно от двете. Той е ограничен до механизма за съхранение на InnoDB.
След това има разпределено, колонно съхранение и масова паралелна обработка с MariaDB ColumnStore. Това е още един двигател за съхранение, който не е наличен в Aurora. Въпреки че Amazon би предложил използването на Aurora за обработка на транзакции и Redshift за анализ, и двете могат да се направят с платформата MariaDB – позволяваща хибридна транзакционна/аналитична обработка (HTAP).
Отвъд двигателите за съхранение, оптимизирани за работното натоварване, има много функции, налични в платформата MariaDB, които не могат да бъдат намерени в Aurora, включително съвместимост с Oracle Database (т.е. PL/SQL), времеви таблици, връщане назад към момента, поточно улавяне на промяна на данни , производител на Apache Kafka, прозрачно разделяне на четене/запис, ограничения за проверка, изрази за стойности по подразбиране, изрази за общи таблици, оператори за набор, функции на прозореца, дефинирани от потребителя функции (скаларни, агрегатни и прозорец), последователности и др.
Собственият опит на Amazon с Aurora илюстрира важността на съображенията по-горе. Малко след преместването на някои от техните бази данни в Aurora, Amazon се сблъска с широко разпространени прекъсвания и други проблеми с базата данни по време на Prime Day 2018. С наближаването на Prime Day 2019 желаем на Amazon успех!
