Analys med MariaDB AX - tThe Open Source Columnar Datastore

Länge borta är dagarna med en databas-passar-alla-metoden.

Med ökande krav på hastighet, prestanda och smidighet uppstod ett flertal datalager, som är avsedda att lösa ett särskilt problem. Vi har relationsdatabaser, dokumentarkiv, tidsseriedatabaser, kolumnära databaser, fulltextsökmotorer.

Det är ganska vanligt att se flera databutiker arbeta tillsammans i samma miljö.

Så hur passar MariaDB AX in i bilden? Hur är det jämfört med MariaDB TX och vilket problem löser det?

I det här blogginlägget kommer vi att ta en titt på MariaDB AX och se varför du kanske vill använda den.

Vad är MariaDB AX?

Först till kvarn, så vad är MariaDB AX?

Det är ett kolumnlager, och det lagrar sina data efter ...kolumn! Den är implementerad som en separat motor i MariaDB 10.3-databasen.

Som du kanske vet är MySQL och MariaDB designade för att använda pluggbara lagringsmotorer. Varje lagringsmotor, vare sig det är InnoDB, Aria, MyRocks, Spider eller andra motorer, är plugins.

På samma sätt använder MariaDB AX ColumnStore-motorn:

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

Detta resulterar i en intressant kombination. SQL-parsningen görs av MariaDB, så du kan förvänta dig att arbeta med frågesyntax som är väldigt lik vad du är van vid i MariaDB. Detta gör det också lättare att kombinera åtkomst till både MariaDB AX och MariaDB TX i samma applikation. Inget behov av några specifika kontakter eller bibliotek för att ansluta till två databutiker. Allt kan göras med MySQL eller MariaDB klientbibliotek. Du kan också använda MaxScale för båda databutikerna, vilket kan bidra till att bygga hög tillgänglighet för MariaDB AX.

Varför ska vi använda ett kolumndatalager?

Låt oss gå igenom en kort introduktion till idén bakom kolumnära databutiker.

Vad skiljer MariaDB AX från MariaDB TX?

Den största skillnaden är hur informationen är uppbyggd. I en typisk databas lagras data som rader.

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

Som du kan se har vi tre rader som var och en innehåller all information om en produktpost.

Problemet är att det här sättet att lagra data inte är riktigt effektivt när du bara vill få en delmängd av denna data. Låt oss säga att du bara vill ha kolumnerna "Produkt" och "Pris" - för att göra det måste du läsa hela rader, all data och sedan kassera de onödiga kolumnerna. Det är också knepigt att sortera uppgifterna. Om du vill sortera datamängden från den dyraste till den billigaste produkten måste du läsa allt och sedan göra sorteringen.

Vi vet alla att databaser använder index för att påskynda åtkomsten. Ett index är strukturerat på ett sätt att det innehåller innehållet i den indexerade kolumnen samt en pekare till hela raden (i InnoDB är det den primära nyckeln). Till exempel kan ett index i kolumnen "Produkt", förutsatt att "Id" är den primära nyckeln, se ut så här:

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

Detta gör åtkomsten till data snabbare eftersom det inte finns något behov av att läsa hela raden bara för att hitta ett värde i kolumnen "Produkt". När databasen väl hittar den kan den läsa resten av raden (om det behövs) genom att följa pekaren.

I en kolumnbutik är det annorlunda. Data struktureras inte som rader utan som kolumner. Till viss del liknar detta indexet. Vår tabell i kolumnära datalager kan se ut så här:

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

I MariaDB AX lagras kolumner i separata filer, varje post för en given "rad" börjar med samma offset.

Den största fördelen här är att om du vill köra en fråga som bara fungerar med en delmängd av data, behöver du bara läsa data från kolumner som är relevanta för frågan.

I vårt exempel tidigare, istället för att läsa hela datamängden, kan vi bara ladda data för kolumnerna "Produkt" och "Pris". Det minskar den data som behövs för att komma åt på disken och påskyndar processen.

Vad som också är viktigt, att lagra data i kolumner gör dem mindre distinkta vilket gör att de komprimeras bättre. Till exempel, i kolumnen "Lager" har vi bara två typer av poster. Även i verkliga scenariot är det mycket troligt att vi kommer att få ett litet antal lager jämfört med antalet produkter. Detta gör kolumnen "Warehouse" till ett mycket bra mål för komprimering.

Som ett resultat av allt detta kan kolumnära datalager hantera stora datamängder bättre och kan söka efter det på ett mer effektivt sätt än "standard" OLTP-fokuserade databaser.

Varför ska jag använda MariaDB AX?

Diskåtkomst är en stor flaskhals i databaser. Ett kolumnärt datalager förbättrar prestandan genom att minska mängden data som behöver läsas från disken. Den läser endast de data som behövs för att svara på frågan.

Naturligtvis är MariaDB AX inte den enda kolumnära databutiken där ute. Det finns många andra som till exempel Clickhouse eller Apache HBase.

Sanningen är att inget av de andra alternativen stöder full SQL-syntax som MySQL gör. De kräver olika kopplingar, olika tillvägagångssätt för att fråga data medan MariaDB AX kan frågas precis som du skulle fråga den "normala" MariaDB.

Vad som också är viktigt, med tanke på att MariaDB AX använder ColumnStore-motorn, är det helt okej att blanda den med andra motorer. Du kan blanda och sammanfoga InnoDB- och ColumnStore-tabeller i samma fråga utan problem.

Utöver det kommer verktyg som kommer med MariaDB TX, som MaxScale, att fungera bra med MariaDB AX vilket gör det lättare att bygga en integrerad, lättanvänd miljö. Så när du kör ClusterControl med MariaDB 10.3 och MaxScale kan du enkelt lägga till MariaDB AX i mixen och det kommer att fungera med andra delar av installationen.

MariaDB AX kommer med verktyg som är avsedda att hjälpa till med att överföra data från andra källor. Om du råkar använda Kafka eller Spark finns det kontakter att använda när du importerar data från dessa källor till MariaDB AX.

Dessutom, även om vanlig replikering mellan MariaDB TX (InnoDB) och MariaDB AX (ColumnStore) inte fungerar bra på grund av ColumnStore-begränsningar (det är alltid bättre att göra batchinfogningar i kolumnära datalagrar än enstaka infogar, eftersom det görs vid replikering), är det möjligt att bygga en pipeline som skulle bestå av MaxScale konfigurerad som binlog-server och Avro CDC-router, MaxScale CDC Data Adapter och MariaDB AX, som kommer att ta emot data från adaptern nästan i realtid.

Vi hoppas att det här blogginlägget kommer att ge dig lite insikt i vad MariaDB AX är och hur det kan användas tillsammans med MariaDB TX-miljön som distribueras och hanteras av ClusterControl (ladda ner det gratis!).