Intelligent databasedesign er nøglen til performance og sikkerhed i din it-platform

04-08-2016

Dine datamængder eksploderer. Stadig flere af dine systemer taler sammen på tværs. Og du kan ikke nøjes med at skrue op for hardwaren for at øge performance.

Hjertet i mange af forretningens applikationer er databasen, som skal være tilgængelig altid. Derfor er databasedesign nøglen til både høj tilgængelighed og effektiv sikring af dine helt centrale data.

Det er slut med de dage, hvor det nemmeste for at optimere en database var at købe større hardware. For hvor langsom hardware engang spændte ben for hastigheden, har introduktionen af flash-storage nu sænket disk-hastighederne fra millisekunder til mikrosekunder og effektivt elimineret diskussioner om storage performance. Samtidig vokser de datamængder, som databaserne skal holde styr på, og det komplicerer både backup og mulighederne for restore. Til sammen betyder det, at databasedesign bliver afgørende for, at dine databasedrevne it-løsninger forbliver hurtige, stabile og sikre.

Storage er ikke længere en forhindring
Hurtige svartider er essentielt for en database, og det sted, hvor der er mest at vinde, er på storage-hastigheden. Men hvor der engang var flaskehals, kan der i dag bygges motorvej med flashbaseret storage. Det gælder også i Itadels to nye datacentre, hvor gammeldags diske er pillet helt ud af rackskabene til fordel for flash.

- Fordi disken tidligere var en flaskehals for hastigheden, så har mange ikke optimeret deres databasedesign. Nu har vi elimineret den flaskehals med flash-baseret storage, og så dukker flaskehalsene op nye steder, forklarer Martin Holevang, der er chef for Continual Service Improvement og specialist i drift af databaser i Itadel.

- Det stiller helt nye krav til designet af databasen, altså til den måde man har lavet sit skema på. Hvor mange tabeller skal jeg røre ved på samme tid for at få data tilbage? Har jeg indekseret dem ordentligt, så jeg får en hurtig og effektiv svartid? Det er alfa og omega det her, og det er det, der betyder noget fremadrettet. Alle de steder vi ser performanceproblemer, er vi inde og evaluere databasedesignet, for det er ikke længere et spørgsmål om hardware-tuning, fortæller Martin Holevang.

Begrænsningerne i hardwarens performance har historisk været ret tydelige og forholdsvis nemme at optimere. Men når hardwaren ikke længere er et værktøj, man kan gribe til, hvad gør man så for at analysere sig frem til databasens access patterns og spotte problemer med concurrency (samtidig adgang til samme data)?

- Vi har set eksempler på store databaseløsninger, hvor hardwaren, der driver databaserne, koster millioner og har flere terabyte ram, men det hjælper bare ikke, når hovedparten af brugere samtidig efterspørger på de samme 8 kilobyte i databasen. Det lægger hele systemet ned. Det sker, fordi man ikke har forudset den rækkefølge, hvori tingene tilgår hinanden, samt hvorledes det skalerer, forklarer Martin Holevang.

Din databasemand skal favne bredere
Forhindringerne for at få en effektiv database udvikler sig, og derfor skal din databaseadministrator også have bygget på. Det kræver nye metoder og kvalifikationer at byde ind i en kompleks situation med enten design eller fejlretning af databasen.

- Den tid en administrator plejer at bruge på optimering af hardwaren, skal i stedet bruges på sparring og wait analyse. Hvor gør det ondt, og hvorfor gør det ondt? Vi skal ikke troubleshoote i hardwaren, hvis det vi sidder og venter på er låsninger, der kan udbedres ved at designe forespørgsler til databasen anderledes. Det er der stadig færre, der kan, og det er blevet en meget større del af det at administrere en database, siger Martin Holevang.

Databaseadministratorens rolle som specialist med tætte bånd til generalisterne får også indflydelse på de platforme, som databasen skal køre på. Og så skal der tages stilling til håndtering af de massive mængder data, der hober sig op.

- Hvornår begynder du at kigge ind i at opdele og komprimere data, så de ikke fylder så meget? En 100TB database kan man sagtens bygge, og det er der også mange, der har, men sådan en laver man ikke restore på. Det vil tage lang tid, ligegyldigt hvor god en backupløsning du har. Og så er det i sig selv en udfordring at arbejde med så store datamængder over lang tid. Har dine systemer behov for en to-centret løsning, eller er ét datacenter tilstrækkeligt? De spørgsmål skal der hele tiden svares på, når databasen udvikler sig, forklarer Martin Holevang.

Hvad kan du undvære, og hvor længe kan du undvære det?
En del af det at designe din database rigtigt handler om at blive klar over, hvilke datatyper, du arbejder med, hvilke systemer, der bruger dem, og så skal de risikovurderes: Hvad kan du godt undvære i perioder, og hvad skal være tilgængeligt altid og hele tiden?

Det fysiske design handler om, hvilke tabeller, der ligger i hvilke filer, men når man opretter nye tabeller i sin database, så sker det som oftest fra den applikation, man bruger. Derfor skal databasedesignet strække sig ind i de applikationer, der arbejder med databasen.

- En optimering kunne være at placere sine data efter år i databasen. Det giver den fordel, at når et system er langsomt eller nede, så kan kan det lade sig gøre at optimere efter de vigtigste data først. Det er ofte vigtigere at få 2016 tal ind med det samme, end at kunne lave rapporter fra 2013. Den slags fokus kan man udnytte, hvis designet er på plads. Man kan leve med at mangle to år gammel ordrehistorik i en periode, men man kan ikke leve med, at der ikke kan afgives nye bestillinger, siger Martin Holevang.

Du skal kunne udfordre dine forretningskritiske applikationer
Et af de centrale steder, hvor strukturen i en database bliver udfordret, er fra de applikationer, der bruger og tilfører data, som ERP, CRM og tilpassede applikationer. For det er langt fra sikkert, at applikationen bygger en database, der er optimal i forhold til tilgængelighed og som styrker it-sikkerheden.

- Du skal være i stand til at udfordre din applikationsleverandør på, hvad de vil være med til. Det viser sig ofte, at applikationen ikke tillader de ting, du helst vil gøre for være sikker på, at databasen altid er tilgængelig. Måske er applikationens high-availability proces 10 år gammel. Så er det vigtigt, at leverandøren begynder at tænke den slags forbedringer ind i deres road map, siger Martin Holevang.

Rigtig ofte er der stor forskel på den bedste måde at drive en database på, og de krav og restriktioner som applikationen dikterer.

- Sådan et mismatch vil der næsten altid være. Vi trækker på vores erfaringer med drift af flere tusinde database-servere, når vi anbefaler, hvordan en database drives bedst. Applikationspartnere fokuserer på deres applikation, og måske mindre på databasedesign og disaster recovery. Derfor er du udfordret af det, siger Martin Holevang.

Gør databasen klar til at skalere ud – ikke kun op
Langt de fleste databaser er bygget til at skalere opad, når de vokser. Men det er ofte mere effektivt, at designe databasen efter at kunne skalere ud, for at øge sikkerheden og gøre løsningen robust. Altså udvide med flere databaser, frem for bare at fylde på den samme. Det viser sig navnlig, når vi taler om meget store databaser.

- Den kunst er der ikke så mange, der har prøvet, og derfor er det svært. Men det hjælper meget, når du skal genskabe systemet, eller når du har problemer med en systemtabel, forklarer Martin Holevang.

- Hvis du baserer en applikation på flere databaser frem for én stor, så er det sandsynligvis kun en lille del af ens totale database, der er nede, eller som lider af availability- eller performanceproblemer på ét tidspunkt. Og så er der kun en del, der skal troubleshootes og eventuelt genskabes. Det betyder også, at slutbrugeren ofte kan arbejde videre. Det kan være forskellen på, at hele din løsning er utilgængelig og til, at det måske bare er en enkelt funktion, der er nede, siger Martin Holevang.

Der er også øget availability at hente ved intelligent at planlægge placeringen af databaser over for de systemer, der bruger dem.

- Du skal tænke meget over, hvilke data, der altid skal være tilgængelige, og hvis du har mange integrationer og afhængigheder mellem systemer, så tænk over at placere disse systemer sammen i systemlandskabet, anbefaler Martin Holevang.

Designet fungerer som sikkerhedsnet
Fordi datamængderne eksploderer, betyder det også, at databaser kan blive meget store. Det giver nye udfordringer, i forhold til at sikre data, og gør det svært at gribe til restore som en reel mulighed.

- Når vi kommer op i systemer med mere end 10 terabyte data, så taler vi ikke længere om, at man skal genskabe databasen ved nedbrud. Så skal man beskytte sig på andre måder. For selv i mindre tilfælde, hvor du kan restore på en time eller to, så er det stadig al for lang tid at være nede for nogle systemer, forklarer Martin Holevang.

Det er dyrt og besværligt at håndtere store datamængder med backup, og selv hvis det lykkes at genskabe en database, er det langt fra sikkert, det er den bedste løsning. Men hvis man ikke har tænkt sit design igennem, kan det være den eneste løsning, man har til rådighed.

- Vi har set eksempler på databaser med korruption, der ville betyde, at hvis vi genskabte data til før fejlen opstod, ville det koste kunden måneders tabt indtjening i næste faktureringscyklus, fordi det salg, kunden havde i mellemtiden, ville blive overskrevet. Det må jo ikke ske. Det kan lade sig gøre at tænke en løsning på det ind i designet og applikationen, forklarer Martin Holevang.

Så hvis du har designet din database rigtigt og har kompetencerne, så er der både meget billigere og hurtigere måder at komme online på igen, end ved blind restore.

- Du kan for eksempel tage en kopi af databasen og nøjes med intelligent at genskabe de dele, der mangler, hvis du har erfaringen. På den måde genskaber du de historiske data, og du kan beholde de aktuelle tal. På den måde kommer din forretning langt hurtigere og mere sikkert tilbage fra nedetid, vurderer Martin Holevang.