MariaDB Server härleddes ursprungligen från MySQL och har därför ärvt dess pluggbara lagringsmotorarkitektur. Olika lagringsmotorer har olika egenskaper vad gäller prestanda men också egenskaper och möjligheter. Detta gör att användare kan välja rätt verktyg för jobbet istället för att använda samma lagringsmotor oavsett vad som är syftet med datan, vilka krav som gäller för datalagring och hur data ska nås. I det här blogginlägget skulle vi vilja titta på de tillgängliga alternativen i MariaDB och diskutera potentiella användningsfall för de olika tillgängliga lagringsmotorerna.
Vad är en lagringsmotor?
Först, men låt oss ta en titt på vad är lagringsmotorn? MariaDB består av flera lager som fungerar tillsammans. SQL tolkas av en av dem, sedan når MariaDB ut efter data med hjälp av ett gemensamt API. Under huven finns en lagringsmotor som innehåller data och den reagerar på förfrågningar om data, extraherar data och gör den tillgänglig för MariaDB.
Kort sagt, MariaDB skickar en begäran om en rad och det är helt upp till lagringsmotorn att hämta den och skicka tillbaka den. MariaDB bryr sig inte om exakt hur raden lagras eller hur den ska hämtas, det är helt upp till implementeringen inom lagringsmotorn. Lagringsmotorer kan också implementera olika funktioner. Transaktioner hanteras också helt på lagringsmotorns sida. Det är därför vissa av supporttransaktionerna och andra inte gör det. Med denna arkitektur är det möjligt att skriva olika lagringsmotorer, dedikerade till att lösa olika problem.
Lagringsmotorer i MariaDB Server
MariaDB kommer med en uppsättning lagringsmotorer. Du kan kontrollera vilka som är tillgängliga genom ett enkelt 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 finns det många av dem, vi kommer att täcka de viktigaste.
InnoDB
InnoDB är uppenbarligen lagringsmotorn. Transactional, byggd för att hantera OLTP-trafik, kan ge riktigt bra prestanda. Det är standardmotorn som används i MariaDB och, om du inte vet vad du gör, vill du förmodligen hålla fast vid den för din databas.
MyISAM
MyISAM är en av de "ursprungliga" lagringsmotorerna som finns tillgängliga i MySQL och sedan MariaDB. Det är inte transaktionsbaserat, vilket gör det inte idealiskt för replikeringsinställningarna och, ja, de flesta andra miljöer också. Det är fortfarande mycket snabb motor, särskilt när det gäller indexåtkomst, vilket gör den lämplig för skrivskyddade arbetsbelastningar som inte kommer att påverkas av låsning av INSERT och övergripande bräcklighet av MyISAM.
Aria
Aria är en motor skapad för MariaDB som ersättning för MyISAM. Det är inte transaktionsmässigt men det är kraschsäkert vilket gör det mycket mer tillförlitligt. För närvarande används den för system- och temporära tabeller, men den kan också användas istället för MyISAM för arbetsbelastningar som kräver snabb skrivskyddad åtkomst till data.
Minne
Detta är en allt-i-minne-motor som vanligtvis används för tillfälliga minnestabeller. Det är inte beständigt men kan fungera för vissa skrivskyddade arbetsbelastningar.
CSV
Denna lagringsmotor är utformad för att lagra data i en fil som kommaseparerade värden. Det är inte den mest använda lagringsmotorn, den är mycket specialiserad men den kan fortfarande användas för att enkelt extrahera data från MariaDB till vilken annan databasprogramvara som helst, såväl som Excel eller liknande programvara.
Lagringsmotorer i MariaDB Enterprise Server
MariaDB Enterprise Server kommer med ett par extra lagringsmotorer utöver vad som är tillgängligt i community-utgåvan. Låt oss ta en titt på dem också.
ColumnStore
Detta är en dedikerad lagringsmotor för analytisk arbetsbelastning. Tack vare det specifika sättet att lagra data går det snabbare att hämta stora datamängder, som ofta behövs för rapportering. Detta kan vara den lagringsmotor du väljer för OLAP-arbetsbelastningar (OnLine Analytical Processing).
S3
S3-motorn låter dig komma åt data som finns i S3. Det är en icke-transaktionsmotor avsedd att ge användare möjlighet att arkivera data i S3. Skrivskyddad åtkomst är tillgänglig efter att tabellen har skapats.
Spindel
Spider Engine låter dig ansluta flera MariaDB-databaser över nätverket, vilket skapar en delad lagring. Det är transaktionsbaserat och det gör det lättare för användare att skala ut genom att dela upp data över flera MariaDB Enterprise Servers, fördela trafiken och arbetsbelastningen mellan dem.
MyRocks
MyRocks är en lagringsmotor utvecklad i Facebook, den är avsedd att minska skrivförstärkningen och minimera slitaget på SSD-enheter. Det är en transaktionsmotor som borde hantera OLTP-arbetsbelastning ganska bra, särskilt arbetsbelastningar som är typiska för webbplatser för sociala medier. MyRocks kommer med ganska bra komprimering, bättre än InnoDB, vilket kan bidra till att avsevärt minska utgifterna för lagring om datauppsättningen blir för stor för att InnoDB ska kunna hanteras på rätt sätt.
Slutsats
Som du kan se finns det många alternativ som tillhandahålls av både MariaDB Enterprise och Community Server angående hur data kan lagras. Det finns lagringsmotorer som utmärker sig i skrivskyddade arbetsbelastningar, OLAP eller stora datamängder. Det är upp till användaren att välja en bra passform. Tänk på att när du är osäker kan du alltid hålla dig till InnoDB, som ger ganska bra prestanda i allmänhet och borde vara mer än tillräckligt för majoriteten av fallen. Det är för de kantfall där du kan behöva leta efter något mer lämpligt.