MariaDB
 sql >> Baza danych >  >> RDS >> MariaDB

Przegląd MariaDB Xpand (dawniej ClustrixDB)

MariaDB Xpand to nowy produkt firmy MariaDB. Wcześniej był znany jako ClustrixDB, który został przejęty we wrześniu 2018 przez MariaDB Corporation.

ClustrixDB nie jest już dostępny jako oddzielna jednostka, ale jest teraz częścią MariaDB Enterprise Server. Obecnie nazywany Xpand, rozszerza MariaDB Enterprise Server o rozproszone przetwarzanie danych i transakcji, przekształcając go w rozproszoną bazę danych SQL zdolną do skalowania do milionów transakcji na sekundę z architekturą typu „shared-nic”. Jednak Xpand to nie wszystko albo nic, ponieważ administratorzy baz danych mogą używać zarówno tabel replikowanych, jak i rozproszonych. Xpand jest dobry do złożonych zapytań i przetwarzania analiz, ponieważ może wykonywać równoległe zapytania w dostępnych węzłach w klastrze.

Zasadniczo Xpand jest architekturą nie współdzieloną i zaprojektowaną jako skalowalna baza danych SQL, zbudowana od podstaw, która pierwotnie mogła działać na zwykłym sprzęcie z automatyczną redystrybucją danych (więc nigdy nie trzeba shardować ). Ma wbudowaną odporność na awarie, dostępną za pomocą prostego interfejsu SQL i obsługę krytycznych funkcji MySQL (replikacja, wyzwalacze, przechowywane procedury itp.). Jego licencja jest dostępna tylko jako zastrzeżona, więc jeśli chcesz skorzystać z tego produktu, musisz najpierw skontaktować się z działem sprzedaży MariaDB, aby uzyskać ważną licencję.

Kiedy używać MariaDB Xpand

Xpand jest przeznaczony do obsługi dużych ilości danych, co pozwala na efektywniejsze skalowanie bazy danych. Oznacza to, że skalowanie klastra odbywa się łatwo i automatycznie przez sam Xpand. Od czasu wydania MariaDB Platform X5, Xpand jest już częścią platformy dostarczanej klientom w ramach rozproszonego rozwiązania SQL. Inteligentny silnik Xpand umożliwia klientom skalowanie wykraczające poza optymalny punkt silnika pamięci masowej InnoDB w zakresie wysokowydajnych mieszanych obciążeń odczytu/zapisu w jednym węźle z opcją dodania skalowania poprzez replikację i zastosowanie wysoce dostępnego, odpornego na awarie rozwiązania rozproszonego dla dużych skaluj obciążenia.

Dzięki Xpand masz elastyczność skalowania na podstawie tabeli. Zacznij od używania Xpand tylko dla jednej tabeli i rozszerzaj użycie, gdy Twoje potrzeby wyrosną poza to, co może obsłużyć pojedynczy węzeł. Zwiększ wykorzystanie rozproszonego SQL, gdy potrzeby Twojego przedsiębiorstwa wykraczają poza replikację lub klastry. Gdy wolumeny danych lub zapytań zwiększą się do punktu, w którym wydajność spada, możesz użyć Xpand do dystrybucji tabel lub całej bazy danych w celu zwiększenia przepustowości i współbieżności. Xpand ma wbudowaną wysoką dostępność i elastyczność, dzięki czemu węzły można dodawać lub usuwać w sposób przejrzysty w razie potrzeby w celu skalowania.

Podobnie jak w przypadku MariaDB ColumnStore, inteligentnego mechanizmu kolumnowego, możliwe są (i zalecane) sprzężenia między silnikami między zreplikowanymi i rozproszonymi tabelami. W przeciwieństwie do innych implementacji Distributed SQL, które dystrybuują całą bazę danych i w związku z tym powodują znaczne obciążenie mniejszych tabel, MariaDB umożliwia łączne użycie InnoDB do replikowanych małych zestawów danych i ogromnych rozproszonych zestawów danych za pośrednictwem Xpand.

Niestety nie ma formalnej dokumentacji dotyczącej stanu zmiany z ClustrixDB na MariaDB Xpand, więc nadal możesz chcieć polegać na https://docs.clustrix.com/ w celu uzyskania dokumentacji dotyczącej działania ClustrixDB. Wiadomo również, że GTID nie jest obsługiwany przez ClustrixDB, chociaż mogło się to zmienić od czasu wydania MariaDB 10.5.

Jak działa MariaDB Xpand?

Wdrożenie przy użyciu MariaDB Xpand wymaga zainstalowania MariaDB Enterprise Servers z zainstalowaną wtyczką Xpand, a następnie uruchomionych obok nich węzłów Xpand. Jest to podobne do konfiguracji konfiguracji replikacji MaxScale i MariaDB Server pod kątem wysokiej dostępności i umieszczenia MaxScale na górze w celu zarządzania połączeniami i przejrzystego przełączania awaryjnego między instancjami frontendowymi Enterprise Server z replikowanymi mniejszymi zestawami danych w InnoDB. Zaleca się również, aby aby uzyskać najlepszą wydajność z Xpand, serwery frontonu i węzły muszą być uruchamiane na osobnych serwerach fizycznych. Zobacz poniżej architekturę topologii MariaDB Xpand z MariaDB, aby dowiedzieć się, jak to działa:

https://mariadb.com/resources/blog/mariadb-adds-xpand-for-distributed-sql /

Aby wyjaśnić dokładniej powyżej, Xpand dzieli pewną liczbę plasterków dla każdej tabeli zbudowanej za pomocą Xpand. Każdy wycinek jest przechowywany w węźle podstawowym, a następnie replikowany do jednego lub większej liczby innych węzłów, aby zapewnić odporność na uszkodzenia. Każdy węzeł Xpand może wykonywać zarówno odczyty, jak i zapisy. Każdy węzeł ma mapę dystrybucji danych.

W przypadku operacji odczytu, większa część zapytania jest przekazywana do Xpand, gdzie zapytanie jest oceniane, a odpowiednie części zapytania są następnie wysyłane do odpowiednich węzłów Xpand. MariaDB Enterprise Server zbiera dane zwrotne z węzłów Xpand, aby wygenerować zestaw wyników.

W przypadku operacji zapisu MariaDB Xpand używa komponentu zwanego „rebalancer”, aby automatycznie i przejrzyście dystrybuować dane w dostępnych węzłach Xpand.

MariaDB Xpand jako rozproszony SQL

Każdy węzeł Xpand może wykonywać zarówno odczyty, jak i zapisy. Gdy zapytanie zostanie odebrane przez MariaDB Enterprise Server, jest ono oceniane przez optymalizator zapytań, a części zapytania są wysyłane do odpowiednich węzłów Xpand. Wyniki są zbierane, a pojedynczy zestaw wyników zwracany do klienta.

MariaDB Xpand wykorzystuje architekturę typu „shared-nic”; pojedynczy węzeł obsługuje każde żądanie, a pamięć i pamięć nie są współdzielone.

MariaDB Xpand HA i tolerancja błędów

MariaDB Xpand jest z założenia odporny na błędy. Xpand utrzymuje dwie repliki wszystkich danych przy użyciu procesu rebalansowania działającego w tle. Xpand może ponieść awarię pojedynczego węzła lub strefy bez utraty danych.

W przypadku awarii węzła dane są ponownie równoważone z pozostałych węzłów, automatycznie naprawiając ochronę danych bez interwencji. W przypadku awarii strefy rebalanser wykonuje tę samą operację między węzłami i pozostałymi strefami.

Gdy uszkodzony węzeł zostanie zastąpiony, moduł rebalansowania ponownie dystrybuuje dane, przywracając MariaDB Xpand do zamierzonej liczby węzłów.

Poziome skalowanie w poziomie za pomocą MariaDB Xpand

MariaDB Xpand jest elastyczny z założenia. Jeśli obciążenie MariaDB Enterprise Server wzrośnie, możesz dodać do wdrożenia dodatkowe serwery, równoważąc obciążenie między nimi za pomocą MariaDB MaxScale. Każdy serwer może łączyć się z węzłami Xpand, aby uzyskać dostęp do danych przechowywanych w tabelach Xpand.

Jeśli obciążenie MariaDB Xpand wzrośnie, możesz skalować w poziomie, dodając nowe węzły. Po dodaniu węzła Xpand do wdrożenia proces ponownego równoważenia powoduje redystrybucję danych z istniejących węzłów. Po zakończeniu węzeł Xpand może teraz obsługiwać zarówno operacje odczytu, jak i zapisu z serwerów MariaDB Enterprise Servers.

Jeśli obciążenie MariaDB Xpand zmniejszy się, możesz zmniejszyć skalę, usuwając węzły. Gdy usuniesz węzeł Xpand z wdrożenia, proces ponownego równoważenia powoduje redystrybucję danych do pozostałych węzłów, zapewniając odporność na błędy.

Co sprawia, że ​​MariaDB Xpand jest skalowalna?

Nie ma wąskich gardeł ani pojedynczych punktów awarii. Wszystkie procesory są wymienione w obsłudze przetwarzania zapytań. Zapytania są równoległe i dystrybuowane w klastrze do odpowiednich danych. Nowe węzły są automatycznie rozpoznawane i włączane do klastra. Obciążenia i dane są automatycznie równoważone we wszystkich węzłach w klastrze. Rachunek relacyjny SQL obejmujący cały klaster i właściwości ACID eliminują złożoność wielowęzłową podczas opracowywania i zarządzania wielowarstwowymi aplikacjami. Wyeliminowano złożoność zwykle wymaganą do skalowania istniejących modeli baz danych w celu obsługi dużych ilości danych. A gdy Twoja baza danych rośnie, po prostu dodawaj węzły.

Istnieje kilka rzeczy, które wpływają na skalowalność i wydajność:

  • Architektura Shared-Nothing, która eliminuje potencjalne wąskie gardła. Porównaj to z architekturami współdzielonego dysku / współdzielonej pamięci podręcznej, które stanowią wąskie gardło, nie skalują się i są trudne w zarządzaniu.
  • Równoległość zapytań, które są dystrybuowane do węzłów z odpowiednimi danymi. Wyniki są tworzone jak najbliżej danych, a następnie kierowane z powrotem do żądającego węzła w celu konsolidacji i zwracane do klienta.

To bardzo różni się od innych systemów, które rutynowo przenoszą duże ilości danych do węzła przetwarzającego zapytanie, a następnie eliminują wszystkie dane, które nie pasują do zapytania (zazwyczaj dużo danych) . Przenosząc tylko kwalifikowane dane przez sieć do żądającego węzła, Xpand znacznie zmniejsza wąskie gardło w ruchu sieciowym. Ponadto w procesie selekcji danych uczestniczy więcej procesorów. Wybierając dane na wielu węzłach równolegle, system generuje wyniki szybciej, niż gdyby wszystkie dane były wybierane przez jeden węzeł, który najpierw musi zebrać wszystkie wymagane dane z drugiego węzły w systemie.

Ponieważ każdy węzeł koncentruje się na określonej partycji i wysyła elementy pracy do innych węzłów, zamiast żądać nieprzetworzonych danych od innych węzłów, pamięć podręczna każdego węzła zawiera więcej danych tego węzła i mniej nadmiarowych danych z innych węzłów. Oznacza to, że współczynniki trafień w pamięci podręcznej będą znacznie wyższe, co znacznie zmniejszy potrzebę wolnego dostępu do dysku.

Wdrażanie MariaDB Xpand

Istnieją dwa oddzielne wdrożenia MariaDB Xpand umożliwiające rozpoczęcie korzystania z MariaDB Xpand. Wdrożenia Xpand składają się z instancji MariaDB Enterprise Server, zwanych serwerami frontonu, z zainstalowaną wtyczką Xpand, a następnie węzły Xpand działają razem z tymi serwerami frontonu. Aby uzyskać najlepszą wydajność, Enterprise Server i węzeł Xpand można zainstalować na osobnych serwerach fizycznych.

  1. Musisz skonfigurować węzeł MariaDB Xpand. Węzły Xpand są konfigurowane we wdrożeniu, aby zapewnić zaplecze pamięci masowej dla serwerów MariaDB Enterprise Server z wtyczką Xpand Storage Engine. Serwery przechowują dane dla tabel Xpand w węzłach Xpand, a nie w lokalnym systemie plików. Instalacja Xpand Node wymaga licencji, która jest obiektem JSON, a możesz ją uzyskać tylko kontaktując się z MariaDB Sales. Proces instalacji nie jest tak szybki, jak tylko jedno polecenie lub kliknięcie, dlatego sugerujemy przejście do ich przewodnika instalacji dla węzła Xpand.
  2. Wdróż serwer frontonu. Jak zauważyłem tutaj po wprowadzonych przez nich zmianach, wygląda na to, że najbardziej zalecanym sposobem korzystania z Xpand jest użycie MariaDB Enterprise Server 10.5. Xpand 

Zgodność sprzętowa MariaDB Xpand

Jeśli interesuje Cię kompatybilność sprzętowa, platforma MariaDB może działać w różnych środowiskach. Dopóki Twoje serwery MariaDB mogą działać lub być hostowane w środowiskach, z których obecnie korzystasz, o ile możesz skonfigurować węzły Xpand wraz z serwerami MariaDB i masz zainstalowane wtyczki Xpand, to z pewnością zadziała. Z ich dokumentacji lista środowisk fizycznych i chmurowych znajduje się poniżej:

  • W siedzibie (w siedzibie)
  • Kolokowane (colo)
  • Prywatna chmura
  • Chmura publiczna
  • Hybrydyzowane

W przypadku architektury sprzętowej warto zauważyć, że od MariaDB Enterprise Server 10.4.10-4 (2019-11-18) MariaDB Enterprise Server obsługuje tylko platformy architektury sprzętowej x86_64.

Wnioski

MariaDB Xpand upraszcza wydajność i rozszerzalność w bardzo wygodny sposób. Najbardziej atrakcyjnym aspektem tego produktu jest to, że możesz również korzystać ze standardowych funkcji SQL MariaDB. Można go osadzić w istniejącym środowisku MariaDB, które może wykorzystać jego funkcje i skalowalność. Chociaż może to być kuszące, wymaga specjalnych licencji i wysokich opłat, abyś mógł korzystać z tego produktu. Jeśli służy to celowi Twojej aplikacji korporacyjnej, warto wypróbować ten MariaDB Xpand.


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Jak EXTRACT() działa w MariaDB

  2. 8 sposobów na dodanie sekund do wartości daty i godziny w MariaDB

  3. Czy na sterownik MariaDB JDBC występuje luka Log4j?

  4. Jak uruchamiać aplikacje PHP 5 z MySQL 8.0 na CentOS 7?

  5. 2 sposoby na zastąpienie podciągu w MariaDB