Nutidens velkendte databaser bygger på ideer, der har 40 år på bagen, så der er plads til forbedringer.
– Mange databasesystemer er bygget op omkring paradigmer fra 1970'erne, og det laver man ikke bare lige om.
Sådan lyder vurderingen fra ph.d.-studerende på IT-Universitetet Rasmus Resen Amossen, som forsker i, hvordan databaser kan gøres hurtigere. Internettet og dets gigantiske tjenester såsom Googles søgninger og Facebooks sociale netværk har sat fokus på, hvordan databaserne kan trimmes og få bedre ydelse.
Et enkelt eksempel er den splinternye database VoltDB, som i nogle tilfælde kan være 100 gange hurtigere end webfavoritten MySQL.
Bag VoltDB står MIT-professoren (Massachusetts Institute of Technology) Michael Stonebraker med mange års databaseerfaring fra for eksempel Postgres. Sammen med andre forskere dissekerede han en open source-database for at se, hvad der egentlig sker under belastning. Det viste sig, at en overraskende stor del af tiden gik med at håndtere logfiler, låsning af rækker og med at have styr på i/o-buffere, mens ganske lidt af processortiden – kun få procent – gik med det egentlige søgearbejde.
– Der bliver sat et kæmpe skib i søen for at lave meget lidt arbejde, siger Rasmus Resen Amossen.
I VoltDB er såkaldte analytiske forespørgsler, som tager lang tid, fravalgt fra starten. I stedet fokuseres på transaktioner, som foretages over kort tid.
– Data tilgås via stored procedures, og derfor kender databasen hele arbejdsbyrden på forhånd.
I stedet for at udføre opgaverne parallelt tager VoltDB opgaverne i serier, og det gør mange ting meget lettere.
Ofte betyder det, at man ikke behøver at føre log over transaktionerne. VoltDB skriver kun til hukommelsen, så behovet for at holde styr på diskbuffere forsvinder også som dug for solen.
– Der er en masse, der kan skæres væk, og i indledende tests fik de et speedup på en faktor 100. Alle de her paradigmer fra 70'erne, hvor meget af det har vi egentlig brug for i vore dage, spørger Rasmus Resen Amossen.
En database til enhver lejlighed
VoltDB bygger på SQL og ligner på den måde de gamle databaser, men mange andre nye databaser er kendt under overskriften NoSQL, der efter behov kan opfattes som 'ingen SQL' eller 'not only SQL', ikke bare SQL. Mange af disse benytter den såkaldte key-value-model, hvor en nøgle peger på en enkelt værdi. Men mange går galt i byen ved at se en klar grænse mellem relationsdatabaser og key-value-modeller. En relationsdatabase kan nemlig godt implementeres oven på en key-value-store. Det nye i de nye databaser er, at de forsimpler ideen om, hvad en database skal kunne. Én størrelse passer nemlig ikke til alle.
– En generaliseret database, der passer til alle behov, er i sagens natur sværere at optimere end en specialiseret, siger Rasmus Resen Amossen.
Facebook benytter sin egen hjemmelavede key-value-database Cassandra.
– Facebook er så kæmpestort, og de skal håndtere en mega-belastning, så hvert millisekund tæller. Der er uhensigtsmæssigheder i de gamle paradigmer, og hvis Facebooks arbejdsbelastning bruger, hvad man kan finde i en key-value-store, så er det jo fint.
En anden ny type database, som Rasmus Resen Amossen synes flere danskere skulle kigge på, er kolonnedatabaser, som er skabt til analytiske opgaver. Ved at gemme data i kolonner i stedet for i rækker er det meget nemmere at udføre såkaldte aggregeringer, som for eksempel at finde summen af alle tal i en kolonne.
– Du kan ofte opnå en kæmpe faktor i speedup ved at flytte data over i kolonnedatabaser, hvis dit workload er analytisk. Det er derfor lidt ærgerligt, at mange ikke kender til de her systemer.
