MariaDB Server blev oprindeligt afledt af MySQL og har derfor arvet sin pluggbare storage engine-arkitektur. Forskellige lagermotorer har forskellige egenskaber med hensyn til ydeevne, men også funktioner og muligheder. Dette giver brugerne mulighed for at vælge det rigtige værktøj til opgaven i stedet for at bruge den samme storage-motor, uanset hvad formålet med dataene er, hvilke krav der er til datalagring og hvordan dataene skal tilgås. I dette blogindlæg vil vi gerne se på de tilgængelige muligheder i MariaDB og diskutere potentielle use cases for de forskellige tilgængelige storage-motorer.
Hvad er en Storage Engine?
Lad os dog først se på, hvad lagermotoren er? MariaDB består af flere lag, der fungerer sammen. SQL parses af en af dem, hvorefter MariaDB rækker ud efter data ved hjælp af en fælles API. Under hætten er der en lagermotor, der indeholder dataene, og den reagerer på anmodninger om data, udtrækker dataene og gør dem tilgængelige for MariaDB.
Kort sagt, MariaDB sender en anmodning om en række, og det er helt op til lagermaskinen at hente den og sende den tilbage. MariaDB er ligeglad med præcis, hvordan rækken er gemt, eller hvordan den skal hentes, det er helt op til implementeringen i storage-motoren. Lagermotorer kan også implementere forskellige funktioner. Transaktioner håndteres også udelukkende på lagermotorens side. Det er derfor, nogle af supporttransaktionerne og nogle ikke gør. Med denne arkitektur er det muligt at skrive forskellige lagringsmotorer, dedikeret til at løse forskellige problemer.
Lagringsmotorer i MariaDB Server
MariaDB leveres med et sæt lagringsmotorer. Du kan kontrollere, hvilke der er tilgængelige ved hjælp af en simpel kommando:
MariaDB [(none)]> SHOW STORAGE ENGINES;
+--------------------+---------+-------------------------------------------------------------------------------------------------+--------------+------+------------+
| Engine | Support | Comment | Transactions | XA | Savepoints |
+--------------------+---------+-------------------------------------------------------------------------------------------------+--------------+------+------------+
| MRG_MyISAM | YES | Collection of identical MyISAM tables | NO | NO | NO |
| CSV | YES | Stores tables as CSV files | NO | NO | NO |
| Aria | YES | Crash-safe tables with MyISAM heritage. Used for internal temporary tables and privilege tables | NO | NO | NO |
| SEQUENCE | YES | Generated tables filled with sequential values | YES | NO | YES |
| MEMORY | YES | Hash based, stored in memory, useful for temporary tables | NO | NO | NO |
| MyISAM | YES | Non-transactional engine with good performance and small data footprint | NO | NO | NO |
| PERFORMANCE_SCHEMA | YES | Performance Schema | NO | NO | NO |
| InnoDB | DEFAULT | Supports transactions, row-level locking, foreign keys and encryption for tables | YES | YES | YES |
+--------------------+---------+-------------------------------------------------------------------------------------------------+--------------+------+------------+
8 rows in set (0.000 sec)
Som du kan se, er der mange af dem, vi vil dække de vigtigste.
InnoDB
InnoDB er naturligvis lagringsmaskinen. Transaktionelle, bygget til at håndtere OLTP-trafik, kan give rigtig god ydeevne. Det er standardmotoren, der bruges i MariaDB, og medmindre du ved, hvad du laver, vil du sandsynligvis holde fast i den til din database.
MyISAM
MyISAM er en af de "originale" lagermotorer, der er tilgængelige i MySQL og derefter MariaDB. Det er ikke transaktionsbestemt, hvilket gør det ikke ideelt til replikeringsopsætningerne og, ja, også de fleste andre miljøer. Det er stadig en meget hurtig motor, især med hensyn til indeksadgang, hvilket gør den velegnet til skrivebeskyttede arbejdsbelastninger, der ikke vil blive påvirket af låsning af INSERT'er og generel skrøbelighed af MyISAM.
Aria
Aria er en motor oprettet til MariaDB som erstatning for MyISAM. Det er ikke transaktionsbaseret, men det er crash-sikkert, hvilket gør det meget mere pålideligt. I øjeblikket bruges det til system- og midlertidige tabeller, men det kan også bruges i stedet for MyISAM til arbejdsbelastninger, der kræver hurtig, skrivebeskyttet adgang til data.
Hukommelse
Dette er en alt-i-hukommelses-motor, der typisk bruges til midlertidige in-memory-tabeller. Det er ikke vedvarende, men fungerer muligvis for nogle skrivebeskyttede arbejdsbelastninger.
CSV
Denne lagermaskine er designet til at gemme data i en fil som kommaseparerede værdier. Det er ikke den mest brugte lagringsmotor, den er meget specialiseret, men den kan stadig bruges til nemt at udtrække data fra MariaDB til enhver anden databasesoftware såvel som Excel eller lignende software.
Lagringsmotorer i MariaDB Enterprise Server
MariaDB Enterprise Server kommer med et par ekstra lagringsmotorer ud over, hvad der er tilgængeligt i fællesskabsudgaven. Lad os også tage et kig på dem.
ColumnStore
Dette er en dedikeret lagermaskine til analytisk arbejdsbyrde. Takket være den specifikke måde at lagre data på gør det det hurtigere at hente store mængder data, som ofte er nødvendige for rapportering. Dette kan være den lagermaskine, du vælger til OLAP-arbejdsbelastninger (OnLine Analytical Processing).
S3
S3-motor giver dig adgang til data placeret i S3. Det er en ikke-transaktionel motor beregnet til at give brugerne mulighed for at arkivere data i S3. Skrivebeskyttet adgang er tilgængelig, efter at tabellen er oprettet.
edderkop
Spider Engine lader dig forbinde flere MariaDB-databaser på tværs af netværket, hvilket skaber et sharded lager. Det er transaktionsbestemt, og det gør det lettere for brugerne at skalere ud ved at opdele dataene på tværs af adskillige MariaDB Enterprise Servere, fordele trafikken og arbejdsbyrden mellem dem.
MyRocks
MyRocks er en lagringsmotor udviklet i Facebook, den har til formål at reducere skriveforstærkningen og minimere sliddet på SSD-drev. Det er en transaktionsmotor, som burde håndtere OLTP-arbejdsbelastning ganske godt, især arbejdsbelastninger, der er typiske for sociale medier-websteder. MyRocks kommer med en ret god komprimering, bedre end InnoDB, hvilket kan være med til at reducere udgifterne til opbevaring markant, hvis datasættet bliver for stort til, at InnoDB kan håndtere det korrekt.
Konklusion
Som du kan se, er der adskillige muligheder leveret af både MariaDB Enterprise og Community Server med hensyn til den måde, hvorpå data kan lagres. Der er lagermotorer, der udmærker sig i skrivebeskyttede arbejdsbelastninger, OLAP eller store datasæt. Det er op til brugeren at vælge en god pasform. Vær opmærksom på, at du, når du er i tvivl, altid kan holde dig til InnoDB, som giver ret god ydeevne generelt og burde være mere end nok til de fleste tilfælde. Det er til de kantsager, hvor du måske skal lede efter noget mere passende.