Dawno minęły czasy podejścia „jedna baza danych dla wszystkich”.
Wraz z rosnącymi wymaganiami dotyczącymi szybkości, wydajności i zwinności pojawiły się liczne magazyny danych, które mają rozwiązać jeden konkretny problem. Mamy relacyjne bazy danych, magazyny dokumentów, bazy danych szeregów czasowych, bazy danych kolumnowe, wyszukiwarki pełnotekstowe.
Często zdarza się, że wiele magazynów danych współpracuje ze sobą w tym samym środowisku.
Jak więc MariaDB AX pasuje do obrazu? Jak wypada w porównaniu z MariaDB TX i jaki problem rozwiązuje?
W tym poście na blogu przyjrzymy się MariaDB AX i zobaczymy, dlaczego warto z niego korzystać.
Co to jest MariaDB AX?
Po pierwsze, czym jest MariaDB AX?
Jest to magazyn kolumnowy i przechowuje swoje dane według ...kolumny! Jest zaimplementowany jako osobny silnik w bazie danych MariaDB 10.3.
Jak być może wiesz, MySQL i MariaDB są zaprojektowane do korzystania z podłączanych silników pamięci masowej. Każdy silnik pamięci masowej, czy to InnoDB, Aria, MyRocks, Spider czy jakiekolwiek inne silniki, są wtyczkami.
W ten sam sposób MariaDB AX wykorzystuje silnik ColumnStore:
MariaDB [(none)]> SHOW ENGINES\G
*************************** 1. row ***************************
Engine: Columnstore
Support: YES
Comment: Columnstore storage engine
Transactions: YES
XA: NO
Savepoints: NODaje to ciekawą kombinację. Analiza SQL jest wykonywana przez MariaDB, dlatego możesz oczekiwać pracy ze składnią zapytań, która jest bardzo podobna do tej, do której przywykłeś w MariaDB. Ułatwia to również łączenie dostępu do MariaDB AX i MariaDB TX w tej samej aplikacji. Do łączenia się z dwoma magazynami danych nie są potrzebne żadne konkretne łączniki ani biblioteki. Wszystko można zrobić za pomocą biblioteki klienckiej MySQL lub MariaDB. Możesz również użyć MaxScale dla obu magazynów danych, co może pomóc w tworzeniu wysokiej dostępności dla MariaDB AX.
Dlaczego powinniśmy używać kolumnowego magazynu danych?
Przejdźmy przez krótkie wprowadzenie do idei kolumnowych magazynów danych.
Co odróżnia MariaDB AX od MariaDB TX?
Główną różnicą jest struktura danych. W typowej bazie danych dane są przechowywane jako wiersze.
Id, Product, Price, Code, Warehouse
1, Door, 10, 12334, EU1
2, Window, 9, 9523, EU1
3, Glass, 12, 97643, EU2Jak widać, mamy trzy wiersze, z których każdy zawiera wszystkie dane dotyczące wpisu produktu.
Problem polega na tym, że ten sposób przechowywania danych nie jest zbyt wydajny, gdy chcesz uzyskać tylko podzbiór tych danych. Powiedzmy, że chcesz uzyskać tylko kolumny „Produkt” i „Cena” – w tym celu musisz przeczytać całe wiersze, wszystkie dane, a następnie odrzucić niepotrzebne kolumny. Trudne jest również sortowanie danych. Jeśli chcesz posortować zbiór danych od najdroższego do najtańszego produktu, musisz przeczytać wszystko, a następnie dokonać sortowania.
Wszyscy wiemy, że bazy danych wykorzystują indeksy do przyspieszenia dostępu. Indeks jest skonstruowany w taki sposób, że zawiera zawartość indeksowanej kolumny, a także wskaźnik do pełnego wiersza (w InnoDB jest to klucz podstawowy). Na przykład indeks w kolumnie „Produkt”, przy założeniu, że „Id” jest kluczem podstawowym, może wyglądać następująco:
Product, Id
Door, 1
Window, 2
Glass, 3Przyspiesza to dostęp do danych, ponieważ nie trzeba czytać całego wiersza tylko po to, aby znaleźć wartość w kolumnie „Produkt”. Gdy baza danych ją znajdzie, może odczytać resztę wiersza (w razie potrzeby), podążając za wskaźnikiem.
W sklepie kolumnowym rzeczy mają się inaczej. Dane mają strukturę nie wierszy, ale kolumn. W pewnym stopniu jest to podobne do indeksu. Nasza tabela w kolumnowym magazynie danych może wyglądać tak:
Id: 1, 2, 3
Product: Door, Window, Glass
Price: 10, 9, 12
Code: 12334, 9523, 97643
Warehouse: EU1, EU1, EU2W MariaDB AX kolumny są przechowywane w osobnych plikach, a każdy wpis dla danego „wiersza” zaczyna się od tego samego przesunięcia.
Główną zaletą jest to, że jeśli chcesz uruchomić zapytanie, które będzie działać tylko z podzbiorem danych, musisz tylko odczytać dane z kolumn, które są istotne dla zapytania.
W naszym przykładzie wcześniej, zamiast czytać cały zbiór danych, możemy po prostu załadować dane dla kolumn „Produkt” i „Cena”. Zmniejsza ilość danych potrzebnych do uzyskania dostępu na dysku i przyspiesza proces.
Co również ważne, przechowywanie danych w kolumnach sprawia, że są mniej wyraźne, co sprawia, że kompresja jest lepsza. Na przykład w naszej kolumnie „Magazyn” mamy tylko dwa rodzaje wpisów. Nawet w realnym scenariuszu jest bardzo prawdopodobne, że skończymy z niewielką liczbą magazynów w porównaniu do liczby produktów. To sprawia, że kolumna „Magazyn” jest bardzo dobrym celem kompresji.
W rezultacie kolumnowe magazyny danych mogą lepiej obsługiwać duże zbiory danych i mogą wysyłać do nich zapytania w bardziej wydajny sposób niż „standardowe” bazy danych skoncentrowane na OLTP.
Dlaczego powinienem używać MariaDB AX?
Dostęp do dysku jest głównym wąskim gardłem w bazach danych. Kolumnowy magazyn danych poprawia wydajność, zmniejszając ilość danych, które należy odczytać z dysku. Odczytuje tylko dane niezbędne do odpowiedzi na zapytanie.
Oczywiście MariaDB AX nie jest jedynym kolumnowym magazynem danych. Istnieje wiele innych, takich jak na przykład Clickhouse lub Apache HBase.
Prawda jest taka, że żadna z pozostałych opcji nie obsługuje pełnej składni SQL, którą robi MySQL. Wymagają różnych łączników, innego podejścia do zapytań o dane, podczas gdy zapytania do MariaDB AX można wykonywać tak, jak zapytania do „normalnej” bazy danych MariaDB.
Co również ważne, biorąc pod uwagę, że MariaDB AX wykorzystuje silnik ColumnStore, doskonale jest mieszać go z innymi silnikami. Możesz mieszać i łączyć tabele InnoDB i ColumnStore w tym samym zapytaniu bez żadnego problemu.
Ponadto narzędzia dostarczane z MariaDB TX, takie jak MaxScale, będą dobrze współpracować z MariaDB AX, ułatwiając tworzenie zintegrowanego, łatwego w użyciu środowiska. Jeśli więc używasz ClusterControl z MariaDB 10.3 i MaxScale, możesz łatwo dodać MariaDB AX do miksu i będzie działać z innymi częściami konfiguracji.
MariaDB AX jest dostarczana z narzędziami, które mają pomóc w przenoszeniu danych z innych źródeł. Jeśli zdarzy ci się używać Kafki lub Sparka, istnieją łączniki, których możesz użyć podczas importowania danych z tych źródeł do MariaDB AX.
Ponadto, mimo że zwykła replikacja między MariaDB TX (InnoDB) i MariaDB AX (ColumnStore) nie działa dobrze ze względu na ograniczenia ColumnStore (zawsze lepiej jest wykonywać wstawianie partii w kolumnowych magazynach danych niż pojedyncze wstawianie, ponieważ odbywa się to podczas replikacji), jest to możliwe jest zbudowanie potoku, który składałby się z MaxScale skonfigurowanego jako serwer binlog i routera Avro CDC, MaxScale CDC Data Adapter i MariaDB AX, który będzie odbierał dane z adaptera niemal w czasie rzeczywistym.
Mamy nadzieję, że ten wpis na blogu da ci wgląd w to, czym jest MariaDB AX i jak można go wykorzystać wraz ze środowiskiem MariaDB TX wdrożonym i zarządzanym przez ClusterControl (pobierz go za darmo!).
