Elke database-architect die een MySQL-database ontwerpt, staat voor de kwestie van het selecteren van de juiste opslagengine. Gewoonlijk gebruikt een applicatie slechts één engine:MyISAM of InnoDB . Maar laten we proberen wat flexibeler te zijn en ons eens voorstellen hoe verschillende storage-engines kunnen worden gebruikt.
Het initiële gegevensmodel
Laten we om te beginnen een vereenvoudigd gegevensmodel bouwen voor een CRM-systeem (klantrelatiebeheer), dat we zullen gebruiken om het punt te illustreren. Het ontwerp omvat de belangrijkste CRM-functies:verkoopgegevens, productdefinities en informatie voor analyses. Het bevat geen details die doorgaans in CRM-systemen worden gebruikt.
Zoals u kunt zien, heeft dit gegevensmodel tabellen waarin transactie-informatie is opgeslagen, genaamd sale en sale_item . Wanneer een klant iets koopt, maakt de applicatie een nieuwe rij aan in de sale tafel. Elk gekocht product wordt weergegeven in de sale_item tafel. Een gerelateerde tabel, sale_status , is voor het opslaan van mogelijke statussen (d.w.z. in behandeling, voltooid, enz.).
Het product tabel slaat informatie over goederen op. Het definieert elk product en zijn basisbeschrijvingen. In een meer gedetailleerd diagram zou ik meer tabellen toevoegen om productspecificaties en categorisering af te handelen. Maar voor onze huidige behoeften is dat niet nodig.
De klantentabel houdt gegevens over klanten bij. Dit is een integraal onderdeel van elk CRM-systeem en volgt meestal de individuele activiteiten van alle gebruikers. Uiteraard bevat het vaak zeer gedetailleerde informatie. Maar zoals ik al zei, we hebben deze details nu niet nodig.
Het log table slaat op wat elke klant binnen de applicatie heeft gedaan. En de report_sales tabel is ontworpen voor gebruik van gegevensanalyse.
Vervolgens zal ik de MySQL-opslagengines beschrijven die mogelijk in dit ontwerp kunnen worden gebruikt. En later bespreken we welke engine geschikt is voor elk type tafel.
Een overzicht van MySQL-opslagengines
Een opslagengine is een softwaremodule die MySQL gebruikt om gegevens uit een database te maken, te lezen of bij te werken. Het wordt niet aanbevolen om willekeurig een engine te kiezen, maar veel ontwikkelaars gebruiken graag MyISAM of InnoDB, hoewel er ook andere opties beschikbaar zijn. Elke motor heeft zijn eigen voor- en nadelen, en de juiste motorkeuze hangt af van verschillende factoren. Laten we eens kijken naar de meest populaire engines.
- MijnISAM heeft een lange geschiedenis met MySQL. Het was de standaardengine voor MySQL-databases vóór de 5.5-release. MyISAM ondersteunt geen transacties en heeft alleen vergrendeling op tafelniveau. Het wordt meestal gebruikt voor leesintensieve toepassingen.
- InnoDB is een algemene opslagengine die een hoge betrouwbaarheid en goede prestaties combineert. Het ondersteunt transacties, vergrendeling op rijniveau, crashherstel en gelijktijdigheidscontrole met meerdere versies. Het biedt ook een referentiële integriteitsbeperking voor referentiële sleutels.
- Het Geheugen engine slaat alle gegevens op in RAM. Het kan worden gebruikt voor het opslaan van opzoekreferenties.
- Een andere engine, CSV , bewaart gegevens in tekstbestanden met door komma's gescheiden waarden. Dit formaat wordt meestal gebruikt voor integratie met andere systemen.
- Samenvoegen is een goede keuze voor rapportagesystemen, zoals in datawarehousing. Het maakt de logische groepering van een set identieke MyISAM-tabellen mogelijk, waarnaar ook als één object kan worden verwezen.
- Archief is geoptimaliseerd voor invoegen op hoge snelheid. Het slaat informatie op in compacte, niet-geïndexeerde tabellen en ondersteunt geen transacties. De Archive-opslagengine is ideaal voor het bewaren van grote hoeveelheden historische of gearchiveerde gegevens waarnaar zelden wordt verwezen.
- De Federale engine biedt de mogelijkheid om MySQL-servers te scheiden of om één logische database te maken van meerdere fysieke servers. Er worden geen gegevens opgeslagen op de lokale tabellen en zoekopdrachten worden automatisch uitgevoerd op de externe (federatieve) tabellen.
- Het Zwarte gat engine fungeert als een "zwart gat" dat gegevens accepteert maar niet opslaat. Alle selecties retourneren een lege dataset.
- De engine Voorbeeld wordt gebruikt om te laten zien hoe nieuwe storage-engines kunnen worden ontwikkeld.
Dit is geen volledige lijst van storage-engines. MySQL 5.x ondersteunt negen van hen direct uit de doos, plus tientallen meer ontwikkeld door de MySQL-gemeenschap. Meer details over storage-engines zijn te vinden in de officiële documentatie van MySQL.
Het ontwerp van het gegevensmodel bijwerken
Kijk nog eens naar ons datamodel. Het is duidelijk dat verschillende tabellen op verschillende manieren zullen worden gebruikt. De sale tabel moet transacties ondersteunen. Aan de andere kant, de log en report_sales tabellen hebben deze functie niet nodig. De belangrijkste missie van het log tabel slaat gegevens op met maximale efficiëntie. Snel ophalen is de belangrijkste vereiste voor de report_sales tafel.
Laten we bovenstaande punten in gedachten houden en ons databaseschema aanpassen. In Vertabelo kunt u "Opslag-engine" instellen in de Tabeleigenschappen paneel. Bekijk de foto's hieronder.
De opslagengine instellen
Laten we dus eens kijken naar het bijgewerkte database-ontwerp.
Ik heb opslagengines gespecificeerd voor bestaande tabellen en de report_sales tafel. Zoals u kunt zien, zijn de tabellen in drie groepen verdeeld:
- Transactietabellen, die worden gebruikt met de hoofdtoepassing
- Rapporttabellen voor BI-analyse
- Logtabel voor het opslaan van alle gebruikersactiviteit
Laten we ze allemaal afzonderlijk bespreken.
Transactietabellen
Deze tabellen bevatten gegevens die door gebruikers zijn ingevoerd tijdens dagelijkse routinehandelingen. In ons geval zou er verkoopinformatie zijn, zoals:
- welke medewerker de verkoop heeft gedaan
- die het product heeft gekocht
- wat is er verkocht
- hoeveel het kost
In de meeste gevallen is InnoDB de beste oplossing voor transactietabellen. Deze opslagengine ondersteunt rijvergrendeling en sommige gebruikers kunnen samenwerken. Evenzo staat InnoDB het gebruik van transacties en buitenlandse sleutels toe. Maar zoals u weet, zijn deze voordelen niet gratis; de engine kan bepaalde instructies langzamer uitvoeren dan MyISAM en gegevens opslaan met minder efficiëntie dan Archive.
Alle hierboven beschreven engines hebben enkele beveiligingen, zodat ontwikkelaars niet voor elke bewerking complexe rollback-functies hoeven te schrijven. In een typische verkooptoepassing is het belangrijker om de consistentie van gegevens te behouden dan mogelijke prestatieproblemen.
Rapporttabellen
In het nieuwe ontwerp heb ik een tafel opgedeeld in een paar kleinere tafels. Dit bespaart moeite wanneer het tijd is om gegevens te beheren en tabel- en indexonderhoud uit te voeren. Het stelt ons ook in staat om de MERGE-tabel te maken sale_report voor het combineren van andere rapporttabellen. Als gevolg hiervan haalt de BI-tool nog steeds gegevens uit één grote tabel (voor analysedoeleinden), maar we hebben het voordeel dat we met kleinere tabellen werken.
De Report_sale_{year} tabellen zijn MyISAM-tabellen. Deze opslagengine ondersteunt geen transacties en kan alleen de tafel als geheel vergrendelen. Omdat MyISAM zich geen zorgen maakt over deze complexe items, voert het gegevensmanipulaties snel uit. Vanwege de bestandsstructuur leest deze opslagengine gegevens sneller dan de meer populaire InnoDB.
De logtabel
De Archive-opslagengine is een goede keuze voor het opslaan van loggegevens. Het kan rijen invoegen en opgeslagen gegevens snel comprimeren. Er zijn grote voordelen voor het bijhouden van informatie over gebruikersactiviteiten. Archief heeft echter enkele beperkingen. Het ondersteunt geen update-bewerkingen en het haalt gegevens langzaam op. Maar in een logtabel zijn de beschreven voordelen belangrijker dan de nadelen.
Opslag-engines integreren
Elk systeem moet worden geïntegreerd met het externe leven. Voor toepassingen kunnen dit gebruikers zijn die referentie- en transactietabellen vullen. Het kunnen services en integratie zijn via REST, SOAP, WCF of iets dergelijks. En last but not least, het kan database-integratie zijn.
MySQL en Oracle hebben twee zeer nuttige opslagengines ontwikkeld:Federated en CSV . De eerste, Federaal , moet worden gebruikt voor het laden van gegevens uit een externe MySQL-database. De tweede opslagengine, CSV , stelt databases in staat om records in CSV-indeling op te slaan en door komma's gescheiden bestanden in de lucht te lezen, zonder extra inspanningen.
Zoals u kunt zien, geeft het gebruik van verschillende storage-engines voor verschillende doeleinden uw database meer flexibiliteit. Als een database-architect zijn beslissing neemt nadat hij alle voor- en nadelen heeft overwogen, kan het resultaat echt indrukwekkend zijn.
Heb je ervaring met het gebruik van verschillende storage-engines bij het ontwerpen van databases? Ik zie graag jullie tips en suggesties tegemoet. Deel ze alstublieft in het opmerkingengedeelte.