Når en database oprettes, er en ofte overset, men kritisk faktor i ydeevnen storage-motoren (især når databasen vokser). I mange tilfælde er fristelsen bare at acceptere standarden og fortsætte med at udvikle dit projekt. Dette kan føre til uventede negative påvirkninger på ydeevne, sikkerhedskopier og dataintegritet senere i applikationens livscyklus, såsom når dit team implementerer analyser og MySQL-dashboards.
For at undgå disse potentielle faldgruber skal vi se nærmere på nogle af de mest udbredte storage-motorer, der understøttes af MySQL (fra version 5.7).
Understøttede lagermotorer
Hvad er mine muligheder?
Som standard understøtter MySQL 5.7 ti lagermotorer (InnoDB, MyISAM, Memory, CSV, Archive, Blackhole, NDB, Merge, Federated og Eksempel). Brug denne kommando for at se, hvilke der er tilgængelige og understøttes af din server:
mysql> VIS MOTORER\G
Dette vil udsende en liste over lagermotorer og fortælle dig, hvilke der er tilgængelige, ikke tilgængelige, eller som i øjeblikket er indstillet til standard. Kolonnen "Support:" viser henholdsvis "JA", "NEJ" eller "DEFAULT".
I nogle applikationer kan der opstå behov for at have forskellige lagringsmotorer til forskellige tabeller i den samme database. Dette er et eksempel på, hvorfor du skal nøje planlægge datamodellen til din applikation. I de fleste tilfælde vil der dog kun være behov for én lagermotor.
Storage Engine-kapaciteter
Hvad er de gode til?
Lad os se nærmere på nogle af de mest brugte lagermotorer. Dette vil give os en idé om, hvad hver enkelt motor er designet til at gøre, og hvordan de bedst kan bruges til at tjene vores forretningsmål.
InnoDB: Standardindstillingen i MySQL 5.7, InnoDB er en robust lagermaskine, der tilbyder:
- Fuld ACID-overholdelse
- Commit, rollback og crash-gendannelse
- Låsning på rækkeniveau
- FREIGN KEY referenceintegritetsbegrænsninger
- Øg samtidighed med flere brugere (via ikke-låsende læsninger)
Med ovenstående funktionalitet, som InnoDB tilbyder, er det indlysende, hvorfor det er standardmotoren i MySQL. Det er en motor, der fungerer godt og tilbyder mange af de nødvendige egenskaber, som enhver database har brug for. En omfattende diskussion af alle dens muligheder er dog uden for denne artikels rammer. Dette er den motor, der højst sandsynligt vil blive brugt i de fleste applikationer.
MyISAM: Den funktionalitet, der adskiller MyISAM, er dens evne til:
- Fuldtekstsøgeindekser
- Låsning på bordniveau
- manglende support til transaktioner
Selvom det er en hurtig lagringsmotor, er den bedst egnet til brug i læsetunge og for det meste læste applikationer såsom data warehousing og webapplikationer, der ikke behøver transaktionssupport eller ACID-overholdelse.
NDB (eller NDBCLUSTER):Hvis et klyngemiljø er det sted, hvor din database vil arbejde, er NDB den foretrukne lagermotor. Det er bedst, når du har brug for:
- Distribueret databehandling
- Høj redundans
- Høj tilgængelighed
- Den højest mulige oppetid
Bemærk, at understøttelse af NDB ikke er inkluderet i distributionen af standard MySQL Server 5.7 binære filer. Du bliver nødt til at opdatere til den seneste binære udgivelse af MySQL Cluster. Selvom du udvikler dig i et klyngemiljø, har du sandsynligvis den nødvendige erfaring til at håndtere disse opgaver.
CSV: En nyttig lagringsmotor, når data skal deles med andre applikationer, der bruger CSV-formaterede data. Tabellerne gemmes som kommaseparerede tekstfiler. Selvom dette gør deling af data med scripts og applikationer nemmere, er en ulempe, at CSV-filerne ikke indekseres. Så dataene skal gemmes i en InnoDB-tabel indtil import/eksportfasen af processen.
Sort hul: Denne motor accepterer, men gemmer ikke data. I lighed med UNIX /dev/null returnerer forespørgsler altid et tomt sæt. Dette kan være nyttigt i et distribueret databasemiljø, hvor du ikke ønsker at gemme data lokalt eller i ydeevne eller andre testsituationer.
Arkiv: Ligesom navnet antyder, er denne motor fremragende til sjældent refererede historiske data. Tabellerne er ikke indekseret, og komprimering sker ved indsættelse. Transaktioner understøttes ikke. Brug denne lagermaskine til at arkivere og hente tidligere data.
Forbundet: Denne lagringsmotor er til at skabe en enkelt, lokal, logisk database ved at forbinde flere forskellige fysiske MySQL-servere. Der gemmes ingen data på den lokale server, og forespørgsler udføres automatisk på den respektive fjernserver. Det er perfekt til distribuerede datamart-miljøer og kan i høj grad forbedre ydeevnen, når du bruger MySQL til analytisk rapportering.
Design af en lagermaskine
Hvordan ændrer jeg, hvilken lagermotor der bruges?
Lagermotoren, der bruges, etableres ved oprettelse af tabellen. Som tidligere nævnt er InnoDB standardlagringsmotoren i MySQL version 5.5 og nyere. Hvis du gerne vil bruge en anden, er det bedst at gøre dette i din CREATE TABLE-sætning. Lad os for eksempel sige, at du har identificeret en tabel, der skal bruge CSV-lagringsmotoren. Din alt for forenklede CREATE TABLE-sætning kan se sådan ud:
mysql> OPRET TABEL Shared_Data (
-> Data_ID INTEGER IKKE NULL,
-> Navn VARCHAR(50) NOT NULL,
-> Beskrivelse VARCHAR(150)
-> ) ENGINE=’CSV’;
Hvorefter vi ville udføre en INSERT-sætning som normalt:
mysql> INSERT INTO Shared_Data VALUES
-> (1,'enhed et', 'den seneste version af den bedste teknologi'),
-> (2,'enhed to', 'den hurtigste på markedet');
Efter succes, hvis du inspicerer databasemappen, skulle der nu være en 'Shared_Data.CSV'-fil i den, der indeholder de poster, du har indsat i Shared_Data-tabellen.
Den samme metode kan bruges til enhver af de mange storage-motorer, som MySQL understøtter. Selvom det er muligt at ændre lagermotoren, efter at en tabel er blevet oprettet med en ALTER TABLE erklæring, er det bedste praksis at planlægge i overensstemmelse hermed og indstille det i begyndelsen.
Til afslutning
MySQL har mange muligheder
Som du kan se, tilbyder MySQL support til storage-motorer designet til at håndtere meget forskellige opgaver i mange forskellige miljøer. At identificere, hvilke motorer der skal bruges, og hvornår de skal bruges, kan hjælpe os med at undgå unødvendige komplikationer og ydeevneproblemer, efterhånden som vores applikationer skaleres.
Uanset om du har brug for 99,999 % oppetid og pålidelighed på din distribuerede computerklynge, eller du har brug for ACID-kompatibel transaktionssupport med FOREIGN KEY-begrænsninger, har MySQL en lagermotor, der passer til dine behov.
Som altid er korrekt planlægning og identifikation af dine projektmål og krav den bedste måde til præcist at identificere, hvilke lagringsmotorer der er bedst egnede til din applikation. Forhåbentlig tjener denne artikel som et nyttigt udgangspunkt for at hjælpe dig i den henseende.
Denne artikel blev oprindeligt vist her. Genudgivet med tilladelse. Indsend dine ophavsretsklager her.