Redigerer Kolonneorientert database (avsnitt)

== Fordeler ==

=== Aksesstid ===
Sammenligninger mellom radorienterte og kolonneorienterte databaser fokuserer ofte på effisiensen til harddiskaksess for en gitt arbeidsmengde, ettersom [[Søketid|søketiden]] er utrolig lang sammenlignet med andre flaskehalser i datamaskiner. For eksempel har en typisk [[Serial ATA|SATA]]-harddisk en gjennomsnittlig søketid på mellom 16 og 22 millisekunder,<ref>{{Kilde www|url=http://www.tomshardware.com/reviews/wd4001faex-4tb-review,3368-4.html|tittel=Western Digital's 4 TB WD4001FAEX Review: Back In Black|fornavn=Manuel|etternavn=Masiero}}</ref> mens [[DRAM]]-tilgang på en [[Intel Core i7]]-prosessor i gjennomsnitt tar 60 ''nano''sekunder, som er nesten 400 000 ganger så raskt.<ref name="JESD79-3F">{{Kilde www|url=https://software.intel.com/sites/products/collateral/hpc/vtune/performance_analysis_guide.pdf|tittel=Performance Analysis Guide for Intel® Core™ i7 Processor and Intel® Xeon™ 5500 processors|besøksdato=2017-11-10|fornavn=David|etternavn=Levinthal|forlag=Intel}}</ref> Det er tydelig at disktilgang er en stor flaskehals ved håndtering av store data. Kolonnedatabaser bedrer ytelsen ved å redusere mengden data som må leses fra disken, både ved å effisient komprimere lignende kolonnedata og ved å lese bare dataene som er nødvendige for å svare på spørringen.

I praksis er kolonnebaserte databaser godt egnet for [[Online analytisk prosessering|OLAP]]-lignende arbeidsoperasjoner (for eksempel [[datavarehus]]) som vanligvis involverer svært komplekse spørringer over alle data (muligens [[Byte|petabyte]]). Det må imidlertid gjøres noe arbeid for å skrive data inn i en kolonneformatert database. [[Transaksjonsdata|Transaksjoner]] ([[Insert (SQL)|insert]]) må separeres i kolonner og komprimeres etterhvert som de lagres, hvilket gjør kolonnedatabaser mindre egnet for [[Online transaksjonsprosessering|OLTP]]-arbeidsbelastninger. Radorienterte databaser er godt egnet for OLTP-lignende arbeidsbelastninger som er mer beheftet med [[Sanntidssystem|interaktive]] transaksjoner. For eksempel er det mer effisient å hente alle data fra en enkelt rad når disse dataene er plassert på ett enkelt sted (minimerer disksøk), som i radorienterte [[Dataarkitektur|arkitekturer]]. Imidlertid har det blitt hybride kolonneorienterte systemer som er i stand til å håndtere både OLTP- og OLAP-operasjoner. Noen av OLTP-begrensningene prøver slike hybride kolonneorienterte å løse er ved (blant annet) å bruke [[Hovedminnedatabase|datalagring i hovedminnet]].<ref name="OLTP&OLAP">{{Kilde www|url=http://vldb.org/pvldb/vol5/p1424_florianfunke_vldb2012.pdf|tittel=Compacting Transactional Data in Hybrid OLTP&OLAP Databases|besøksdato=1. august 2017}}</ref> Et kolonneorientert system som er egnet for både OLAP og OLTP kan i teorien fjerne behovet for to separate systemer.<ref>{{Kilde www|url=http://www.sigmod09.org/images/sigmod1ktp-plattner.pdf|tittel=A Common Database Approach for OLTP and OLAP Using an In-Memory Column Database|besøksdato=1. august 2017}}</ref>

=== Komprimering ===
Siden dataene i en kolonne er av enhetlig type har kolonneorienterte data noen muligheter for optimering av lagringsstørrelse som radorienterte data ikke har. For eksempel bruker mange{{Hvem}} populære moderne komprimeringsmetoder som [[Lempel–Ziv–Welch|Lempel–Ziv–Welch-kompresjon]] eller [[løpelengdeenkoding]], som er algoritmer som utnytter likheter mellom nærliggende data for å komprimere. Manglende verdier og gjentatte verdier (som er vanlige i kliniske data) kan representeres av en 2-bits markør.<ref name="TODS2">{{cite journal|title=A Modular Self-describing Clinical Database System|author1=Stephen Weyl|author2=James F. Fries|author3=Gio Wiederhold|author4=Frank Germano|journal=Computers and Biomedical Research|year=1975|doi=10.1016/0010-4809(75)90045-2|volume=8|issue=3|pages=279–293|pmid=1157469}}</ref> Selv om de samme teknikkene kan brukes på radorienterte data vil de typisk oppnå mindre effektive resultater.<ref>{{Kilde bok|tittel=Column-stores vs. row-stores: how different are they really?|etternavn=D. J. Abadi|etternavn2=S. R. Madden|etternavn3=N. Hachem|verk=SIGMOD’08}}</ref><ref>{{cite arXiv|first=N|last=Bruno <!-- URL not supported by cite arXiv |url=http://www-db.cs.wisc.edu/cidr/cidr2009/Paper_2.pdf -->|title=Teaching an old elephant new tricks|year=2009|eprint=0909.1758|class=cs.DB}}</ref>

For bedre komprimering kan sortering av rader også hjelpe. For eksempel ved å bruke [[Bitmap-indeks|punktgrafikkindekser]] kan sortering forbedre komprimeringen med en god størrelsesorden.<ref>Daniel Lemire, Owen Kaser, Kamel Aouiche, [[arxiv:0901.3751|"Sorting improves word-aligned bitmap indexes"]], ''Data & Knowledge Engineering'', Volume 69, Issue 1 (2010), pp. 3-28.</ref> For å maksimere komprimeringsfordelene til den [[Leksikografisk orden|leksikografiske rekkefølgen]] med hensyn til løpelengdeenkoding er det best å bruke kolonner med lav [[kardinalitet]] som de første sorteringsnøklene.<ref>Daniel Lemire and Owen Kaser, [[arxiv:0909.1346|Reordering Columns for Smaller Indexes]], Information Sciences 181 (12), 2011</ref> For eksempel gitt en tabell med kolonnene kjønn, alder, navn, ville det være best å sortere først på verdien kjønn (kardinalitet av 2), deretter alder (kardinalitet <128), deretter navn (høy [[Kardinalitet (datamodellering)|kardinalitet]]).

Kolonnekomprimering oppnår redusert diskplass på bekostning av effisiens ved henting. Jo større komprimering som oppnås mellom nærliggende data, desto vanskeligere kan tilfeldig tilgang bli, ettersom data kanskje må dekomprimeres for å kunne leses. Derfor blir kolonneorienterte arkitekturer noen ganger beriket med tilleggsmekanismer med sikte på å minimere behovet for tilgang til komprimerte data.<ref name="Infobright">{{Kilde konferanse|url=http://www.vldb.org/pvldb/1/1454174.pdf}}</ref>