Varje databasarkitekt som designar en MySQL-databas står inför frågan om att välja rätt lagringsmotor. Vanligtvis använder ett program bara en motor:MyISAM eller InnoDB . Men låt oss försöka vara lite mer flexibla och föreställa oss hur olika lagringsmotorer kan användas.
Den initiala datamodellen
Till att börja, låt oss bygga en förenklad datamodell för ett CRM-system (customer relation management) som vi kommer att använda för att illustrera poängen. Designen kommer att täcka de viktigaste CRM-funktionerna:försäljningsdata, produktdefinitioner och information för analys. Den kommer inte att innehålla detaljer som vanligtvis används i CRM-system.
Som du kan se har denna datamodell tabeller som lagrar transaktionsinformation som kallas sale och sale_item . När en kund köper något kommer applikationen att skapa en ny rad i sale tabell. Varje köpt produkt kommer att återspeglas i sale_item tabell. En relaterad tabell, sale_status , är för att lagra möjliga statuser (d.v.s. väntande, komplett, etc.).
product tabell lagrar information om varor. Den definierar varje produkt och dess grundläggande beskrivningar. I ett mer detaljerat diagram skulle jag lägga till fler tabeller för att hantera produktspecifikation och kategorisering. Men för våra nuvarande behov är det inte nödvändigt.
Kundtabellen lagrar data om kunder. Detta är en integrerad del av alla CRM-system och det spårar vanligtvis alla användares individuella aktivitet. Uppenbarligen har den ofta riktigt detaljerad information. Men som jag noterade behöver vi inte dessa detaljer just nu.
log tabellen lagrar vad varje kund gjorde i applikationen. Och report_sales tabellen är designad för användning av dataanalys.
Därefter kommer jag att beskriva MySQL-lagringsmotorerna som möjligen kan användas i denna design. Och senare kommer vi att diskutera vilken motor som är lämplig för varje typ av bord.
En översikt över MySQL-lagringsmotorer
En lagringsmotor är en mjukvarumodul som MySQL använder för att skapa, läsa eller uppdatera data från en databas. Det rekommenderas inte att slumpmässigt välja en motor, men många utvecklare använder gärna antingen MyISAM eller InnoDB, även om andra alternativ också finns tillgängliga. Varje motor har sina egna för- och nackdelar, och rätt motorval beror på flera faktorer. Låt oss ta en titt på de mest populära motorerna.
- MyISAM har en lång historia med MySQL. Det var standardmotorn för MySQL-databaser innan 5.5-versionen. MyISAM stöder inte transaktioner och har endast låsning på tabellnivå. Det används mest för läsintensiva applikationer.
- InnoDB är en generell lagringsmotor som balanserar hög tillförlitlighet och bra prestanda. Den stöder transaktioner, radnivålåsning, kraschåterställning och samtidighetskontroll i flera versioner. Det ger också en referensintegritetsbegränsning för främmande nyckel.
- Minne motorn lagrar all data i RAM. Den kan användas för att lagra uppslagsreferenser.
- En annan motor, CSV , sparar data i textfiler med kommaseparerade värden. Detta format används mest för integration med andra system.
- Sammanfoga är ett bra val för rapporteringssystem, till exempel inom datalager. Det tillåter logisk gruppering av en uppsättning identiska MyISAM-tabeller, som också kan refereras till som ett objekt.
- Arkivera är optimerad för höghastighetsinsättning. Den lagrar information i kompakta, oindexerade tabeller och stöder inte transaktioner. Arkivlagringsmotorn är idealisk för att lagra stora mängder sällan refererade historiska eller arkiverade data.
- Det Federerade motorn erbjuder möjligheten att separera MySQL-servrar eller skapa en logisk databas från många fysiska servrar. Ingen data lagras i de lokala tabellerna och frågor exekveras automatiskt på de fjärranslutna (federerade) tabellerna.
- Det svarta hålet motorn fungerar som ett "svart hål" som accepterar data men inte lagrar det. Alla markeringar returnerar en tom datauppsättning.
- Motorn Exempel används för att visa hur man utvecklar nya lagringsmotorer.
Detta är inte en fullständig lista över lagringsmotorer. MySQL 5.x stöder nio av dem direkt från lådan, plus dussintals fler som utvecklats av MySQL-communityt. Mer information om lagringsmotorer finns i MySQL:s officiella dokumentation.
Uppdatera datamodelldesignen
Titta igen på vår datamodell. Uppenbarligen kommer olika tabeller att användas på olika sätt. sale tabellen måste stödja transaktioner. Å andra sidan, log och report_sales tabeller kräver inte denna funktion. Huvuduppdraget för log Tabellen lagrar data med maximal effektivitet. Snabb hämtning är huvudkravet för report_sales tabell.
Låt oss komma ihåg punkterna ovan och ändra vårt databasschema. I Vertabelo kan du ställa in "Lagringsmotor" i Tabellegenskaper panel. Ta en titt på bilderna nedan.
Ställa in lagringsmotorn
Så låt oss se uppdaterad databasdesign.
Jag specificerade lagringsmotorer för befintliga tabeller och omorganiserade report_sales tabell. Som du kan se är tabellerna indelade i tre grupper:
- Transaktionstabeller, som används med huvudprogrammet
- Rapporttabeller för BI-analys
- Loggtabell för lagring av all användaraktivitet
Låt oss prata om dem alla separat.
Transaktionstabeller
Dessa tabeller innehåller data som angetts av användare under daglig rutindrift. I vårt fall skulle det finnas försäljningsinformation, såsom:
- vilken anställd gjorde försäljningen
- vem köpte produkten
- vad som såldes
- hur mycket det kostade
I de flesta fall är InnoDB den bästa lösningen för transaktionstabeller. Denna lagringsmotor stöder radlåsning och vissa användare kan arbeta tillsammans. Likaså tillåter InnoDB användning av transaktioner och främmande nycklar. Men som ni vet är dessa förmåner inte gratis; motorn kan utföra urvalssatser långsammare än MyISAM och spara data med mindre effektivitet än Arkiv.
Alla motorer som beskrivs ovan har vissa skydd på plats, så utvecklare behöver inte skriva komplicerade återställningsfunktioner för varje operation. I en typisk försäljningsapplikation är det viktigare att hålla datakonsistensen än möjliga prestandaproblem.
Rapporttabeller
I den nya designen delade jag upp ett bord i ett par mindre bord. Detta sparar ansträngning när det är dags att hantera data och utföra tabell- och indexunderhåll. Det låter oss också skapa MERGE-tabellen sale_report för att kombinera andra rapporttabeller. Som ett resultat hämtar BI-verktyget fortfarande data från en stor tabell (för analysändamål), men vi har fördelen av att arbeta med mindre tabeller.
Report_sale_{year} tabeller är MyISAM-tabeller. Denna lagringsmotor stöder inte transaktioner och kan bara låsa tabellen som helhet. Eftersom MyISAM inte oroar sig för dessa komplexa föremål, utför den datamanipuleringsoperationer i snabb takt. På grund av sin filstruktur läser denna lagringsmotor data snabbare än den mer populära InnoDB.
Loggtabellen
Arkivlagringsmotorn är ett bra val för att lagra loggdata. Det kan infoga rader och komprimera lagrad data snabbt. Det finns stora fördelar med att behålla information om användaraktiviteter. Arkiv har dock vissa begränsningar. Den stöder inte uppdateringsoperationer och den hämtar data långsamt. Men i en loggtabell är de beskrivna fördelarna viktigare än nackdelarna.
Integrera lagringsmotorer
Varje system måste integreras med yttre liv. För applikationer kan detta vara användare som fyller i referens- och transaktionstabeller. Det kan vara tjänster och integration via REST, SOAP, WCF eller något liknande. Och sist men inte minst kan det vara databasintegration.
MySQL och Oracle har utvecklat två riktigt användbara lagringsmotorer:Federated och CSV . Den första, Federated , ska användas för att ladda data från en extern MySQL-databas. Den andra lagringsmotorn, CSV , tillåter databaser att spara poster i CSV-format och läsa kommaseparerade filer i luften, utan ytterligare ansträngningar.
Som du kan se ger din databas större flexibilitet att använda olika lagringsmotorer för olika ändamål. Om en databasarkitekt fattar sitt beslut efter att ha övervägt alla för- och nackdelar, kan resultatet bli riktigt imponerande.
Har du erfarenhet av att använda olika lagringsmotorer i databasdesign? Jag skulle vilja se dina tips och förslag. Vänligen dela dem i kommentarsfältet.