Ten artykuł pojawił się po raz pierwszy w InfoWorld . Jest przedrukowywany za zgodą. © IDG Communications, Inc., 2020. Wszelkie prawa zastrzeżone Jak MariaDB osiąga globalną skalę dzięki Xpand. Xpand jest teraz dostępny w MariaDB SkySQL, dodając rozproszony SQL w celu zapewnienia skalowalności i elastyczności w chmurze.
W miarę wzrostu potrzeb w zakresie informacji i przetwarzania, problemy, takie jak wydajność i odporność, wymusiły nowe rozwiązania. Bazy danych muszą zachowywać zgodność i spójność z ACID, zapewniać wysoką dostępność i wysoką wydajność oraz obsługiwać ogromne obciążenia bez obciążania zasobów. Sharding zaoferował rozwiązanie, ale dla wielu firm sharding osiągnął swoje granice ze względu na swoją złożoność i wymagania dotyczące zasobów. Lepszym rozwiązaniem jest rozproszony SQL.
W implementacji rozproszonego SQL baza danych jest rozproszona w wielu systemach fizycznych, dostarczając transakcje na globalnie skalowalnym poziomie. MariaDB Platform X5, główne wydanie, które obejmuje uaktualnienia wszystkich aspektów platformy MariaDB, zapewnia rozproszony SQL i ogromną skalowalność dzięki dodaniu nowego inteligentnego silnika pamięci masowej o nazwie Xpand. Dzięki architekturze współdzielonej niczego, w pełni rozproszonym transakcjom ACID i silnej spójności, Xpand umożliwia skalowanie do milionów transakcji na sekundę.
Zoptymalizowane, podłączane inteligentne silniki
MariaDB Enterprise Server zaprojektowano tak, aby korzystał z podłączanych silników pamięci masowej (takich jak Xpand) w celu optymalizacji pod kątem określonych obciążeń z poziomu jednej platformy. Do obsługi określonych obciążeń nie są potrzebne specjalistyczne bazy danych. MariaDB Xpand, nasz inteligentny silnik do rozproszonego SQL, to najnowszy dodatek do naszej oferty. Xpand dodaje masowo skalowalne możliwości transakcyjne rozproszone do opcji oferowanych przez nasze inne silniki. Nasze inne podłączane silniki zapewniają optymalizację pod kątem obciążeń analitycznych (kolumnowych), z dużym obciążeniem odczytem i zapisem. Możesz mieszać i dopasowywać zreplikowane, rozproszone i kolumnowe tabele, aby zoptymalizować każdą bazę danych pod kątem konkretnych wymagań.
Dodanie MariaDB Xpand umożliwia klientom korporacyjnym uzyskanie wszystkich korzyści płynących z rozproszonego SQL — szybkości, dostępności i skalowalności — przy jednoczesnym zachowaniu zalet MariaDB, do których są przyzwyczajeni.
Przyjrzyjmy się na wysokim poziomie, jak MariaDB Xpand zapewnia rozproszony SQL.
Rozprowadzanie SQL do indeksów
Xpand zapewnia rozproszony SQL poprzez dzielenie, replikację i dystrybucję danych między węzłami. Co to znaczy? Użyjemy bardzo prostego przykładu z jedną tabelą i trzema węzłami, aby zademonstrować koncepcje. W tym przykładzie nie pokazano, że wszystkie plasterki są replikowane.
Na rysunku 1 powyżej mamy tabelę z dwoma indeksami. Tabela ma kilka dat i mamy indeks w kolumnie drugiej, a drugi w kolumnie trzeciej i pierwszej. Indeksy są w pewnym sensie tabelami. Są podzbiorami tabeli. Klucz podstawowy to id , pierwszy indeks w tabeli. To właśnie będzie używane do mieszania i rozmieszczania danych tabeli po bazie danych.
Teraz dodajemy pojęcie plastrów . Plastry to zasadniczo poziome przegrody stołu. W naszym stole mamy pięć rzędów. Na rysunku 2 tabela została podzielona i rozłożona. Węzeł #1 ma dwa wiersze. Węzeł #2 ma dwa wiersze, a węzeł #3 ma jeden wiersz. Celem jest, aby dane były rozłożone tak równomiernie, jak to możliwe w węzłach.
indeksy zostały również pokrojone i rozprowadzone. Jest to kluczowa różnica między Xpand a innymi rozwiązaniami rozproszonymi. Zazwyczaj rozproszone bazy danych mają indeksy lokalne, więc każdy węzeł ma indeks własnych danych. W Xpand indeksy są dystrybuowane i przechowywane niezależnie od tabeli. Eliminuje to konieczność wysyłania zapytania do wszystkich węzłów (scatter/gather). W powyższym przykładzie Węzeł #1 zawiera wiersze 2 i 4 tabeli, a także zawiera indeksy dla wierszy 32 i 35 oraz wierszy April i March. Tabela i indeksy są niezależnie dzielone, dystrybuowane i replikowane w węzłach.
Aparat zapytań używa indeksów rozproszonych do określenia, gdzie znaleźć dane. Wyszukuje tylko potrzebne partycje indeksu, a następnie wysyła zapytania tylko do lokalizacji, w których znajdują się potrzebne dane. Wszystkie zapytania są dystrybuowane. Odbywają się równolegle i równolegle. To, dokąd się udają, zależy wyłącznie od danych i tego, co jest potrzebne do rozwiązania zapytania.
Wszystkie plastry są replikowane co najmniej dwukrotnie. Dla każdego wycinka istnieją repliki znajdujące się w innych węzłach. Domyślnie będą trzy kopie tych danych – wycinek i dwie repliki. Każda kopia będzie znajdować się w innym węźle, a jeśli działasz w wielu strefach dostępności, kopie te również będą znajdować się w różnych strefach dostępności.
Obsługa odczytu i zapisu
Weźmy inny przykład. Na rysunku 3 mamy pięć wystąpień MariaDB Enterprise Server z Xpand (węzły). Jest tabela do przechowywania profili klientów. Plasterek z profilem Shane'a znajduje się na węźle nr 1, a kopie na węźle nr 3 i węźle nr 5. Zapytania mogą przychodzić na dowolnym węźle i będą przetwarzane różnie w zależności od tego, czy są odczytywane, czy zapisywane.
Zapisy są dokonywane synchronicznie we wszystkich kopiach w ramach transakcji rozproszonej. Za każdym razem, gdy aktualizuję swój profil „Shane”, ponieważ zmieniłem adres e-mail lub adres, te wpisy trafiają do wszystkich kopii jednocześnie w ramach transakcji. To zapewnia silną spójność.
Na rysunku 3 instrukcja UPDATE trafiła do węzła 2. W Węźle 2 nie ma nic dotyczącego mojego profilu, ale Węzeł 2 wie, gdzie jest mój profil i wysyła aktualizacje do Węzła #1, Węzła #3 i Węzła #5, a następnie zatwierdza tę transakcję i wraca z powrotem do aplikacji.
Odczyty są obsługiwane inaczej. Na diagramie wycinek z moim profilem znajduje się na węźle nr 1 z kopiami na węźle nr 3 i węźle nr 5. To sprawia, że Węzeł #1 jest repliką rankingu. Każdy wycinek ma replikę rankingu, o której można powiedzieć, że jest węzłem, który „posiada” dane. Domyślnie, bez względu na to, w którym węźle pojawia się odczyt, zawsze trafia on do repliki rankingu, więc każdy SELECT, który do mnie trafia, trafi do węzła #1.
Zapewnienie elastyczności
Rozproszone bazy danych, takie jak Xpand, ciągle się zmieniają i ewoluują w zależności od danych w aplikacji. Proces rebalansowania odpowiada za dostosowanie dystrybucji danych do bieżących potrzeb oraz utrzymanie optymalnego rozkładu wycinków między węzłami. Istnieją trzy ogólne scenariusze, które wymagają redystrybucji:dodawanie węzłów, usuwanie węzłów i zapobieganie nierównomiernym obciążeniom lub „gorącym punktom”.
Załóżmy na przykład, że działamy z trzema węzłami, ale ruch znajduje się w zwiększeniu i musimy skalować – dodajemy czwarty węzeł do obsługi ruchu. Węzeł #4 jest pusty, gdy dodamy go, jak pokazano na rysunku 4. Rebalanser automatycznie przesuwa plasterki i repliki, aby wykorzystać węzeł #4, jak pokazano na rysunku 5.
Jeśli Node #4 ulegnie awarii, rebalanser automatycznie wraca do pracy; tym razem odtwarzając wycinki z ich replik. Żadne dane nie zostaną utracone. Repliki są również odtwarzane w celu zastąpienia tych, które znajdowały się w węźle nr 4, więc wszystkie wycinki ponownie mają repliki w innych węzłach, aby zapewnić wysoką dostępność.
Rysunek 6. Jeśli węzeł ulegnie awarii, Xpand rebalancer odtwarza wycinki i repliki, które znajdowały się w uszkodzonym węźle, na podstawie danych repliki w innych węzłach.
Zrównoważenie obciążenia
Oprócz skalowania w poziomie i wysokiej dostępności, rebalanser łagodzi nierówny rozkład obciążenia — albo gorące punkty, albo niedostateczne wykorzystanie. Nawet jeśli dane są dystrybuowane losowo przy użyciu doskonałego algorytmu mieszającego, mogą wystąpić gorące punkty. Na przykład może się zdarzyć, że 10 produktów sprzedawanych w tym miesiącu znajdzie się na węźle #1. Dane są równomiernie rozłożone, ale obciążenie nie jest (rysunek 7). W tego typu scenariuszu moduł rebalansujący dokona redystrybucji wycinków, aby zrównoważyć wykorzystanie zasobów (rysunek 8).
Rysunek 7. Xpand równomiernie rozłożył dane, ale obciążenie pracą jest nierównomierne. Węzeł 1 ma znacznie większe obciążenie niż pozostałe trzy węzły.
Rys. 8. Xpand rebalancer redystrybuuje wycinki danych w celu zrównoważenia obciążenia między węzłami.
Skalowalność, szybkość, dostępność, równowaga
Potrzeby w zakresie informacji i przetwarzania będą nadal rosły. To jest dane. MariaDB Xpand zapewnia spójne, zgodne z ACID rozwiązanie skalowania dla przedsiębiorstw z wymaganiami, których nie można spełnić za pomocą innych alternatyw, takich jak replikacja i sharding.
Rozproszony SQL zapewnia skalowalność, a MariaDB Xpand zapewnia elastyczność wyboru wymaganej skalowalności. Dystrybuuj jedną tabelę lub wiele tabel, a nawet całą bazę danych, wybór należy do Ciebie. Wydajność operacyjną można łatwo dostosować do zmieniających się wymagań w zakresie obciążenia w dowolnym momencie. Nigdy nie musisz mieć nadmiaru alokacji.
Xpand chroni również w przejrzysty sposób przed nierównomiernym wykorzystaniem zasobów, dynamicznie redystrybuując dane w celu zrównoważenia obciążenia między węzłami i zapobiegania gorącym punktom. Programiści nie muszą martwić się skalowalnością i wydajnością. Xpand jest elastyczny. Xpand zapewnia również nadmiarowość i wysoką dostępność. Dane są dzielone, replikowane i dystrybuowane w węzłach, dzięki czemu dane są chronione, a nadmiarowość jest zachowana w przypadku awarii sprzętu.
A dzięki architekturze MariaDB Twoje rozproszone stoły będą dobrze grać – w tym JOIN między silnikami – z innymi Twoimi stołami MariaDB. Utwórz potrzebne rozwiązanie bazodanowe, mieszając i dopasowując zreplikowane, rozproszone lub kolumnowe tabele w jednej bazie danych na platformie MariaDB.
