Databaseudvikling er den del af et system, ingen taler om, før noget er langsomt eller forkert. Det er også den del, der er dyrest at lave om, fordi alt andet bygger ovenpå. Her er de valg, der afgør, om databasen bliver et fundament eller en flaskehals.
Det vigtigste at få rigtigt
- Datamodellen er sværere at ændre end koden. Brug tid på den først.
- Langsomme systemer skyldes næsten altid manglende indeks eller for mange kald — ikke for lidt hardware.
- Mål før I optimerer. Gæt koster både tid og ydeevne.
- Migreringer skal kunne køres igen og rulles tilbage. Ellers tør ingen udrulle.
- Backup uden en afprøvet gendannelse er ikke backup.
- Persondata skal kunne findes og slettes. Det er et designkrav, ikke en opgave til sidst.
Modellen er den beslutning, der binder
Kode kan skrives om på en uge. En datamodel med fem års data i sig kan ikke. Derfor er det værd at bruge længere tid på at forstå, hvad en “kunde”, en “ordre” og en “aftale” faktisk er i jeres forretning, før tabellerne låses.
Det klassiske spørgsmål, der afslører problemer tidligt: kan den samme ting optræde to gange med forskellig status? Hvis ja, hører den sandsynligvis til i sin egen tabel.
Ydeevne er målbar, ikke en fornemmelse
Når noget er langsomt, er årsagen næsten altid en af tre. Der mangler et indeks på det felt, der søges på. Applikationen henter én post ad gangen i en løkke i stedet for alle på én gang. Eller en forespørgsel trækker hele tabellen for at vise ti rækker.
Find den faktisk langsomme forespørgsel med databasens egne værktøjer, før nogen foreslår kraftigere hardware. Mere CPU skjuler problemet i seks måneder og gør det dyrere at finde bagefter.
Indeks koster også noget
Indeks gør læsning hurtigere og skrivning langsommere. På et system med mange opdateringer kan for mange indeks være årsagen til, at det er langsomt. Læg indeks efter de forespørgsler, I faktisk kører — ikke på hvert felt, nogen kunne finde på at søge i.
Migreringer og udrulning
Ændringer i databasen skal ligge i versionsstyring sammen med koden, køres automatisk, og kunne rulles tilbage. Uden det bliver hver udrulning en manuel handling, som én person husker hvordan man laver.
Ved større omlægninger: tilføj det nye felt, skriv til begge, flyt data, skift læsning, fjern det gamle. Fire små trin er langt sikrere end ét stort, og hvert trin kan rulles tilbage alene.
Backup, gendannelse og persondata
Afprøv gendannelsen. Det lyder banalt og er den hyppigste ubehagelige overraskelse vi møder: backup har kørt i to år, men ingen har prøvet at hente data tilbage, og formatet viser sig ubrugeligt.
Persondata kræver desuden, at I kan svare på, hvor en persons oplysninger ligger, og kan slette dem. Ligger de spredt i femten tabeller uden fælles nøgle, bliver det en manuel opgave hver gang. Det er billigere at designe for det.
Når databasen er arvet
De fleste opgaver, vi får, handler ikke om at bygge nyt, men om at forstå noget, der har kørt i ti år. Start med at måle frem for at gætte: hvilke forespørgsler er langsomme, hvilke tabeller vokser, hvor er der data uden ejer.
Skal kodebasen ovenpå også vurderes, hører det under kodeaudit, og skal systemet holdes kørende imens, under softwarevedligeholdelse.
Sådan arbejder vi
Vi arbejder med datamodellering, migrering, optimering og drift som en del af vores databaseudviklingstjeneste, typisk sammen med API-udvikling, når data også skal deles med andre systemer. Skal arbejdet fortsætte over tid, sætter vi et dedikeret udviklingsteam på det.
Ofte stillede spørgsmål
SQL, medmindre I har en konkret grund til andet. De fleste forretningsdata er relationelle, og relationelle databaser håndterer i dag fint både JSON og store mængder. Vælg NoSQL når datamodellen reelt er dokumenter eller hændelser.
Størrelse er sjældent problemet i sig selv. Problemet opstår, når forespørgslerne ikke er skrevet til mængden. Vi ser tabeller med hundrede millioner rækker køre fint og tabeller med tyve tusinde køre elendigt.
Teknisk ofte ja. Men hvis systemet er langsomt i dag, bliver det også langsomt i skyen — bare med en månedlig regning. Ryd op først, flyt bagefter.
Mindst to gange om året, og altid efter større ændringer. Skriv datoen ned, så nogen kan svare på, hvornår det sidst blev gjort.
Hvor I skal begynde
Mål før I optimerer, læg indeks efter de forespørgsler I faktisk kører, versionsstyr migreringerne, og afprøv gendannelsen. Det er ikke spændende arbejde, men det er det, der afgør, om systemet stadig er til at arbejde med om fem år.
Skal vi kigge på jeres database? Skriv til os eller book et møde.
