Redigerer Kolonneorientert database (avsnitt)

== Beskrivelse ==

=== Presentasjon ===
Data i en relasjonsdatabase representeres som en todimensjonal tabell med kolonner og rader. Dette er uavhengig av den underliggende datastukturen er rad- eller kolonnebasert.

For eksempel kan en databasetabell se slik ut:

{| class="wikitable"
!Rad_id
!Ansatt_id
! Etternavn
! Fornavn
! Lønn
|-
| 001
| 10
|Nilsen
|Thomas
| 60 000
|-
| 002
| 12
|Moen
|Erik
| 80 000
|-
| 003
| 11
|Jørgensen
|Anna
| 94 000
|-
| 004
| 22
|Moen
|Marit
| 55 000
|}

Tabellen har en ansattidentifikator (ansatt_id), navnefelt (etternavn og fornavn) og lønn. Dette todimensjonale formatet er en [[abstraksjon]], mens den faktiske implementeringen krever at dataene [[Serialisering|serialiseres]] på en eller annen form.

Den dyreste operasjon for [[Platelager|harddisker]] er søk. For å forbedre den generelle ytelsen bør relaterte data lagres på en måte som minimerer antall søk. Dette er kjent som [[referanselokalitet]], og dette grunnleggende konseptet dukker opp i mange sammenhenger. Harddisker er organisert i en serie [[Disksektor|blokker]] med fast størrelse, vanligvis nok til å lagre flere rader i tabellen. Ved å organisere tabellens data slik at rader passer innenfor disse blokkene, og ved å gruppere relaterte rader i sekvensielle blokker, minimeres antallet blokker som må leses eller søkes i for de fleste tilfeller, samt antallet søk.

En undersøkelse av Pinnecke med kolleger<ref name="Are Databases Fit for Hybrid Workloads on GPUs? A Storage Engine’s Perspective">{{Kilde konferanse|url=http://wwwiti.cs.uni-magdeburg.de/iti_db/publikationen/ps/auto/Pinnecke+BCS17.pdf|doi=10.1109/ICDE.2017.237}}</ref> beskrev teknikker for kolonne- og rad-hybridisering per 2017.

=== Radorienterte systemer ===
En vanlig metode for å lagre en tabell er å serialisere hver rad med data, slik:

 001:10,Nilsen,Thomas,60000;
 002:12,Moen,Erik,80000;
 003:11,Jørgensen,Anna,94000;
 004:22,Moen,Marit,55000;

Etter hvert som data settes inn i tabellen tildeles en intern ID <code>rad_id</code> som brukes internt i systemet for å referere til data. I dette tilfellet har postene sekvensielle <code>rad_id</code> uavhengig av brukertildelt <code>ansatt_id</code> . I dette eksemplet bruker DBMS-en korte heltall for å lagre <code>rad_id</code>-er. I praksis brukes normalt større tall på 64 bit eller 128 bit.

Radorienterte systemer er designet for å effisient returnere data for en hel rad eller [[Record|oppføring]] i så få operasjoner som mulig. Dette samsvarer med det vanlige bruksmønsteret der systemet prøver å hente informasjon om et bestemt objekt, for eksempel kontaktinformasjonen for en bruker i et [[Rolodex]]-system eller produktinformasjon for et netthandelsystem. Ved å lagre oppføringens data i en enkelt blokk på disken sammen med relaterte oppføringer kan systemet raskt hente oppføringer ved et minimum av diskoperasjoner.

Radorienterte systemer er ikke effisiente til å utføre [[Operator|operasjoner]] på hele [[Mengde|mengder]] (''set-wide operations'') på hele tabeller, i motsetning til et lite antall spesifikke oppføringer. For eksempel: For å finne alle oppføringer i eksempeltabellen hvor lønnen er mellom 40 000 og 50 000 må databasehåndteringssystemet skanne fullstendig gjennom hele tabellen på jakt etter samsvarende oppføringer. Mens eksempeltabellen ovenfor sannsynligvis vil passe inn i en enkelt diskblokk vil det fort ikke være tilfellet for en tabell med bare noen få hundre rader, og dermed vil flere diskoperasjoner være nødvendig for å hente dataene og undersøke dem.

For å forbedre ytelsen til denne typen operasjoner (som er veldig vanlige, og generelt poenget med å bruke et databasehåndteringssystem) støtter de fleste DBMS-er bruk av [[Databaseindeks|databaseindekser]] som lagrer alle verdiene fra en mengde med kolonner sammen med <code>rad_id</code>-[[Peker (informatikk)|pekere]] tilbake til den originale tabellen. En indeks for lønnskolonnen vil omtrent se slik ut:

 55000:004; 
 60000:001;
 80000:002;
 94000:003;

Siden de bare lagrer enkeltdata (i stedet for hele rader) er indeksene generelt mye mindre enn hoved-tabelllagrene. Skanning av denne mindre mengden med data reduserer antallet diskoperasjoner. Hvis indeksen er mye brukt kan den redusere tiden for vanlige operasjoner dramatisk. Vedlikehold av indekser legger imidlertid til [[Indirekte kostnader (informatikk)|indirekte kostnader]] i systemet, særlig når nye data skrives til databasen. Oppføringer må ikke bare lagres i hovedtabellen, men eventuelle tilknyttede indekser må også oppdateres.

Hovedårsaken til at indekser dramatisk forbedrer ytelsen på store datamengder er at databaseindekser på én eller flere kolonner typisk er sortert etter verdi, hvilket gjør at spørreoperasjoner om rekkevidder (som eksempelet ovenfor: "Finn alle oppføringer med lønn mellom 40 000 og 50 000") veldig raskt kan løses basert på indeksen (lavere [[tidskompleksitet]]).

En rekke radorienterte databaser er designet for å passe i [[Hovedminne|RAM]], en [[hovedminnedatabase]]. Disse systemene er ikke avhengige av diskoperasjoner, og har lik tilgang til hele datamengden. Dette reduserer behovet for indekser ettersom det kreves samme mengde operasjoner for å fullskanne originaldataene som en komplett indeks for typiske [[Aggregering (datavarehus)|aggregeringsformål]]. Slike systemer kan derfor være enklere og mindre, men kan bare håndtere databaser som passer i minnet.

=== Kolonneorienterte systemer ===
En kolonneorientert database serialiserer alle verdiene i en kolonne sammen, deretter verdiene til neste kolonne, og så videre. For eksempeltabellen over vil dataene bli lagret på følgende måte:

 001:10,002:12,003:11,004:22;
 001:Nilsen,002:Moen,003:Jørgensen,004:Moen,
 001:Thomas,002:Erik,003:Anna,004:Marit;
 001:60000,002:80000,003:94000,004:55000;

I dette oppsettet samsvarer hvilken som helst av kolonnene nærmere med strukturen til en indeks i et radorientert system. Dette kan føre til forvirring og den feilaktige oppfatningen om at et kolonneorientert lager egentlig bare er "et radlager med en indeks på hver kolonne". Imidlertid skiller [[Avbilding (matematikk)|avbildingen]] av dataene seg dramatisk. I et radorientert system indekserer kolonneverdier til rader, mens kolonner i et kolonneorientert system avbilder rader til kolonneverdier.<ref>{{Kilde www|url=http://www.databasecolumn.com/2008/07/debunking-another-myth-columns.html|tittel=Debunking Another Myth: Column-Stores vs. Vertical Partitioning|arkiv-url=https://web.archive.org/web/20081204091753/http://www.databasecolumn.com/2008/07/debunking-another-myth-columns.html|arkivdato=4. desember 2008|etternavn=Daniel Abadi|forlag=The Database Column|url-status=dead}}</ref> Dette kan virke subtilt, men forskjellen kan sees i følgende vanlige modifikasjon i samme lager der de to "Moen"-instansene ovenfor komprimeres til en enkelt instans med to <code>rad_id</code>-er:
 …;Nilsen:001; '''Moen:002,004''' ;Jørgensen:003;...
Hvorvidt et kolonneorientert system vil være mer effisient i drift avhenger sterkt av at arbeidsmengden blir automatisert. Operasjoner som henter all data for et gitt objekt (hele raden) vil være tregere i et kolonnebasert system. Et radorientert system kan hente raden i en enkelt diskavlesning, mens det kreves en rekke diskoperasjoner for å samle inn data fra flere kolonner fra en kolonnebasert database. Imidlertid er disse hele radoperasjonene generelt sjeldne, altså i de fleste tilfeller hentes kun en begrenset delmengde av data. Til et "[[rolodex]]-formål" er det for eksempel langt mer vanlig å samle for- og etternavn fra mange rader for å bygge en liste over kontakter enn å lese alle data for en enkelt adresse. Dette vil gjelde enda mer når det kommer til å skrive data inn i databasen, særlig hvis dataene har en tendens til å være glisne (''sparse'') med mange valgfrie kolonner. Av denne grunn har kolonnelagre vist utmerket ytelse i den virkelige verden til tross for mange teoretiske ulemper.<ref>{{Kilde www|url=http://www.cs.yale.edu/homes/dna/talks/Column_Store_Tutorial_VLDB09.pdf|tittel=Column-Oriented Database Systems|etternavn=Stavros Harizopoulos}}</ref>

[[Partisjon (database)|Partisjonering]], [[Databaseindeks|indeksering]], hurtigbufring, [[Visning (database)|visninger]], [[OLAP-kube|OLAP-kuber]] og [[Online transaksjonsprosessering|transaksjonssystemer]] som [[Loggføring med fremskrivning|forutgående logging]] eller [[multiversjons samtidighetskontroll]] påvirker alle dramatisk den fysiske organiseringen av begge systemene. Når det er sagt er [[Online transaksjonsprosessering|OLTP-rettede]] RDBMS-systemer ofte mer radorienterte, mens [[Online analytisk prosessering|OLAP-rettede]] systemer er en balanse mellom radorienterte og kolonneorienterte.