När en databas skapas är en ofta förbisedd men kritisk faktor för prestanda lagringsmotorn (särskilt när databasen växer). I många fall är frestelsen att bara acceptera standarden och fortsätta att utveckla ditt projekt. Detta kan leda till oväntade negativa effekter på prestanda, säkerhetskopior och dataintegritet senare i applikationens livscykel, till exempel när ditt team implementerar analyser och MySQL-dashboards.
För att undvika dessa potentiella fallgropar kommer vi att titta närmare på några av de mest använda lagringsmotorerna som stöds av MySQL (från och med version 5.7).
Lagringsmotorer som stöds
Vilka är mina alternativ?
Som standard stöder MySQL 5.7 tio lagringsmotorer (InnoDB, MyISAM, Memory, CSV, Archive, Blackhole, NDB, Merge, Federated och Example). För att se vilka som är tillgängliga och stöds av din server, använd det här kommandot:
mysql> VISA MOTORER\G
Detta kommer att mata ut en lista över lagringsmotorer och berätta vilka som är tillgängliga, inte tillgängliga eller vilka som för närvarande är inställda på standard. Kolumnen "Support:" visar "JA", "NEJ" respektive "DEFAULT".
I vissa applikationer kan det uppstå behov av att ha olika lagringsmotorer för olika tabeller i samma databas. Det här är ett exempel på varför du måste noggrant planera datamodellen för din applikation. I de flesta fall kommer dock bara en lagringsmotor att behövas.
Lagringsmotorkapacitet
Vad är de bra på?
Låt oss ta en närmare titt på några av de mest använda lagringsmotorerna. Detta kommer att ge oss en uppfattning om vad varje motor var designad för att göra och hur de bäst kan användas för att tjäna våra affärsmål.
InnoDB: Standardalternativet i MySQL 5.7, InnoDB är en robust lagringsmotor som erbjuder:
- Fullständig ACID-efterlevnad
- Bekräftelse, återställning och kraschåterställning
- Låsning på radnivå
- FREIGN KEY referensintegritetsbegränsningar
- Öka samtidighet för flera användare (via icke-låsande läsningar)
Med ovanstående funktionalitet som InnoDB erbjuder är det uppenbart varför det är standardmotorn i MySQL. Det är en motor som fungerar bra och erbjuder många av de nödvändiga attributen som en databas skulle behöva. En omfattande diskussion av alla dess möjligheter ligger dock utanför ramen för denna artikel. Detta är den motor som troligen kommer att användas i de flesta applikationer.
MyISAM: Funktionen som skiljer MyISAM åt är dess förmåga för:
- sökindex i fulltext
- bordsnivålåsning
- brist på stöd för transaktioner
Även om det är en snabb lagringsmotor är den bäst lämpad för användning i lästunga och mestadels lästa applikationer som datalagring och webbapplikationer som inte behöver transaktionsstöd eller ACID-kompatibilitet.
NDB (eller NDBCLUSTER):Om en klustrad miljö är där din databas kommer att fungera, är NDB den lagringsmotor du väljer. Det är bäst när du behöver:
- Distribuerad datoranvändning
- Hög redundans
- Hög tillgänglighet
- Högsta möjliga drifttid
Observera att stöd för NDB inte ingår i distributionen av standard MySQL Server 5.7-binärfiler. Du måste uppdatera till den senaste binära versionen av MySQL Cluster. Men om du utvecklar i en klustermiljö har du förmodligen den nödvändiga erfarenheten för att hantera dessa uppgifter.
CSV: En användbar lagringsmotor när data behöver delas med andra applikationer som använder CSV-formaterad data. Tabellerna lagras som kommaseparerade värdetextfiler. Även om detta gör det lättare att dela data med skript och applikationer, är en nackdel att CSV-filerna inte indexeras. Så data bör lagras i en InnoDB-tabell tills import-/exportfasen av processen.
Blackhole: Denna motor accepterar men lagrar inte data. I likhet med UNIX /dev/null returnerar frågor alltid en tom uppsättning. Detta kan vara användbart i en distribuerad databasmiljö där du inte vill lagra data lokalt eller i prestanda eller andra testsituationer.
Arkiv: Precis som namnet antyder är denna motor utmärkt för sällan refererade historiska data. Tabellerna är inte indexerade och komprimering sker vid insättning. Transaktioner stöds inte. Använd denna lagringsmotor för att arkivera och hämta tidigare data.
Föderat: Denna lagringsmotor är till för att skapa en enda, lokal, logisk databas genom att länka flera olika fysiska MySQL-servrar. Ingen data lagras på den lokala servern och frågor exekveras automatiskt på respektive fjärrserver. Den är perfekt för distribuerade datamart-miljöer och kan avsevärt förbättra prestandan när du använder MySQL för analytisk rapportering.
Utse en lagringsmotor
Hur ändrar jag vilken lagringsmotor som används?
Lagringsmotorn som används etableras när tabell skapas. Som tidigare nämnts är InnoDB standardlagringsmotorn i MySQL version 5.5 och högre. Om du vill använda en annan, är det bäst att göra detta i din CREATE TABLE-sats. Låt oss till exempel säga att du har identifierat en tabell som behöver använda CSV-lagringsmotorn. Din alltför förenklade CREATE TABLE-sats kan se ut så här:
mysql> SKAPA TABELL Shared_Data (
-> Data_ID INTEGER INTE NULL,
-> Namn VARCHAR(50) NOT NULL,
-> Beskrivning VARCHAR(150)
-> ) ENGINE=’CSV’;
Därefter utförde vi en INSERT-sats som vanligt:
mysql> INSERT INTO Shared_Data VALUES
-> (1,'enhet ett', 'den senaste versionen av den bästa tekniken'),
-> (2,'enhet två', 'den snabbaste på marknaden');
Om du har lyckats, om du inspekterar databaskatalogen, bör det nu finnas en "Shared_Data.CSV"-fil i den som innehåller de poster du har infogat i Shared_Data-tabellen.
Samma metod kan användas för vilken som helst av de många lagringsmotorer som MySQL stöder. Även om det är möjligt att ändra lagringsmotorn efter att en tabell har skapats med en ALTER TABLE uttalande, är det bästa praxis att planera därefter och ställa in det i början.
Avslutningsvis
MySQL har många alternativ
Som du kan se erbjuder MySQL stöd för lagringsmotorer utformade för att hantera väldigt olika uppgifter i många olika miljöer. Att identifiera vilka motorer som ska användas och när de ska användas kan hjälpa oss att undvika onödiga komplikationer och prestandaproblem när våra applikationer skalas.
Oavsett om du behöver 99,999 % drifttid och tillförlitlighet på ditt distribuerade datorkluster eller om du behöver ACID-kompatibelt transaktionsstöd med FOREIGN KEY-begränsningar, har MySQL en lagringsmotor som passar dina behov.
Som alltid är korrekt planering och identifiering av dina projektmål och krav det bästa sättet att exakt identifiera vilka lagringsmotorer som är bäst lämpade för din applikation. Förhoppningsvis fungerar den här artikeln som en användbar utgångspunkt för att hjälpa dig i det avseendet.
Denna artikel visades ursprungligen här. Återpubliceras med tillstånd. Skicka in dina upphovsrättsanspråk här.