Databasemotor - Database engine
En databasemotor (eller lagermotor ) er den underliggende softwarekomponent, som et databasesystem (DBMS) bruger til at oprette, læse, opdatere og slette (CRUD) data fra en database . De fleste databasestyringssystemer inkluderer deres eget applikationsprogrammeringsinterface (API), der gør det muligt for brugeren at interagere med deres underliggende motor uden at gå gennem brugergrænsefladen i DBMS.
Udtrykket "databasemotor" bruges ofte i flæng med " databaseserver " eller "databasesystem". En "databaseinstans" refererer til processer og hukommelsesstrukturer i den kørende databasemotor .
Lagermotorer
Mange af de moderne DBMS understøtter flere lagermotorer i den samme database. For eksempel understøtter MySQL InnoDB såvel som MyISAM .
Nogle lagermotorer er transaktionelle .
| Navn | Licens | Transaktionelt |
|---|---|---|
| Aria | GPL | Ingen |
| Falk | GPL | Ja |
| InnoDB | GPL | Ja |
| MyISAM | GPL | Ingen |
| InfiniDB | GPL | Ingen |
| TokuDB | GPL | Ja |
| WiredTiger | GPL | Ja |
| XtraDB | GPL | Ja |
| KlipperDB | GPL v2 eller Apache 2.0 | Ja |
Yderligere motortyper omfatter:
- Indlejrede database motorer
- In-memory database motorer
Designovervejelser
Information i en database lagres som bits, der er lagt ud som datastrukturer i lagring, som tager effektivt kan læses fra og skrives til givet hardwareens egenskaber. Typisk er selve lageret designet til at opfylde kravene i forskellige områder, der i vid udstrækning udnytter lagring, herunder databaser. Et DBMS i drift anvender altid flere lagertyper samtidigt (f.eks. Hukommelse og ekstern lagring) med respektive layoutmetoder.
I princippet kan databaselagringen ses som et lineært adresserum , hvor hver bit data har sin unikke adresse i dette adresserum. I praksis opbevares kun en meget lille procentdel af adresser som indledende referencepunkter (hvilket også kræver lagring); de fleste data tilgås ved indirektion ved hjælp af forskydningsberegninger (afstand i bits fra referencepunkterne) og datastrukturer, der definerer adgangsveje (ved hjælp af pointer) til alle nødvendige data på en effektiv måde, optimeret til de nødvendige datatilgangsoperationer.
Databaselagerhierarki
En database, mens den er i drift, ligger samtidigt i flere lagertyper og danner et lagringshierarki . Af moderne computere er det meste af databasedelen inde i en computer, der er vært for DBMS, placeret (delvist replikeret) i flygtig lagring. Data (dele af databasen), der behandles/manipuleres, findes i en processor, muligvis i processorens caches . Disse data bliver læst fra / skrives til hukommelsen, typisk via en computer bus (indtil videre typisk flygtige opbevaring komponenter). Computers hukommelse kommunikerer data (overført til/fra) ekstern lagring, typisk via standard lagringsgrænseflader eller netværk (f.eks. Fiberkanal , iSCSI ). Et lagringsarray , en fælles ekstern lagerenhed, har typisk sit eget lagerhierarki fra en hurtig cache, typisk bestående af (flygtig og hurtig) DRAM , som er forbundet (igen via standardgrænseflader) til drev, muligvis med forskellige hastigheder, som flashdrev og magnetiske diskdrev (ikke-flygtige). Drevene kan være tilsluttet magnetbånd , hvor de typisk mindst aktive dele af en stor database typisk kan ligge, eller database -backupgenerationer.
Typisk eksisterer der i øjeblikket en sammenhæng mellem lagringshastighed og pris, mens den hurtigere opbevaring typisk er flygtig.
Datastrukturer
En datastruktur er en abstrakt konstruktion, der indlejrer data på en veldefineret måde. En effektiv datastruktur tillader manipulation af dataene på effektive måder. Datamanipulationen kan omfatte dataindsættelse, sletning, opdatering og hentning i forskellige tilstande. En bestemt datastrukturtype kan være meget effektiv i visse operationer og meget ineffektiv i andre. En datastrukturtype vælges ved DBMS -udvikling for bedst at imødekomme de operationer, der er nødvendige for de datatyper, den indeholder. Typen af datastruktur, der er valgt til en bestemt opgave, tager typisk også hensyn til, hvilken type lagring den opholder sig i (f.eks. Adgangshastighed, minimal størrelse af lagringsdel, der er adgang til osv.). I nogle DBMS'er har databaseadministratorer fleksibiliteten til at vælge mellem muligheder for datastrukturer til at indeholde brugerdata af ydeevne. Nogle gange har datastrukturer valgbare parametre til at justere databasens ydeevne.
Databaser kan gemme data i mange datastrukturtyper. Almindelige eksempler er følgende:
- bestilte/uordnede flade filer
- hashborde
- B+ træer
- ISAM
- dynger
Dataorientering og klynge
I modsætning til konventionel rækkeorientering kan relationsdatabaser også være kolonneorienterede eller korrelationsmæssige i den måde, de gemmer data på i en bestemt struktur.
Generelt opnås en væsentlig forbedring af ydeevnen, hvis forskellige typer databaseobjekter, der normalt bruges sammen, lægges i lagring i nærheden og bliver "grupperet". Dette giver normalt mulighed for at hente nødvendige relaterede objekter fra lagring i minimum antal inputoperationer (hver undertiden i det væsentlige tidskrævende). Selv for in-memory databaser giver clustering ydelsesfordele på grund af almindelig udnyttelse af store caches til input-output-operationer i hukommelsen med lignende resulterende adfærd.
For eksempel kan det være en fordel at samle en registrering af en "vare" på lager med alle dens respektive "ordre" poster. Beslutningen om, hvorvidt bestemte objekter skal klynges eller ej, afhænger af objekternes udnyttelsesstatistik, objektstørrelser, cachestørrelser, lagertyper osv.
Databaseindeksering
Indeksering er en teknik, nogle lagermotorer bruger til at forbedre databasens ydeevne. De mange typer indekser deler den fælles ejendom, at de reducerer behovet for at undersøge hver post, når du kører en forespørgsel. I store databaser kan dette reducere forespørgselstid/omkostninger ved størrelsesordener. Den enkleste form for indeks er en sorteret liste over værdier, der kan søges ved hjælp af en binær søgning med en tilstødende reference til placeringen af posten, analog med indekset bag i en bog. De samme data kan have flere indekser (en medarbejderdatabase kan indekseres efter efternavn og ansættelsesdato).
Indekser påvirker ydeevnen, men ikke resultaterne. Databasedesignere kan tilføje eller fjerne indekser uden at ændre applikationslogik, hvilket reducerer vedligeholdelsesomkostninger, når databasen vokser og databaseforbruget udvikler sig. Indekser kan fremskynde datatilgang, men de forbruger plads i databasen og skal opdateres hver gang dataene ændres. Indekser kan derfor fremskynde datatilgang, men langsom datavedligeholdelse. Disse to egenskaber afgør, om et givet indeks er værd at betale.