Analytics met MariaDB AX - tThe Open Source Columnar Datastore

De dagen van de one-database-fits-all-aanpak zijn allang voorbij.

Met toenemende eisen aan snelheid, prestaties en wendbaarheid, ontstonden er talloze datastores, die bedoeld zijn om een bepaald probleem op te lossen. We hebben relationele databases, documentopslag, tijdreeksdatabases, kolomdatabases, full-text zoekmachines.

Het is vrij gebruikelijk om meerdere datastores samen te zien werken in dezelfde omgeving.

Dus hoe past MariaDB AX in het plaatje? Hoe verhoudt het zich tot MariaDB TX en welk probleem lost het op?

In deze blogpost zullen we MariaDB AX bekijken en zien waarom je het misschien wilt gebruiken.

Wat is MariaDB AX?

First things first, dus wat is MariaDB AX?

Het is een kolomarchief en het slaat zijn gegevens op per ...kolom! Het is geïmplementeerd als een aparte engine in de MariaDB 10.3-database.

Zoals u wellicht weet, zijn MySQL en MariaDB ontworpen om pluggable storage-engines te gebruiken. Elke storage-engine, of het nu InnoDB, Aria, MyRocks, Spider of andere engines zijn, zijn plug-ins.

Op dezelfde manier gebruikt MariaDB AX de ColumnStore-engine:

MariaDB [(none)]> SHOW ENGINES\G
*************************** 1. row ***************************
      Engine: Columnstore
     Support: YES
     Comment: Columnstore storage engine
Transactions: YES
          XA: NO
  Savepoints: NO

Dit resulteert in een interessante combinatie. De SQL-parsing wordt gedaan door MariaDB, dus u kunt verwachten dat u werkt met querysyntaxis die erg lijkt op wat u gewend bent in MariaDB. Dit maakt het ook gemakkelijker om toegang tot zowel MariaDB AX als MariaDB TX in dezelfde applicatie te combineren. Er zijn geen specifieke connectoren of bibliotheken nodig om verbinding te maken met twee datastores. Alles kan worden gedaan met behulp van MySQL of MariaDB-clientbibliotheek. U kunt MaxScale ook gebruiken voor beide datastores, wat kan helpen om een hoge beschikbaarheid voor MariaDB AX op te bouwen.

Waarom zouden we een zuilvormige datastore gebruiken?

Laten we een korte inleiding geven over het idee achter zuilvormige datastores.

Wat maakt MariaDB AX anders dan MariaDB TX?

Het belangrijkste verschil is hoe de gegevens zijn gestructureerd. In typische databases worden gegevens opgeslagen als rijen.

Id, Product, Price, Code, Warehouse
1, Door, 10, 12334, EU1
2, Window, 9, 9523, EU1
3, Glass, 12, 97643, EU2

Zoals u kunt zien, hebben we drie rijen, die elk alle gegevens over een productinvoer bevatten.

Het probleem is dat deze manier om gegevens op te slaan niet echt efficiënt is als je slechts een subset van deze gegevens wilt hebben. Laten we zeggen dat u alleen de kolommen "Product" en "Prijs" wilt krijgen - om dat te doen, moet u hele rijen lezen, alle gegevens en vervolgens de onnodige kolommen weggooien. Het is ook lastig om de gegevens te sorteren. Als u de dataset wilt sorteren van het duurste naar het goedkoopste product, moet u alles lezen en vervolgens sorteren.

We weten allemaal dat databases indexen gebruiken om de toegang te versnellen. Een index is zo gestructureerd dat het de inhoud van de geïndexeerde kolom bevat, evenals een verwijzing naar de volledige rij (in InnoDB is dat de primaire sleutel). Een index in de kolom 'Product', ervan uitgaande dat 'Id' de primaire sleutel is, kan er bijvoorbeeld als volgt uitzien:

Product, Id
Door, 1
Window, 2
Glass, 3

Dit versnelt de toegang tot de gegevens, omdat het niet nodig is om de volledige rij te lezen om een waarde in de kolom "Product" te vinden. Zodra de database het heeft gevonden, kan het de rest van de rij lezen (indien nodig) door de aanwijzer te volgen.

In een column store zijn de dingen anders. Gegevens zijn niet gestructureerd als rijen, maar als kolommen. Tot op zekere hoogte is dit vergelijkbaar met de index. Onze tabel in kolomvormige datastore kan er als volgt uitzien:

Id: 1, 2, 3
Product: Door, Window, Glass
Price: 10, 9, 12
Code: 12334, 9523, 97643
Warehouse: EU1, EU1, EU2

In MariaDB AX worden kolommen opgeslagen in afzonderlijke bestanden, elk item voor een bepaalde "rij" begint met dezelfde offset.

Het belangrijkste voordeel hiervan is dat als u een query wilt uitvoeren die met slechts een subset van gegevens werkt, u alleen gegevens hoeft te lezen uit kolommen die relevant zijn voor de query.

In ons eerder voorbeeld kunnen we, in plaats van de hele dataset te lezen, gewoon gegevens laden voor de kolommen 'Product' en 'Prijs'. Het vermindert de gegevens die nodig zijn om toegang te krijgen op schijf en versnelt het proces.

Wat ook belangrijk is, is dat het opslaan van gegevens in kolommen ze minder duidelijk maakt, waardoor het beter wordt gecomprimeerd. In onze kolom "Magazijn" hebben we bijvoorbeeld slechts twee soorten boekingen. Zelfs in het echte wereldscenario is het zeer waarschijnlijk dat we zullen eindigen met een klein aantal magazijnen in vergelijking met het aantal producten. Dit maakt de kolom "Magazijn" een zeer goed doel voor compressie.

Als gevolg van dit alles kunnen kolomvormige datastores grote datasets beter aan en kunnen ze deze op een efficiëntere manier opvragen dan "standaard" OLTP-gerichte databases.

Waarom zou ik MariaDB AX gebruiken?

Schijftoegang is een groot knelpunt in databases. Een kolomvormig gegevensarchief verbetert de prestaties door de hoeveelheid gegevens die van schijf moet worden gelezen te verminderen. Het leest alleen de gegevens die nodig zijn om de vraag te beantwoorden.

MariaDB AX is natuurlijk niet de enige zuilvormige datastore die er is. Er zijn er nog veel meer, zoals Clickhouse of Apache HBase.

De waarheid is dat geen van de andere opties de volledige SQL-syntaxis ondersteunt die MySQL doet. Ze vereisen verschillende connectoren, een andere benadering voor het opvragen van de gegevens, terwijl MariaDB AX kan worden opgevraagd net zoals u de 'normale' MariaDB zou opvragen.

Wat ook belangrijk is, aangezien MariaDB AX de ColumnStore-engine gebruikt, is het prima om het met andere engines te combineren. U kunt zonder enig probleem InnoDB- en ColumnStore-tabellen combineren en samenvoegen in dezelfde query.

Bovendien werken tools die bij MariaDB TX worden geleverd, zoals MaxScale, prima met MariaDB AX, waardoor het gemakkelijker wordt om een geïntegreerde, gebruiksvriendelijke omgeving te bouwen. Dus als u ClusterControl met MariaDB 10.3 en MaxScale gebruikt, kunt u MariaDB AX eenvoudig aan de mix toevoegen en werkt het met andere delen van de installatie.

MariaDB AX wordt geleverd met tools die bedoeld zijn om te helpen bij het overzetten van de gegevens uit andere bronnen. Als u Kafka of Spark gebruikt, zijn er connectoren die u kunt gebruiken bij het importeren van gegevens uit die bronnen in MariaDB AX.

Bovendien, hoewel reguliere replicatie tussen MariaDB TX (InnoDB) en MariaDB AX (ColumnStore) niet goed presteert vanwege ColumnStore-beperkingen (het is altijd beter om batch-inserts in kolomvormige datastores te doen dan enkele inserts, zoals bij replicatie), is het mogelijk om een pijplijn te bouwen die zou bestaan uit MaxScale geconfigureerd als binlog-server en Avro CDC-router, MaxScale CDC-gegevensadapter en MariaDB AX, die bijna in realtime gegevens van de adapter zullen ontvangen.

We hopen dat deze blogpost je enig inzicht geeft in wat MariaDB AX is en hoe het kan worden gebruikt naast de MariaDB TX-omgeving die wordt geïmplementeerd en beheerd door ClusterControl (download het gratis!).