Databasemotor

En databasemotor (eller lagringsmotor^[1][2]) er den underliggende programvarekomponenten som et databasestyringssystem (DBMS) bruker til å opprette, lese, oppdatere og slette (CRUD) data fra en database. De fleste databasehåndteringssystemer (DBMS) inkluderer sitt eget applikasjons-programmeringsgrensesnitt (API) som lar brukeren samhandle med den underliggende motoren uten å gå gjennom brukergrensesnittet til databasehåndteringssystemet.

Begrepet "databasemotor" forveksles av og til med databasetjener og databasehåndteringssystem. En "databaseinstans" refererer til prosessene og minnestrukturene til den kjørende databasemotoren.

Mange av de moderne databasehåndteringssystemer støtter flere lagringsmotorer i samme database. For eksempel støtter MySQL både InnoDB og MyISAM.

Noen lagringsmotorer er transaksjonelle.

Ytterligere motortyper inkluderer:

• Innebygde databasemotorer
• Hovedminne-databasemotorer

Informasjon i en database lagres som biter anlagt som en lagret datastrukturer i maskinvaren som effisient kan leses fra og skrives til. Vanligvis er selve lagringen designet for å møte krav til ulike områder som i stor grad bruker lagring, inkludert databaser. Et databasehåndteringssystem i drift bruker alltid flere lagringstyper samtidig (for eksempel minne og ekstern lagring) med sine respektive layoutmetoder.

I prinsippet kan databaselagringen sees på som et lineært adresserom hvor hver bit av data har sin unike adresse i dette adresserommet. I praksis er det bare en svært liten prosentandel av adressene som beholdes som innledende referansepunkter (som også krever lagring), mens de fleste dataene aksesseres indirekte ved bruk av beregninger (bitavstand fra referansepunktene) og ved datastrukturer som definerer tilgangsstier (ved hjelp av pekere) til alle nødvendige data på en effektiv måte som er optimalisert for nødvendige datatilgangsoperasjoner.

En database som er i drift har flere typer lagring samtidig, og danner et lagerhierarki. I moderne datamaskiner er mesteparten av databasedelen som er vert for DBMS (delvis replikert) i flyktig lagring. Data (deler av databasen) som blir manipulert ligger inni en prosessor, muligens i prosessoren sitt hurtigminne. Disse dataene blir lest fra og skrevet til minnet, vanligvis gjennom en databuss (typisk flyktige lagringskomponenter). Datamaskinminne kommuniserer data (overført til/fra) ekstern lagring, vanligvis gjennom et standard lagringsgrensesnitt eller nettverk (for eksempel fiberkanal, iSCSI).

Et lagringsarray (en vanlig ekstern lagringsenhet) har typisk et eget lagringshierarki, fra en rask hurtigbuffer som typisk består av (flyktig og rask) DRAM, som er koblet (via standardgrensesnitt) til stasjoner med muligens forskjellige hastigheter som fastminne-stasjoner og magnetiske diskstasjoner (ikke-flyktig). Stasjonene kan være koblet til magnetbånd, som vanligvis de minst aktive delene en stor database kan ligge på, eller sikkerhetskopier av databaser.

For tiden per 2020-årene er det vanligvis en korrelasjon mellom lagringshastighet og pris, men den raskeste lagringen er vanligvis volatil.

En datastruktur er en abstrakt konstruksjon som holder på data på en veldefinert måte. En effisient datastruktur tillater manipulering av dataene på effisiente måter. Datamanipulasjonen kan omfatte datainnsetting, sletting, oppdatering og uthenting i ulike moduser. En gitt datastrukturtype kan være svært effektiv i visse operasjoner, og svært ineffektiv i andre. En datastrukturtype velges ved utvikling av DBMS for best å møte operasjonene som trengs for datatypene den inneholder. Typen datastruktur valgt for en bestemt oppgave tar vanligvis også i betraktning hvilken type lagring den ligger i (for eksempel tilgangshastighet, minimal størrelse på lagringsstykkene man får tilgang til, og så videre). I noen DBMS-er har databaseadministratorer fleksibilitet til å velge mellom ulike datastrukturer for å lagre brukerdata av ytelsesgrunner. Noen ganger har datastrukturene velgbare parametere for å justere databaseytelsen.

Databaser kan lagre data i mange datastrukturtyper.^[3] Noen vanlige eksempler er:

• Ordnede/uordnede flatfiler
• Hashtabeller
• B+ trær
• ISAM
• Hauger (heaps)

I motsetning til konvensjonell radorientering kan relasjonsdatabaser også være kolonneorienterte eller korrelasjonsorienterte i måten de lagrer data på i en bestemt struktur.

Generelt oppnås betydelig ytelsesforbedring hvis forskjellige typer databaseobjekter som vanligvis brukes sammen lagres i nærheten og blir "gruppert". Dette gjør det vanligvis mulig å hente nødvendige relaterte objekter fra lagring med minimum antall innputtoperasjoner (som kan være betydelig tidkrevende). Selv for hovedminnedatabaser gir klynging ytelsesfordeler på grunn av vanlig bruk av store hurtigminner (caches) for innputt-utputt-operasjoner i minnet, med lignende resulterende oppførsel.

For eksempel kan det være fordelaktig å gruppere en oppføring for en "vare" på lager med alle dens respektive "ordre"-oppføringer. Beslutningen om å gruppere bestemte objekter eller ikke avhenger av objektenes bruksstatistikk, objektstørrelser, hurtigminnestørrelser, lagringstyper, og så videre.

Indeksering er en teknikk noen lagringsmotorer bruker for å forbedre databaseytelsen. De mange typene indekser deler den felles egenskapen at de reduserer behovet for å undersøke hver oppføring når man kjører en spørring. I store databaser kan dette redusere spørretiden/kostnadene i flere størrelsesordener. Den enkleste formen for indeks er en sortert liste over verdier som kan søkes ved hjelp av et binært søk med en tilstøtende referanse til plasseringen av oppføringen, analogt med indeksen bak i en bok. De samme dataene kan ha flere indekser (en ansattdatabase kan indekseres etter etternavn og ansettelsesdato).

Indekser påvirker ytelsen, men ikke resultatene. Databasedesignere kan legge til eller fjerne indekser uten å endre applikasjonslogikk, noe som reduserer vedlikeholdskostnadene etterhvert som databasen vokser og databasebruken utvikler seg. Indekser kan øke hastigheten på datatilgangen, men bruker plass i databasen og må oppdateres hver gang dataene endres. Indekser kan derfor øke hastigheten på datatilgangen, men sinke datavedlikeholdet. Disse to egenskapene avgjør hvorvidt en gitt indeks er verdt kostnaden.