Enhver databasearkitekt, der designer en MySQL-database, står over for spørgsmålet om at vælge den rigtige lagringsmotor. Normalt bruger en applikation kun én motor:MyISAM eller InnoDB . Men lad os prøve at være lidt mere fleksible og forestille os, hvordan forskellige lagermotorer kan bruges.
Den indledende datamodel
Lad os til at begynde med bygge en forenklet datamodel for et CRM-system (customer relationship management), som vi vil bruge til at illustrere pointen. Designet vil dække de vigtigste CRM-funktioner:salgsdata, produktdefinitioner og information til analyse. Det vil ikke indeholde detaljer, der typisk bruges i CRM-systemer.
Som du kan se, har denne datamodel tabeller, der gemmer transaktionsoplysninger kaldet sale og sale_item . Når en kunde køber noget, vil applikationen oprette en ny række i sale bord. Hvert købt produkt vil blive afspejlet i sale_item bord. En relateret tabel, sale_status , er til lagring af mulige statusser (dvs. afventer, fuldført osv.).
product tabel gemmer oplysninger om varer. Den definerer hvert produkt og dets grundlæggende beskrivelser. I et mere detaljeret diagram vil jeg tilføje flere tabeller for at håndtere produktspecifikation og kategorisering. Men for vores nuværende behov er det ikke nødvendigt.
Kundetabellen gemmer data om kunder. Dette er en integreret del af ethvert CRM-system, og det sporer normalt alle brugeres individuelle aktivitet. Det er klart, at det ofte har virkelig detaljerede oplysninger. Men som jeg bemærkede, har vi ikke brug for disse detaljer lige nu.
log tabel gemmer, hvad hver kunde gjorde i applikationen. Og report_sales tabellen er designet til brug af dataanalyse.
Dernæst vil jeg beskrive MySQL-lagringsmotorerne, der muligvis kan bruges i dette design. Og senere vil vi diskutere, hvilken motor der er egnet til hver type bord.
En oversigt over MySQL Storage Engines
En lagringsmotor er et softwaremodul, som MySQL bruger til at oprette, læse eller opdatere data fra en database. Det anbefales ikke at vælge en motor tilfældigt, men mange udviklere er glade for at bruge enten MyISAM eller InnoDB, selvom andre muligheder også er tilgængelige. Hver motor har sine egne fordele og ulemper, og korrekt motorvalg afhænger af flere faktorer. Lad os tage et kig på de mest populære motorer.
- MyISAM har en lang historie med MySQL. Det var standardmotoren til MySQL-databaser før 5.5-udgivelsen. MyISAM understøtter ikke transaktioner og har kun låsning på tabelniveau. Det bruges mest til læsetunge programmer.
- InnoDB er en generel lagringsmotor, der balancerer høj pålidelighed og god ydeevne. Det understøtter transaktioner, række-niveau-låsning, crash recovery og multi-version samtidighedskontrol. Det giver også en fremmednøgle, referentiel integritetsbegrænsning.
- Hukommelsen motoren gemmer alle data i RAM. Den kan bruges til at gemme opslagsreferencer.
- En anden motor, CSV , opbevarer data i tekstfiler med kommaseparerede værdier. Dette format bruges mest til integration med andre systemer.
- Flet er et godt valg til rapporteringssystemer, såsom i data warehousing. Det tillader den logiske gruppering af et sæt identiske MyISAM-tabeller, som også kan refereres til som ét objekt.
- Arkiv er optimeret til højhastighedsindsættelse. Den gemmer information i kompakte, uindekserede tabeller og understøtter ikke transaktioner. Arkiv-lagringsmotoren er ideel til at opbevare store mængder sjældent refererede historiske eller arkiverede data.
- De Federerede motoren giver mulighed for at adskille MySQL-servere eller oprette en logisk database fra mange fysiske servere. Ingen data gemmes på de lokale tabeller, og forespørgsler udføres automatisk på de eksterne (fødererede) tabeller.
- Det Sorte hul motoren fungerer som et "sort hul", der accepterer data, men ikke gemmer dem. Alle valg returnerer et tomt datasæt.
- Motoren Eksempel bruges til at vise, hvordan man udvikler nye lagringsmotorer.
Dette er ikke en komplet liste over lagermotorer. MySQL 5.x understøtter ni af dem lige fra boksen, plus snesevis mere udviklet af MySQL-fællesskabet. Flere detaljer om lagringsmotorer kan findes på MySQLs officielle dokumentation.
Opdatering af datamodeldesignet
Se igen på vores datamodel. Det er klart, at forskellige tabeller vil blive brugt på forskellige måder. sale tabel skal understøtte transaktioner. På den anden side er log og report_sales tabeller kræver ikke denne funktion. Hovedopgaven for log tabellen lagrer data med maksimal effektivitet. Hurtig hentning er hovedkravet til report_sales bord.
Lad os huske punkterne ovenfor og ændre vores databaseskema. I Vertabelo kan du indstille "Lagringsmotor" i Tabelegenskaber panel. Se venligst billederne nedenfor.
Indstilling af lagermotoren
Så lad os se opdateret databasedesign.
Jeg specificerede lagermotorer for eksisterende tabeller og omorganiserede report_sales bord. Som du kan se, er tabellerne opdelt i tre grupper:
- Transaktionstabeller, som bruges sammen med hovedapplikationen
- Rapporttabeller til BI-analyse
- Logtabel til lagring af al brugeraktivitet
Lad os tale om dem alle hver for sig.
Transaktionstabeller
Disse tabeller indeholder data indtastet af brugere under daglige rutineoperationer. I vores tilfælde ville der være salgsoplysninger, såsom:
- hvilken medarbejder foretog salget
- hvem har købt produktet
- hvad der blev solgt
- hvor meget det kostede
I de fleste tilfælde er InnoDB den bedste løsning til transaktionstabeller. Denne lagermotor understøtter rækkelåsning, og nogle brugere er i stand til at arbejde sammen. Ligeledes tillader InnoDB brugen af transaktioner og fremmednøgler. Men som bekendt er disse fordele ikke gratis; motoren kan udføre udvalgte sætninger langsommere end MyISAM og gemme data med mindre effektivitet end Arkiv.
Alle de motorer, der er beskrevet ovenfor, har nogle beskyttelser på plads, så udviklere behøver ikke at skrive komplekse rollback-funktioner for hver operation. I en typisk salgsapplikation er det vigtigere at holde dataenes konsistens end mulige præstationsproblemer.
Rapporttabeller
I det nye design delte jeg det ene bord op i et par mindre borde. Dette sparer kræfter, når det er tid til at administrere data og udføre tabel- og indeksvedligeholdelse. Det giver os også mulighed for at oprette MERGE-tabellen sale_report til at kombinere andre rapporttabeller. Som følge heraf henter BI-værktøjet stadig data fra én enorm tabel (til analyseformål), men vi har fordelen ved at arbejde med mindre tabeller.
Report_sale_{year} tabeller er MyISAM-tabeller. Denne lagermaskine understøtter ikke transaktioner og kan kun låse bordet som helhed. Fordi MyISAM ikke bekymrer sig om disse komplekse elementer, udfører den datamanipulationsoperationer med hastighed. På grund af sin filstruktur læser denne lagermaskine data hurtigere end den mere populære InnoDB.
Logtabellen
Arkivlagringsmotoren er et godt valg til lagring af logdata. Det kan indsætte rækker og komprimere lagrede data hurtigt. Der er store fordele ved at opbevare information om brugeraktiviteter. Arkiv har dog nogle begrænsninger. Det understøtter ikke opdateringsoperationer, og det henter data langsomt. Men i en logtabel er de beskrevne fordele vigtigere end ulemperne.
Integration af lagermotorer
Hvert system skal integreres med eksternt liv. For applikationer kan dette være brugere, der udfylder reference- og transaktionstabeller. Det kan være services og integration via REST, SOAP, WCF eller sådan noget. Og sidst men ikke mindst kan det være databaseintegration.
MySQL og Oracle har udviklet to virkelig nyttige storage-motorer:Federated og CSV . Den første, Federated , skal bruges til at indlæse data fra en ekstern MySQL-database. Den anden lagermaskine, CSV , tillader databaser at gemme poster i CSV-format og læse kommaseparerede filer i luften uden yderligere indsats.
Som du kan se, giver brug af forskellige storage-motorer til forskellige formål din database større fleksibilitet. Hvis en databasearkitekt træffer deres beslutning efter at have overvejet alle fordele og ulemper, så kan resultatet være virkelig imponerende.
Har du erfaring med at bruge forskellige storage-motorer i databasedesign? Jeg vil gerne se dine tips og forslag. Del dem venligst i kommentarfeltet.