Jak porównują się relacyjne bazy danych AWS

Relacyjna baza danych była przez długi czas dość standardowym rozwiązaniem dla różnych (i prawie wszystkich) przypadków użycia oprogramowania, które musiały rozwiązać duże lub małe firmy.

Obecnie zmienność jest znacznie większa dzięki szerszej dostępności baz danych NoSQL, in-memory lub data lake. Ale mimo to, ilekroć zapada decyzja o migracji obecnych lokalnych baz danych do chmury, relacyjna baza danych jako cel jest nadal najprostszą opcją dla tego przejścia.

Przyjrzymy się bliżej następującym bazom danych, które mogą być częścią takiej inicjatywy:

  • Wyrocznia
  • Zorza polarna
  • Serwer Microsoft SQL
  • MySQL i PostgreSQL
  • MariaDB

Wyjaśnię, czym różnią się od pozostałych i co je wyróżnia, w tym ich wady. Następnie przedstawię je w kontekście, demonstrując na typowym przykładzie użycia w świecie rzeczywistym. Na koniec podzielę się moim poglądem na wybór różnych baz danych dla twojej sprawy.

Baza danych AWS Oracle

Źródło: aws.amazon.com

Oracle DB była bez wątpienia najczęściej używaną komercyjną bazą danych w ciągu ostatnich kilku dekad. Zawsze, gdy firma potrzebowała niezawodnego i wydajnego rozwiązania bazodanowego, pierwszym wyborem była Oracle DB. I z wielu dobrych powodów.

Jak to się różni

Oracle to solidna i bogata w funkcje platforma, która może obsłużyć ogromną liczbę nawet całkowicie różnych konfiguracji i wymagań. Z biegiem czasu ta baza danych stała się najlepszym rozwiązaniem, jeśli potrzebujesz najnowocześniejszej niezawodności, skalowalności i łatwości konserwacji w lokalnej infrastrukturze sprzętowej.

Główne zalety

Oto niektóre z głównych korzyści płynących z wyboru tak dojrzałego systemu bazodanowego, jak Oracle:

✅ Świetne wsparcie i opcje skutecznego tworzenia kopii zapasowych i przywracania.

✅ Szerokie pole możliwości dostrajania wydajności rozwiązania DB wewnątrz systemu. Nawet długo później rozwiązanie jest już w fazie produkcji. Działania wspierające i konserwacyjne w ramach tej platformy są naprawdę łatwe do skonfigurowania i są bardzo skuteczne.

✅ Wysoka personalizacja rozwiązania DB. Ponieważ baza danych Oracle obsługuje szeroką gamę funkcji do wyboru, jako integrator systemów masz wiele możliwości zbudowania niezawodnego systemu składającego się dokładnie z tych funkcji, których potrzebuje Twoja platforma (wyzwalacze, partycje, podpartycje, zautomatyzowane sekwencje kluczy podstawowych, widoki , migawki, ograniczenia danych, klucze unikalne, klucze kombinowane, klucze obce, indeksy złożone itp.). Obsługuje wszystko.

✅ Łatwe administrowanie działaniami i procesami bazy danych. Dedykowane konsole administracyjne i pulpity nawigacyjne oraz wiele narzędzi stworzonych przez Oracle i dedykowanych wyłącznie administratorom do użytku od razu po wyjęciu z pudełka.

✅ Obsługa środowisk wielu użytkowników. Jeśli wymagana jest obsługa tysięcy różnych aktywnych użytkowników w tym samym czasie, rozwiązaniem jest Oracle.

Główne wady

Oracle DB jest bardzo elastyczny w zakresie pionowego skalowania wydajności. Ale mniej, gdy potrzebujesz silnego skalowania poziomego. Oznacza to, że łatwo jest dokonać aktualizacji do mocniejszego procesora, większej ilości pamięci i miejsca w bazie danych klastra.

Ale jeśli Twoje dane znacznie zwiększą się w krótkim czasie – co zwykle ma miejsce w przypadku danych w chmurze, wąskie gardła wydajności staną się bardziej widoczne i trudniejsze do rozwiązania. Rozprzestrzenianie danych na wiele klastrów i oczekiwanie ich dynamicznego wzrostu stanie się głównym wymaganiem w przyszłości. W takim przypadku może się okazać, że Oracle DB zacznie bardziej ograniczać niż zaspokajać przyszłe potrzeby.

Inną możliwą wadą może być koszt. Oracle DB obsługuje wiele funkcji, ale wiele z nich ma również swoją cenę. Tym bardziej, jeśli istnieje kilka klastrów i konieczne są fizyczne aktualizacje wydajności. Oznacza to, że dostrajanie oprogramowania modelu danych nie jest już wystarczające. Aby dostępnych było więcej narzędzi i funkcji administracyjnych, należy zakupić licencję korporacyjną. To jeszcze bardziej zwiększy i tak już wysokie koszty.

Wreszcie Oracle DB nie jest natywną usługą AWS DB, co oznacza, że ​​nie należy oczekiwać pełnego wsparcia ze strony AWS. Raczej zorientuj się na wsparcie Oracle. Ale potem zajmij się problemami Oracle i AWS równolegle i z dwoma różnymi zestawami zespołów wsparcia.

Kiedy wybrać

Wybór chmurowego odpowiednika bazy danych Oracle DB to najbardziej naturalna decyzja, którą należy podjąć, gdy obecne rozwiązanie lokalne korzysta już z bazy danych Oracle. Sprawi również, że migracja i przejście na rozwiązanie oparte na chmurze będzie tak proste, jak to tylko możliwe.

Dlatego wybierz AWS Oracle DB w przypadku:

  • Oczekujesz, że baza danych w chmurze będzie obsługiwać te same procesy i funkcje, co wersja lokalna w dającej się przewidzieć przyszłości.
  • Nie planujesz bardzo szybko integrować bazy danych ze zbyt wieloma natywnymi usługami AWS.
  • Nie spodziewasz się, że obecny wolumen danych znacznie wzrośnie w krótkim czasie.
  • Potrzebujesz wsparcia ogromnej ilości funkcjonalności na miejscu. Oznacza to, że przy przejściu na chmurę trudno byłoby stracić część z nich, które są obecnie na miejscu.
  • Twój system musi obsługiwać jednocześnie setki aktywnych użytkowników (lub więcej).

Przykład użycia

  • Duże systemy telekomunikacyjne do rozliczeń, CRM i danych oprogramowania pośredniczącego.
  • Niestandardowe implementacje baz danych dla samochodowych systemów baz danych, zintegrowane z kilkoma różnymi narzędziami niestandardowymi lub narzędziami dostawców zewnętrznych.
  • Pakietowe rozwiązania systemowe dla sektora bankowego, w przypadku których Oracle jest już stałą częścią pakietu rozwiązania oferowanego przez dostawców i ostatecznie integruje dodatkowe niestandardowe komponenty bazy danych w jedną złożoną implementację.

Baza danych AWS Aurora

Źródło: aws.amazon.com

Pod wieloma względami Aurora jest bezpośrednim przeciwieństwem Oracle, nawet jeśli nadal jest relacyjną bazą danych.

Jak to się różni

Autora DB to natywna usługa bazy danych w AWS. AWS zapewnia mu pełne wsparcie i ciągły rozwój oraz głęboko integruje go z resztą ekosystemu usług AWS.

Aurora DB nie osiąga takiego poziomu zróżnicowania funkcjonalności, jaki ma już Oracle. Ale narodził się w chmurze (w przeciwieństwie do Oracle). Ponieważ AWS dalej rozwija Aurorę, luka funkcjonalna może w przyszłości być mniejsza niż obecnie.

Pod wieloma względami Aurora już wyprzedza Oracle, zwłaszcza jeśli chodzi o integrację z innymi usługami chmurowymi AWS. A ponieważ Amazon stworzył Aurorę z myślą o ekosystemie chmurowym, Aurora jest gotowa na ogromny dochód z danych i wzrost w czasie, więc skalowanie w poziomie jest silną właściwością.

Główne zalety

Powiedziałbym, że głównymi zaletami Aurora DB są:

✅ Bardzo elastyczna rozszerzalność instancji kopii DB tylko do odczytu. Te, które możesz stworzyć w kilka sekund. Instancje tylko do odczytu współużytkują te same dzienniki DB głównej bazy danych, z której pochodzą. Oznacza to, że utworzenie nowej bazy danych tylko do odczytu nie wymaga synchronizacji wszystkich danych; robi to automatycznie, udostępniając istniejące.

✅ Gotowy na wzrost dużych ilości danych – skalowanie w poziomie to duża cecha Aurora DB. Dodawanie nowych klastrów i rozszerzanie skalowalności w różnych strefach dostępności jest tak proste, jak to tylko możliwe. Aurora jest wtedy bardzo skuteczna w bardzo szybkim wybieraniu dużych ilości danych.

✅ Możesz wybrać, czy chcesz korzystać z trybu serwerowego, czy bezserwerowego Aurora DB. Niektóre funkcje będą niedostępne w trybie bezserwerowym. Ale wybierając tryb bezserwerowy, zyskujesz dużą elastyczność i optymalizację kosztów.

✅ Zautomatyzowane kopie zapasowe i łatwe przywracanie do określonego punktu w czasie. Kolejną zaletą jest to, że Aurora DB może wykonywać łatwe codzienne kopie zapasowe, a przywracanie pełnej bazy danych do dowolnego punktu w czasie jest znacznie prostsze. Możesz połączyć tutaj wszystkie zalety środowiska chmurowego, takie jak zawsze dostępna wolna przestrzeń, szybkie operacje wewnętrzne AWS i dedykowana funkcja Aurora DB, która ma na celu szybki czas odzyskiwania i krótkie przestoje.

✅ Obsługa silnika MySQL lub PostgreSQL DB, więc możesz wybrać, który Ci odpowiada.

Główne wady

  • Mimo że Aurora jest prawdopodobnie najbardziej bogatą w funkcje natywną relacyjną bazą danych, jaką można wybrać w AWS, pod tym względem wciąż pozostaje w tyle za Oracle. To jest do zrozumienia; W przeszłości firma Oracle miała znacznie więcej czasu na opracowanie tych funkcji. Faktem jest, że Aurora DB jest z każdym wydaniem silniejsza i bliższa.
  • Nie ma odpowiednika Aurora DB w przestrzeni on-premise. Można argumentować, że stare bazy danych zbudowane w bazach danych MySQL lub PostgreSQL są do siebie bardzo podobne – iz punktu widzenia kompatybilności z pewnością tak jest. Ale nie są one ścisłym odpowiednikiem. Oznacza to, że migracja nie będzie tak prosta. Będziesz musiał dostosować i wdrożyć procesy migracji, aby mieć pewność, że przeniosą dane z lokalnego środowiska i zapiszą je w Aurora DB, a wszystko to w odpowiednim formacie modelu danych.
  • Różne limity AWS, zwłaszcza te twarde, są czynnikiem, który w niektórych przypadkach może zniechęcić do wybrania tej bazy danych jako celu do dalszego działania. Jest bardzo prawdopodobne, że będziesz w stanie obejść je wszystkie, ale w przypadku niektórych będziesz potrzebować poważniejszej inwestycji w refaktoryzację, co ostatecznie może zwiększyć ogólne koszty migracji w porównaniu z inną docelową bazą danych.

Kiedy wybrać

W skrócie wybór Aurora DB jako relacyjnej bazy danych goto na platformie AWS nigdy nie jest złą decyzją, ale zrób to, zwłaszcza jeśli:

  • Zbudujesz od podstaw system chmurowy wokół relacyjnej bazy danych.
  • Oczekujesz najwyższego poziomu kompatybilności i integralności z jak największą liczbą różnych natywnych usług AWS.
  • Oczekujesz, że ilość Twoich danych znacznie wzrośnie w krótkim czasie.
  • Planujesz rozpocząć kilka projektów spin-off proof of concept (POC), w których można wykorzystać wszystkie zalety bezserwerowej wersji relacyjnej bazy danych.

Przykład użycia

  • Bezserwerowa platforma do analizowania dużych ilości danych obrazu infrastruktury.
  • Wykorzystanie modeli uczenia maszynowego do przetwarzania informacji o jeziorze danych i generowania prognoz biznesowych dla Twojej firmy.
  • Netflix używa Aurora DB do szybkiego wykonywania równoległych zapytań dotyczących danych katalogowych.

Baza danych AWS Microsoft SQL

Źródło: aws.amazon.com

Ta baza danych jest pod pewnymi względami porównywalna z Oracle. Została również stworzona na długo przed tym, zanim chmura stała się czymś, a wielu obecnych użytkowników on-premise planuje migrację do chmury, korzystając z bazy danych MS SQL jako źródła.

Jak to się różni

Pomimo tych podobieństw, MS SQL DB jest nadal tą, która w przeszłości była znacznie mniej używana w porównaniu do Oracle DB.

Przynajmniej sądząc z perspektywy mojego osobistego doświadczenia. Byłem zaangażowany w wiele projektów Oracle w ciągu ostatnich dwóch dekad, ale tylko w kilku przypadkach, w których zaangażowany był MS SQL DB. I szczerze mówiąc, nie lubiłem sobie z tym radzić tak bardzo, jak z Oracle DB.

W każdym razie nadal rozpoznaję duży segment firm korzystających z MS SQL DB jako głównej bazy danych, która jest jedynym punktem prawdy dla wszystkich danych.

Główne zalety

Główne zalety, które posiada MS SQL DB:

✅ Dobra integracja z innymi usługami i oprogramowaniem Microsoft, jeśli jest to funkcja, którą uznasz za cenną w swojej sprawie.

✅ Łatwa personalizacja dzięki niestandardowym rozszerzeniom kodu, głównie w postaci modułów kodu JavaScript. Może to być przydatne w przypadku bardziej złożonych procesów biznesowych i zadań, które mają być zaplanowane w bazie danych.

✅ Dość proste z punktu widzenia administracji (przynajmniej w porównaniu do Oracle DB).

✅ Prawdopodobnie ma to dużo większy sens w ekosystemie chmury Azure, ponieważ tam jest uważany za natywny system relacyjnej bazy danych, znacznie bardziej kompatybilny z innymi usługami chmurowymi.

Główne wady

  • Podobnie jak w przypadku Oracle DB, jako nienatywnej bazy danych w przestrzeni chmury AWS, całe wsparcie i rozwiązywanie problemów musi być realizowane przez oddzielne dedykowane zespoły wsparcia MS SQL.
  • Mniejsze zróżnicowanie obsługi funkcjonalności w porównaniu z Oracle DB lub Aurora DB.
  • Nieodpowiednie dla dużej liczby aktywnych użytkowników.
  • Skalowalność pozioma jest jeszcze większym problemem niż w przypadku Oracle DB.

Kiedy wybrać

Baza danych MS SQL najlepiej nadaje się do migracji istniejącej lokalnej bazy danych MS SQL do chmury przy jak najmniejszej liczbie czynników rozpraszających uwagę. Ponadto nie oczekujesz takiej integracji z innymi usługami chmurowymi AWS w dużym stopniu.

Następnie baza danych MS SQL będzie działać w chmurze AWS jako w pełni zarządzana baza danych z nieograniczoną pamięcią masową i rozszerzonymi opcjami skalowalności poziomej i wysokiej dostępności w porównaniu z alternatywą lokalną.

Przykład użycia

  • Działając jako pośrednia platforma do niestandardowej integracji różnych systemów bazodanowych (może być nawet innego typu, na przykład Oracle DB).
  • Różne mniejsze projekty, w których koszt rozwiązania bazodanowego jest kwestią do rozważenia, a budżet jest bardziej ograniczony (i nie pozwala na pełnoprawne rozwiązanie Oracle DB).

Baza danych AWS MySQL i PostgreSQL

Źródło: aws.amazon.com

Te bazy danych są z natury otwarte (chociaż teraz są już kupowane przez większe firmy), co ostatecznie daje im zarówno zalety, jak i wady.

Nie są też tak bogate w funkcje jak inne alternatywy, zwłaszcza w swojej natywnej formie. I chociaż nadal możesz używać ich obu w infrastrukturze AWS w tej formie, wątpię, czy nadal ma to zbyt duży sens praktyczny.

Jak to się różni

Podczas migracji lokalnej bazy danych (czy to MySQL, czy PostgreSQL) do chmury AWS, możesz po prostu bezpośrednio użyć Aurory z silnikiem MySQL lub PostgreSQL jako celu, aby uzyskać wszystkie dodatkowe korzyści, jakie ma do zaoferowania Aurora DB.

Oczywiście będzie to oznaczało dodatkowy wysiłek w fazie migracji w porównaniu z przypadkiem wyboru rodzimej alternatywy. Ale ten dodatkowy wysiłek będzie tylko marginalny.

Ich główna zaleta polega na kosztach i tym, że najlepiej nadają się do małych inicjatyw projektowych, w których solidność nie jest tak naprawdę tematem.

Główne wady

  • Oba mają dość ograniczoną obsługiwaną funkcjonalność i trzeba być przygotowanym na ograniczone opcje konserwacji i administracji.
  • Nie nadaje się do dużych projektów z wieloma aktywnymi użytkownikami.
  • Nienajlepsze w przypadku rozwiązań o wysokiej wydajności, w których ciągłe dostrajanie wydajności jest silnym wymaganiem.

Kiedy wybrać

  • Jeśli koszt jest głównym tematem, a budżet jest bardzo ograniczony.
  • Jeśli inicjatywa projektu jest raczej niewielka.
  • Jeśli wolumen danych jest raczej mały i nie ma planów znacznego wzrostu.

Przykład użycia

  • Indywidualne inicjatywy projektowe, w których koszt infrastruktury powinien być jak najmniejszy.
  • Małe POC, które udowodniłyby, że proponowana koncepcja może zostać zrealizowana.
  • Projekty małych firm z niewielką ilością danych.
  • W przypadku małych projektów SaaS, które nie wymagają dużej liczby obciążeń baz danych, tak naprawdę wystarczy przechowywanie danych w sposób relacyjny model danych.

AWS MariaDB

Źródło: aws.amazon.com

MariaDB jest nadal w pełni otwartą bazą danych stworzoną przez byłych programistów MySQL (po przejęciu MySQL przez Oracle).

Jeśli chodzi o kompatybilność, każda baza danych MySQL będzie działać dobrze w MariaDB.

Jak to się różni

Pod względem funkcji nie ma wielu różnic w stosunku do MySQL, ale najważniejszą cechą jest właściwość open source.

Technicznie rzecz biorąc, istnieje wiele przydatnych funkcji, które są dostępne w MariaDB, ale nie w MySQL.

Główne wady

Całkiem podobny do przypadku MySQL.

Kiedy wybrać

  • Jeśli absolutnie podoba Ci się Twoja obecna lokalna implementacja MariaDB i z jakiegokolwiek powodu nie chcesz migrować do Aurora DB.
  • Jeśli chcesz pozostać prawdziwie open-source ze swoim rozwiązaniem bazodanowym w ekosystemie chmurowym AWS.

Przykład użycia

Całkiem podobny do przypadku MySQL.

Ostatnie słowa

Podobnie jak Oracle DB było rozwiązaniem w świecie on-premise, wydaje się, że Aurora DB zajmuje to miejsce w świecie chmury AWS. Przynajmniej z perspektywy zestawów funkcji jest to najbliższe, jakie można uzyskać.

I nawet jeśli tak naprawdę nie interesujesz się głównymi interesariuszami, dobrze jest wiedzieć, że nadal istnieją całkiem proste opcje migracji istniejącej bazy danych do chmury AWS.

Jeszcze lepiej – dzięki temu przełącznikowi automatycznie uzyskasz funkcje, których najprawdopodobniej brakowało Ci do tej pory. Co najważniejsze, lepsze możliwości rozbudowy pamięci masowej, wysoka dostępność i skalowalność pozioma to natywne cechy środowiska chmurowego.