Skalowanie baz danych

0

Cześć,
Zastanawiam się jak skalowane są bazy danych. Dajmy na to, mamy infrastrukturę złożoną z dockerowych obrazów mikroserwisów, którymi zarządza Kubernetes. Jak to się ma do baz danych? Tworzenie kopii na podstawie obrazu nie zagwarantowałoby spójności danych na różnych instancjach baz. Znacie jakieś rozwiązania/ciekawe artykuły na ten temat?

1

Istnieje przynajmniej kilkaset różnych baz danych - każdą będzie się skalowało inaczej. O którą konkretnie Ci chodzi?

0

Chodziło mi bardziej o sposoby skalowania niż dokładny schemat dla danej technologii. Weźmy np taki PostgresSQL. Praktyka jest taka jak w przypadku mikroserwisów - stawiamy bazę na podstawie dockerowego obrazu? Co jeśli kubernetes ubije poda?
Ciężko mi sobie wyobrazić jak mogłoby to działać w zdecentralizowany sposób

4

Najpopularniejszy sposób na skalowanie bazy danych to master-slave, jedną masz tylko do zapisu (master), plus kilka replik tylko do odczytu(slave). Jak master pada, to slave wybierają wśród siebie nowego mastera.

I baz raczej w kontenerach się nie trzyma, jeśli chce się wycisnąć maks z serwera.

1

Ja to jeszcze rozróżniam skalowanie na podstawie podejścia do danych (consistency). Silniki, które bardziej dbają o integralność danych inaczej się skalują od silników, które mniej i zupełnie inaczej od silników, które w ogóle temat "zlewają".

1

Sposoby na skalowanie to:

  • sharding
  • replication, różne typy najczęściej master-slave i do tego CQRS

To co przeszkadza w skalowaniu zawarte jest w teorii CAP, chociaż google twierdzi że poradził sobie z tym i ma produkt Spanner.
Trudniej jest skalować bazy relacyjne niż NoSQL.

0

Możesz popatrzeć na rozwiązania typu https://www.yugabyte.com/ lub https://www.cockroachlabs.com/ sa to wysoko wydajne bazy relacyjne (wspierają ACID i SQLa ). Jak dobrze pamiętam to obydwie są oparte na PostgreSQL. EDIT: Nie dobrze pamiętam patrz ponizej.
Możesz też poszukać pod hasłem sharding.

0

Jeśli chcesz naprawdę skalowalną bazę danych to relacyjne bazy danych odpadają. Problemem są joiny w SQLu. W zasadzie można by nawet używać relacyjnych baz danych tylko nie używać relacji, a wszystko trzymać w PostgreSQL jako BJSONy.
Z nierelacyjnych, skalowalnych i darmowych baz danych prawdopodobnie najlepsza jest Cassandra, pracująca jako master-master. Określenie NoSQL słabo do niej pasuje, bo posiada swój język zapytać CQL, który wygląda prawie jak SQL. Tylko tego nieszczęsnego joina nie ma

0

Z jakimi sytuacjami najczęściej się spotykacie? Częściej skaluje się bazy, czy raczej korzystające z nich aplikacje?

2

Częściej spotykam sytuacje, w których baza się nudzi, a aplikacja jest słabo napisana. Ewentualnie aplikacja zarzyna bazę jakimiś słabymi zapytaniami.

Trzeba też odróżnić zagadnienie skalowalności (zdolność systemu do przetworzenia większej ilości zadań po tym jak dodajemy zasoby) od odporności systemu na awarie komponentów. Skalować możemy pionowo (zwiększamy zasoby maszyny na której działa komponent) albo poziomo (dodajemy więcej maszyn i instancji komponentów).

Są to powiązane elementy, ale jednak różne. Co więcej trudne do pogodzenia jak mamy wybierać spośród: wydajności, dostępności, maksymalnej ochrony danych (to ze względu, że np. większą przepustowość osiągniemy idąc w model asynchroniczny, ale godzimy się na utratę danych w pewnych nieszczęśliwych splotach zdarzeń).

Przed awariami zabezpieczamy się przez wprowadzenie redundancji na różnych poziomach rozwiązania:

  • osobne lokalizacje (geo-redundancja), w których są serwerownie,
  • redundancja połączeń między data center (różne fizyczne ścieżki),
  • zasilaniem (agregaty prądotwórcze, upsy, osobne linie zasilania)
  • na poziomie serwera - dwa zasilacze, po 2 karty sieciowe na różnych kontrolerach, każda z kart po >=2 porty, podpięte do 2 różnych switchy na 2 sposoby etc.
  • na poziomie storage (wszelkiej maści RAIDy, replikacja macierz-macierz między lokalizacjami)
  • na poziomie OS (klastry HA), klastrowe systemy plików
  • współdzielone systemy plików
  • klastry aplikacyjne/bazodanowe
  • wirtualizacja dodaje kolejny zestaw narzędzi wspomagających rozwiązania (cała gama produktów, np. vSphere/vStorage/vMotion/...).

Możemy mieć spoko klaster Active-Active, ale i tak dupa, bo ktoś np. zapomniał odseparować ruch aplikacyjny od ruchu dla replikacji klastra, czy nie zrobił bondingu.

ie znam specyfiki cloudów, żeby się wypowiadać, czy wszystkie bolączki typowych systemów enterprajzowych zostały rozwiązane, czy raczej zdjęte z barków projektantów (nie muszą wiedzieć w jaki sposób macierz podpięta jest do serwera) i przypudrowane usługami.

W komentarzach przewinął się googlowy spanner, które ma być remedium na różne bolączki, ale możliwe, że to tylko chwyt marketingowy i będzie tak jak w Apache Ignite (reklamuje się jako łączący funkcjonalnośći RDBMS/IMDG/NoSQL, ale czy o to chodziło... )

Co do skalowalności samych baz, to są opcje:

  • więcej zasobów (RAM, CPU, szybszy storage)
  • dodawanie instancji (Oracle RAC, Greenplum)
  • dedykowane kombajny (Exadata )

Ale co z tego jeśli baza się będzie skalować, a aplikacja nie? Trafiają się aplikacje, które nie potrafią zrobić reconnecta do klastra bazodanowego, nie potrafią działać w klastrze i cała $$$ na wysoką dostępność/wydajność infrastruktury marnuje się, bo jest jakiś single-point-of-failure-by-app-design :-)

1

Chyba za bardzo odjechaliście od głównego tematu pytania OP które było o mikroserwisy. Ogólna odpowiedź jest taka, że nie można wrzucić warstwy stateful do mikroserwisu, którego chcemy tworzyć czy usuwać dynamicznie. Baza jest osobną skalowalną warstwą ale jednocześnie może należeć tylko do jednego mikroserwisu. Teoretycznie jestem sobie w stanie wyobrazić rozwiązanie gdzie przy niewielkich ilościach danych ładujemy snapshot bazy do nowej instancji mikroserwisu i nadganiamy z ostatnimi transakcjami, ale nie wiem czy istnieje coś takiego produkcyjnie.

Te wszystkie rozwiązania podane wyżej (RAC lub inne, Exadata to też architektura RAC) skalują się w trybie multi-master maksymalnie do kilku lokalnych nodów. W Google Spanner piszą o setkach czy tysiącach nodów rozproszonych globalnie. To jest unikalne rozwiązanie możliwe tylko dzięki posiadaniu własnej globalnej infrastruktury sieciowej. Dla porównania Amazon jest daleko w tyle bo wszystkie ich bazy (DynamoDB, Aurora) mają replikację tylko master-slave i tylko w danym Regionie. Zamknięte testy nad multi-master trwają już prawie dwa lata i na razie cisza.

1 użytkowników online, w tym zalogowanych: 0, gości: 1