Skalowanie baz danych

Odpowiedz Nowy wątek
2019-06-15 18:40

Rejestracja: 2 lata temu

Ostatnio: 1 tydzień temu

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?

Pozostało 580 znaków

2019-06-15 19:05
Moderator

Rejestracja: 12 lat temu

Ostatnio: 1 godzina temu

Lokalizacja: Wrocław

1

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


edytowany 2x, ostatnio: Patryk27, 2019-06-15 19:05

Pozostało 580 znaków

2019-06-15 19:37

Rejestracja: 2 lata temu

Ostatnio: 1 tydzień temu

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

Pozostało 580 znaków

2019-06-15 20:00

Rejestracja: 17 lat temu

Ostatnio: 2 godziny temu

Lokalizacja: Kraków

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.


It's easy to hate code you didn't write, without an understanding of the context in which it was written.
edytowany 1x, ostatnio: neves, 2019-06-15 20:02

Pozostało 580 znaków

2019-06-15 21:40

Rejestracja: 3 lata temu

Ostatnio: 1 minuta temu

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ą".

Pozostało 580 znaków

2019-06-18 00:16

Rejestracja: 2 lata temu

Ostatnio: 13 godzin temu

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.

edytowany 1x, ostatnio: ralf, 2019-06-18 00:17

Pozostało 580 znaków

2019-06-18 11:07

Rejestracja: 1 rok temu

Ostatnio: 1 godzina temu

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.

edytowany 2x, ostatnio: Tomek Pycia, 2019-06-18 13:05
Cockroach według mojej wiedzy nie jest na PostgreSQL oparty, jedynie ma z nim kompatybilny driver, czyli tego samego drivera co używasz do Postgresa, możesz użyć do CockroachDB - TurkucPodjadek 2019-06-18 11:13
Cockroach jest oparty na RocksDB - neves 2019-06-18 12:01
"CockroachDB is inspired by Google's Spanner and F1 technologies" - ralf 2019-06-18 12:52

Pozostało 580 znaków

2019-06-18 12:16

Rejestracja: 1 rok temu

Ostatnio: 2 godziny temu

Lokalizacja: Silesia

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


Pytanie brzmi: co znaczy wydajne? I czy potrzebna jest transakcyjnośći i spójność danych. Wszystko zależy od rozwiązywanego problemu. - Tomek Pycia 2019-06-18 13:08
Nie można wykorzystywać relacyjnych baz danych bez wykorzystywania relacji (https://pl.wikipedia.org/wiki/Model_relacyjny). Można wykorzystywać relacyjne bazy danych bez kluczy obcych ;-) - Patryk27 2019-06-18 13:46

Pozostało 580 znaków

2019-06-18 16:12

Rejestracja: 3 lata temu

Ostatnio: 3 godziny temu

0

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

Zależy od problemu. Tam, gdzie nie daje rady baza, to skaluje się bazę. Jak problemem jest aplikacja to skaluje sie aplikację. - Tomek Pycia 2019-06-18 17:15

Pozostało 580 znaków

2019-06-18 21:30

Rejestracja: 5 lat temu

Ostatnio: 2 minuty temu

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 :-)

Pozostało 580 znaków

2019-06-19 22:33

Rejestracja: 2 lata temu

Ostatnio: 13 godzin temu

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) Exadata to nie tylko RAC, nie ma wymogu by na exadacie obowiązkowo stawiać RACa. 2) Od 12c pojawiły się tzw. "flex clusters", w których może być do 64 nodów typu "hub" (połączonych interconnectem i mających dostęp do storage), do nodów "hub" może podpiąć się dużo nodów typu "leaf", więc nie do końca jest tak, że skalowanie jest ogarniczone do "kilku lokalnych nodów". 3) Sensowna replikacja multi-master raczej zakłada, że master zarządza podzbiorem danych (bo inaczej jak rozwiązywać konflikty?). Czy wtedy nie mamy pewnym sensie master-slave?:) - yarel 2019-06-20 20:55
1,2) Tak samo jak mając RAC można postawić tylko jeden node :) ale jaki to ma sens? Jest też różnica w maksimum teoretycznym a praktycznym i nadal twierdze, że jest to max kilka lokalnych nodów. W ogóle RAC to trochę oszukiwany multi-master bo ma jeden wspólny storage co eliminuje geograficzne rozproszenie takiego klastra. 3) multi-master nie zakłada żadnych podzbiorów, każda z baz posiada te same dane i wszystkie są dostępne do zapisu i to właśnie rozwiązywanie konfliktów stanowi trudność takiej architektury - ralf 2019-06-20 22:03
Jak nie potrzebujemy HA, to nie ma sensu iść w RACa (narzut na utrzymanie kalstra). W przypadku 1 instancji korzyścią z exadaty jest wsparcie na poziomie storage. Rozproszenie geograficzne jest w "extended clusters" (50km/100km, ale nie widziałem ciekawego przypadku użycia). Teraz robimy takie rozwiązanie z 2 klastrami (Active-Active) RAC w różnych lokalizacjach i replikacją pomiędzy klastrami, ale tak by uniknąć konfliktów i w razie konieczności móc przełączyć cały ruch aplikacyjny na 1 klaster, ale app instance wie, które dane są jej i nie ma konfliktów do rozwiązywania:) - yarel 2019-06-20 22:45

Pozostało 580 znaków

Odpowiedz

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