For længst forbi er dagene med en-database-passer-alle-tilgangen.
Med stigende krav til hastighed, ydeevne og smidighed opstod der adskillige datalagre, som er beregnet til at løse et bestemt problem. Vi har relationsdatabaser, dokumentlagre, tidsseriedatabaser, søjledatabaser, fuldtekstsøgemaskiner.
Det er ret almindeligt at se flere datalagre arbejde sammen i det samme miljø.
Så hvordan passer MariaDB AX ind i billedet? Hvordan er det sammenlignet med MariaDB TX, og hvilket problem løser det?
I dette blogindlæg vil vi se på MariaDB AX og se, hvorfor du måske vil bruge det.
Hvad er MariaDB AX?
Først og fremmest, så hvad er MariaDB AX?
Det er et kolonnelager, og det gemmer sine data efter ...kolonne! Den er implementeret som en separat motor i MariaDB 10.3-databasen.
Som du måske ved, er MySQL og MariaDB designet til at bruge pluggbare lagermotorer. Hver lagermotor, det være sig InnoDB, Aria, MyRocks, Spider eller andre motorer, er plugins.
På samme måde bruger MariaDB AX ColumnStore-motoren:
MariaDB [(none)]> SHOW ENGINES\G
*************************** 1. row ***************************
Engine: Columnstore
Support: YES
Comment: Columnstore storage engine
Transactions: YES
XA: NO
Savepoints: NODette resulterer i en interessant kombination. SQL-parsingen udføres af MariaDB, så du kan forvente at arbejde med forespørgselssyntaks, som minder meget om det, du er vant til i MariaDB. Dette gør det også nemmere at kombinere adgang til både MariaDB AX og MariaDB TX i samme applikation. Der er ikke behov for specifikke stik eller biblioteker for at forbinde til to datalagre. Alt kan gøres ved hjælp af MySQL eller MariaDB klientbibliotek. Du kan også bruge MaxScale til begge datalagre, hvilket kan hjælpe med at opbygge høj tilgængelighed for MariaDB AX.
Hvorfor skal vi bruge et kolonnedatalager?
Lad os gennemgå en kort introduktion til ideen bag søjleformede datalagre.
Hvad adskiller MariaDB AX fra MariaDB TX?
Den største forskel er, hvordan data er struktureret. I typiske databaser lagres data som rækker.
Id, Product, Price, Code, Warehouse
1, Door, 10, 12334, EU1
2, Window, 9, 9523, EU1
3, Glass, 12, 97643, EU2Som du kan se, har vi tre rækker, der hver indeholder alle data om en produktpost.
Problemet er, at denne måde at gemme data på ikke er rigtig effektiv, når du kun ønsker at få en delmængde af disse data. Lad os sige, at du kun vil have kolonnerne "Produkt" og "Pris" - for at gøre det skal du læse hele rækker, alle data og derefter kassere de unødvendige kolonner. Det er også svært at sortere dataene. Hvis du gerne vil sortere datasættet fra det dyreste til det billigste produkt, skal du læse alt og derefter foretage sorteringen.
Vi ved alle, at databaser bruger indekser til at fremskynde adgangen. Et indeks er struktureret på en måde, så det indeholder indholdet af den indekserede kolonne samt en pegepind til hele rækken (i InnoDB er det den primære nøgle). For eksempel kan et indeks i kolonnen "Produkt", forudsat at "Id" er den primære nøgle, se ud som følger:
Product, Id
Door, 1
Window, 2
Glass, 3Dette fremskynder adgangen til dataene, da der ikke er behov for at læse hele rækken bare for at finde en værdi i kolonnen "Produkt". Når databasen finder den, kan den læse resten af rækken (hvis det er nødvendigt) ved at følge markøren.
I en spaltebutik er tingene anderledes. Data er ikke struktureret som rækker, men som kolonner. Til en vis grad ligner dette indekset. Vores tabel i kolonnedatalageret kan se sådan ud:
Id: 1, 2, 3
Product: Door, Window, Glass
Price: 10, 9, 12
Code: 12334, 9523, 97643
Warehouse: EU1, EU1, EU2I MariaDB AX er kolonner gemt i separate filer, hver indtastning for en given "række" starter med samme forskydning.
Den største fordel her er, at hvis du vil køre en forespørgsel, som kun vil fungere med en delmængde af data, behøver du kun at læse data fra kolonner, der er relevante for forespørgslen.
I vores tidligere eksempel, i stedet for at læse hele datasættet, kan vi bare indlæse data for kolonnerne "Produkt" og "Pris". Det reducerer de data, der skal tilgås på disken, og fremskynder processen.
Hvad der også er vigtigt, lagring af data i kolonner gør dem mindre adskilte, hvilket gør det komprimere bedre. For eksempel har vi i vores "Lager"-kolonne kun to typer poster. Selv i den virkelige verden er det meget sandsynligt, at vi ender med et lille antal varehuse sammenlignet med antallet af produkter. Dette gør kolonnen "Warehouse" til et meget godt mål for komprimering.
Som et resultat af alt dette kan søjleformede datalagre håndtere store datasæt bedre og kan forespørge det på en mere effektiv måde end "standard" OLTP-fokuserede databaser.
Hvorfor skal jeg bruge MariaDB AX?
Diskadgang er en stor flaskehals i databaser. Et søjleformet datalager forbedrer ydeevnen ved at reducere mængden af data, der skal læses fra disken. Den læser kun de data, der er nødvendige for at besvare forespørgslen.
Naturligvis er MariaDB AX ikke den eneste søjleformede databutik derude. Der er mange andre som for eksempel Clickhouse eller Apache HBase.
Sandheden er, at ingen af de andre muligheder understøtter fuld SQL-syntaks, som MySQL gør. De kræver forskellige forbindelser, en anden tilgang til at forespørge dataene, mens MariaDB AX kan forespørges, ligesom du ville forespørge den 'normale' MariaDB.
Hvad der også er vigtigt, da MariaDB AX bruger ColumnStore-motoren, er det helt fint at blande det med andre motorer. Du kan blande og forbinde InnoDB- og ColumnStore-tabeller i den samme forespørgsel uden problemer.
Oven i det vil værktøjer, der følger med MariaDB TX, som MaxScale, fungere fint med MariaDB AX, hvilket gør det nemmere at bygge et integreret, brugervenligt miljø. Så når du kører ClusterControl med MariaDB 10.3 og MaxScale, kan du nemt tilføje MariaDB AX til blandingen, og det vil fungere med andre dele af opsætningen.
MariaDB AX kommer med værktøjer, der er beregnet til at hjælpe med at overføre data fra andre kilder. Hvis du tilfældigvis bruger Kafka eller Spark, er der stik at bruge, når du importerer data fra disse kilder til MariaDB AX.
Derudover, selvom regelmæssig replikering mellem MariaDB TX (InnoDB) og MariaDB AX (ColumnStore) ikke fungerer godt på grund af ColumnStore-begrænsninger (det er altid bedre at lave batch-indsættelser i søjleformede datalagre end enkeltindsættelser, da det gøres ved replikering), er det muligt at bygge en pipeline, som ville bestå af MaxScale konfigureret som binlog-server og Avro CDC-router, MaxScale CDC Data Adapter og MariaDB AX, som vil modtage data fra adapteren næsten i realtid.
Vi håber, at dette blogindlæg vil give dig et indblik i, hvad MariaDB AX er, og hvordan det kan bruges sammen med MariaDB TX-miljøet implementeret og administreret af ClusterControl (download det gratis!).