Często słyszymy to pytanie:co się dzieje z Amazon Aurora? Podczas określania najlepszej zarządzanej usługi bazy danych dla Twojej organizacji należy wziąć pod uwagę wiele czynników — a wspólnym wątkiem, który przechodzi przez wszystkie, jest to, ile kontroli potrzebujesz. Amazon przywiązuje dużą wagę do swojej oferty Aurora DBaaS, ale – w zależności od Twoich wymagań i priorytetów – wybór uruchomienia bazy danych, takiej jak MariaDB na Amazon EC2 lub innej, innej niż Amazon usłudze, może być dla Ciebie lepszym rozwiązaniem.
Oto cztery rzeczy, których prawdopodobnie nie wiedziałeś o Amazon Aurora.
Starzejąca się, przestarzała baza danych
Amazon Aurora 2.x używa starej wersji MySQL 5.7.
Aurora 2.0.1 została wydana w lutym 2018, używając MySQL 5.7.12, która została wydana w kwietniu 2016. Aurora 2.x nadal używa starej wersji MySQL 5.7. Jednak Amazon nie publikuje już używanej wersji serwisowej. Nie powinno to dziwić. Od wersji 5.7.12 pojawiło się kilkanaście wydań konserwacyjnych MySQL. Ile zawartych w nich poprawek błędów Amazon przeportował? 17… na setki.
- Aurora 2.02.0:błąd #22833364
- Aurora 2.02.3:Błędy #24929748, #26867509, #22843444, #25080442
- Aurora 2.03.0:Błędy #24929748, #26867509, #22843444, #25080442
- Aurora 2.03.3:Błędy #25361251, #26734162, #27460607, #22343910, #23074801, #25287633
- Aurora 2.04.0:błąd #26225783
- Aurora 2.04.2:błąd #24829050
Gdybyś mógł wybrać nową bazę danych, czy wybrałbyś tę wydaną ponad trzy lata temu, w której brakuje trzech lat poprawek błędów, poprawek bezpieczeństwa, ulepszeń i nowych funkcji?
Wymagane przestoje i przerwy
Aurora wymaga przestojów na konserwację. Chociaż niektóre prace konserwacyjne są opcjonalne i można je odraczać na czas nieokreślony, inne czynności konserwacyjne, takie jak poprawki bezpieczeństwa i niezawodności, są nie tylko wymagane, ale powodują przestój podczas losowego 30-minutowego okna konserwacyjnego. Co więcej, aktualizacje bazy danych (tj. aktualizacje silnika bazy danych) powodują 20-30 sekund przestoju, ponieważ są wykonywane na każdej instancji bazy danych w klastrze w tym samym czasie.
Z drugiej strony platforma MariaDB obsługuje aktualizacje stopniowe z wdzięcznymi przełączeniami, dzięki czemu administratorzy baz danych mogą na żądanie wykonywać konserwację bez przestojów.
Poza konserwacją i aktualizacjami, Aurora może zająć do dwóch minut, aby wykonać automatyczne przełączanie awaryjne, co skutkuje dłuższymi przestojami. Co więcej, automatyczne przełączanie awaryjne skutkuje utratą połączeń, sesji i transakcji w locie.
Platforma MariaDB, w przeciwieństwie do Aurora, obsługuje klastrowanie z wieloma wzorcami, aby wyeliminować przestoje spowodowane nieoczekiwaną awarią. Ponadto platforma MariaDB obsługuje migrację połączeń, przywracanie sesji i odtwarzanie transakcji, aby nieoczekiwane awarie nie miały wpływu na aplikacje.
Brak bezpieczeństwa korporacyjnego
Aurora nie ma wielu funkcji bezpieczeństwa korporacyjnych oczekiwanych od nowoczesnych baz danych, w tym zapory bazy danych, dynamicznego maskowania danych, ról, rotacji kluczy i TLS 1.3.
Aurora obsługuje usługę Amazon Key Management Service, ale nie obsługuje rotacji kluczy dla instancji bazy danych. Zamiast tego można użyć aliasu klucza do zmiany klucza dla nowych instancji bazy danych. W związku z tym, nawet jeśli zostanie dodany nowy klucz, istniejące instancje bazy danych będą nadal szyfrować i odszyfrowywać dane przy użyciu starego klucza.
Platforma MariaDB obsługuje rotację kluczy, a po dodaniu nowego klucza może automatycznie ponownie zaszyfrować dane za pomocą nowego klucza – umożliwiając odrzucenie starego klucza.
Aurora nie ma potężnej zapory bazy danych i funkcji dynamicznego maskowania bazy danych dostępnych w platformie MariaDB, a ponieważ Aurora jest oparta na starej wersji MySQL, brakuje jej również ról. Ponadto jest ograniczony do TLS 1.0, 1.1 i 1.2.
Najmniejszy wspólny mianownik
Aurora zapewnia użytkownikom podstawową bazę danych utworzoną przy użyciu szablonu obcinacza ciasteczek, który ma spełniać najmniej wspólny mianownik. Platforma MariaDB może skalować odczyty, zapisy i pamięć masową dzięki przezroczystemu fragmentowaniu za pośrednictwem silnika pamięci masowej Spider lub korzystać z pamięci masowej zoptymalizowanej pod kątem zapisu i miejsca na dyskach SSD za pośrednictwem silnika pamięci masowej MyRocks (opracowanego przez Facebook), jednak Aurora tego nie robi. Jest ograniczony do silnika pamięci masowej InnoDB.
Następnie istnieje rozproszona, kolumnowa pamięć masowa i masowo równoległe przetwarzanie za pomocą MariaDB ColumnStore. Jest to kolejny silnik pamięci masowej niedostępny w Aurorze. Podczas gdy Amazon sugerowałby użycie Aurory do przetwarzania transakcyjnego i Redshift do analiz, oba można zrobić za pomocą MariaDB Platform – umożliwiając hybrydowe przetwarzanie transakcyjne/analityczne (HTAP).
Oprócz silników pamięci masowej zoptymalizowanych pod kątem obciążenia istnieje wiele funkcji dostępnych w platformie MariaDB, których nie można znaleźć w Aurora, w tym zgodność z bazą danych Oracle (tj. PL/SQL), tabele czasowe, wycofywanie zmian do określonego momentu, przesyłanie strumieniowe i przechwytywanie danych , producent Apache Kafka, przejrzysty podział odczytu/zapisu, ograniczenia sprawdzające, wyrażenia wartości domyślnych, wspólne wyrażenia tabelowe, operatory zestawów, funkcje okien, funkcje zdefiniowane przez użytkownika (skalarne, agregujące i okienne), sekwencje i wiele więcej.
Własne doświadczenie Amazona z Aurora ilustruje znaczenie powyższych rozważań. Wkrótce po przeniesieniu niektórych swoich baz danych do Aurory, Amazon doświadczył powszechnych przerw w działaniu i innych problemów z bazami danych podczas Prime Day 2018. W miarę zbliżania się Prime Day 2019 życzymy Amazonowi powodzenia!
