Database optimering - Indeks Alle kender til dette irritations moment, hvor programmet man sidder og arbejder med, bare ikke er hurtigt nok. Selvom det kun drejer sig om få sekunder man sidder og venter, virker det stadig som en evighed, man bliver frustreret og begynder og råbe op om, at det da også er et lorte program. Der er mange faktorer der spiller ind, for at få et program til at arbejde hurtigere. En af disse faktorer er databasen, derfor vil der i denne opgave blive gået i dybden med, hvordan man kan optimere ens database, så denne arbejder hurtigere, og man derved mindsker vente tiden. Databasen er der hvor alle informationerne bliver gemt, det er også fra den man henter informationerne, så derfor er det ofte databasens arbejde med sidder og venter på. Der findes mange måder hvorpå man kan optimere ens database. Jeg har i opgaven valgt at fortælle om indeks til database. Hvad det er, hvordan det kan bruges og hvad fordele og ulemper der er ved det. Eksempler i opgaven vil være lavet ud fra databasen Adventureworks, som er blevet udleveret fra vores underviser. Da jeg har læst rigtig meget forskelligt materiale omkring dette emne, for at få en god forståelse af det, og rapporten ikke er særlig stor, har jeg valgt at undlade fodnoter til kildehenvisning, da det jeg er kommet frem til, ikke er fra et bestemt sted, men fra mange forskellige kilder. Der vil til slut i rapporten være en kildeoversigt, hvor man kan se hvilket materialer der er blevet brugt. Indeks Indeks til database kan sammenlignes, med det indeks vi kender fra en bog, hvor man kan slå op i indekset på et bestemt ord, og derudfra se en reference til steder i bogen, hvor ordet forekommer, og hvor man kan finde resten af informationen. En database kan sagtens fungere uden indeks, det kan en bog også, men hvis man så skal finde noget bestemt, er man nødsaget til at bladre alle sider igennem, dette siger sig selv, at det er meget mere tidskrævende, frem for at slå op i indekset. I en database er man nødt til at lave en tabel scan. Ved små mængde data er kan man sagtens scanne igennem det hele, for at finde frem til det man leder efter. Men ofte indeholder en database store mængder data, og så vil det være enormt tidskrævende, derfor indfører man indeks, for at forbedre performance. Måden hvor på et indeks fungere i en database, er at der bliver lavet en såkald indeksfil. Indekset bliver ud fra et felt, eller flere defineret, disse værdier bliver sorteret, og opdelt i en stryktur, ofte i et B-træ struktur. Så når man laver et query, kan dette bruge indekset til hurtigere at finde frem til svaret. Der findes flere forskellige indeks, jeg har valgt at fokusere på disse: Primære indeks dette er et indeks, som basere sig på primære nøglen eller et andet nøgle felt. Da det er nøgle felter der bliver benyttet, må der ikke forefindes dubletter af disse felter, og ved at lave et indeks på dem, kan man nemt se om der opstår dubletter. Side 1 af 10
Sekundære indeks Dette er et indeks, der er defineret på et felt i en databaserelation, som ikke er primær nøglen, men som supplere det primære indeks. Nogle gange har man brug for at kunne lave en hurtigt søgning, på et felt som ikke er primære nøgle, og det er så her det sekundære indeks kommer ind i billedet. Et eksempel, hvis der kigges på Product tabellen, der har man en tabel med alle informationerne til et produkt og man vil søge på produktets listepris, frem for productnummeret. Derfor kan man lave et indeks på listepris. Dog skal man være opmærksom på at, ved at supplere det primære indeks med et sekundær indeks på produktets pris, så øges søgehastigheden, men samtidigt øges pladsforbruget og performance ved ændringer, da det sekundære indeks også skal ændres, når det primære indeks ændres. Der kan godt være flere sekundære indeks på en tabel. Clustering indeks Et almindeligt (non-clustered) indeks gemmer en indeks key og en reference. Hvis vi tænker tilbage i starten hvor et indeks bliver sammenlignet med et bog indeks, så er bog indekset også et non-clustered indeks. Et clustering indeks kan derimod sammenlignes med en telefonbog. Her er data erne sorteret efter et felt, og det samme felt benyttes så til at lave indekset med. Hvis man for eksempel ser på en telefonbog, hvis man finder personens navn som man søger, så har man med det samme resten af oplysninger, altså er indekset stadig i tabellen, dette giver en bedre performance, da når man slår op i et clustering indeks, ikke skal følge en reference for at finde resten af informationerne, de ligger der allerede, i forhold til et nonclustered indeks. Derfor er der også en tommelfinger regl, at alle tabeller skal have et clustering indeks. Der kan også kun være et clustering indeks pr. tabel, da en tabel jo ikke kan være sorteret efter to forskellige felter. Når man opretter en primary key, vil der i ms SQL server, automatisk blive oprettet et clustering indeks på dette felt. Hvor den så bruger primary key kolonnen som indeks key. Dog kan et clustering indeks, sagtens være lavet på et andet felt, som ikke er primary key. Opdateres værdien på et indekseret kolonne, kan det være nødvendigt at flytte rækken i forhold til at holde indekset sorteret. Dette sker ved praktisk talt at slette den gamle værdi også oprette den nye, dette medførende en nedsat performance. Fordele ved indeks Som tidligere nævnt er den store fordel ved indeks, at det ikke tager så langt tid at finde frem til det resultat man søger. Der er dog også andre fordele ved indeks. Hvis man for eksempel laver en update, insert, eller delete statement, hvor der er en WHERE i. Dette vil jeg give et eksempel på, hvis jeg for eksempel kører følgende query: Dette query laver en update på salasordetdetail, hvor den dividere unitpricen med 2, hvis UnitPrice er lig med 53.99. Hvis query en bliver kørt uden indeks, før man et resultat der siger: Side 2 af 10
Dette siger ikke meget i sig selv, så jeg prøver nu at lave et indeks på unitprice, det ser således ud: Altså bliver der lavet et Non-clustered indeks på UnitPrice, med navnet SalesOrderDetail. Efter at have lavet indekset, vil jeg prøve at kører den tidligere query igen, dette giver følgende resultat: Side 3 af 10
Når man sammenligner de to resultater, kan man se der er en kæmpe forskel. Ved det først query uden indeks er der en estimated subtree cost på 1.049, hvor den er med indeks kun 0.007, det er jo en kæmpe forskel. Der ses tydeligt at indekset gør en forskel. Det samme er gældende hvis man laver en query statement med ORDER BY kommando, samt GROUP BY. Hvordan er det så queryen udnytter indekset. Hvis man ser øverst i de gule bokse, ved den første, da er det et indeks scan der er blevet fortaget, og ved den anden er det et indeks seek. Forskellen på disse to ting er, at ved indeks scan, scanner den hele tabellen igennem, og finder frem til dem der skal opdateres. Ved et indeks seek, da benytter den indekset, og ved hjælp af det, finder den frem til de rækker der skal opdateres, og behøver derfor ikke bruge tid på at scanne alt igennem. Dense og Sparse Der findes to typer af hvor meget et indeks indeholder, enten Dense eller Sparse. Dense da er alle søge felterne med i indekset. Altså når det er et dense indeks, så indeholder det værdien af søge feltet, samt en reference til den aktuelle placering af alle informationer. Et dense indeks vil se således ud, hvis man for eksempel har en kunde tabel, og man tit søger over hvilke byer kunderne kommer fra, kan man lave et indeks over byerne, et sådan dense indeks, vil se således ud: Man kan se indekset, som indeholder alle byerne der er sorteret efter alfabetiskorden. (*) symbolisere den reference den har, til hvor man finder resten af informationerne. Når man kommer over i datafilen kan man se, at indeksen har alle søgefelterne med, dog har indekset ikke dobbelt af samme navn, så da må man søge igennem dem. Som man for eksempel kan se Side 4 af 10
ved byen London. ( ) som ses udfor bynavne, repræsenterer de manglende værdier, som hører til bynavnet. Sparse da er der kun nogle af værdierne der er med i indekset. For en lettere forståelse af sparse indeks, vil jeg lave samme eksempel som ved dense indeks. Så hvis vi igen ser på en kunde tabel, så kan man lave et sparse indeks, som ser således ud: som man kan se på figuren, så indeholder et sparse indeks kun nogle af søge felterne, den indeholder et søgefelt til hver blok. Det fungere på den måde, at hvis man for eksempel skal finde Roskilde, så kigger man ned i indekset, og ser at det må ligge mellem Odense og Århus, så tager den, den første af dem og følger referencen videre, og der er der en henvisning ned til Roskilde. På denne måde kan man undgå at lave indekserne store, så de kun lige har de nødvendige data i sig. Dense indeks er hurtigere end sparse indeks, da man ved et dense indeks ikke skal følge nogle referencer, da kommer man med det samme frem til resultatet. Men sparse indekset som tidligere nævnt, er det mindre end dense indekset, og derfor kræver det ikke så meget plads. Så det er et spørgsmål om, om man vil have hurtighed frem for mindre pladsforbrug, når man skal vælge mellem de to. Multilevel indeks Et andet problem ved indeks, er at de gennem tiden kan vokse sig rigtig store, og så bliver det også tidskrævende at søge i, og derved opnår man ikke den samme reducering af performance længere. Dog er der en måde til at afhjælpe dette på, nemlig det man kalder multilevel indeks. Dette går ud på, at det store indeks bliver splittet op til nogle mindre indeks. Da det første Side 5 af 10
indeks(level1) er et sorteret indeks i forvejen, kan man lave et indeks på det(level2 indeks). Jo større indekset er, jo flere level kan man have. På nedenstående figur kan man se et visualiesering over et 2 level indeks, for at få en bedre forståelse. Som sagt så viser figuren et 2 level indeks. Level 1 er det oprindelige indeks, og hvor level 2 er et indeks til oprindelige indeks. Som det ses er de sat op som en træstruktur. (*) i de to første kolonner repræsentere referencen til det sted man skal hen. Den sidste kolonne repræsenterer datafilen, ( ) i datafilen repræsenterer de tilhørende felter som passer til tallet. Multilevel indeks, fungere så på den måde, lad os sige vi skal finde frem til nummer 41. Så slår man op i det første indeks, og hvis man ikke direkte finder tallet 41, så finder den det tal der er mindre end 41, men hvor det næste tal i rækken er stører. I denne situation når vi frem til nummer 27. Fra nummer 27 gives der en reference videre til det næste indeks, her foregår det på samme måde, som det foregående, og her er det så nummer 38, der bliver fundet, og sender os så videre til hvor vi kan finde resultatet. Dog er det et problem med disse multilevel indeks, når man skal opdatere, sletter eller indsætte, så er det alle indeks det skal gøres på, så igen vil det gå udover performance. Side 6 af 10
Eksempel Jeg har valgt at inddrage et lidt større eksempel på brug af indeks, da jeg synes min rapport mangler nogle generelle eksempler. Da jeg sad og legede med indeks, prøvede jeg alt muligt forskelligt, og jeg synes dette eksempel igen gir et godt eksempel på hvordan indeks er brugbart. Jeg lavede følgende query: Altså går den ind og finder SalesOrderID, SalesOrderNumber, samt UnitPrice i tabellen SalesOrderHeader. Dog findes unitprice ikke i denne tabel, så derfor bliver der lavet en INNER JOIN med tabellen SalesOrderDetail, hvor SalesOrderID fra SalesOrderHeader er lig med SalesOrderID fra SalasOrderDetail tabellen. Dog skal den kun finde dem hvor Unitprice er mellem 500 til 1000. Hvis jeg kører denne query uden indeks, kommer følgende resultat: Hvis jeg så laver følgende indeks på unitprice: Side 7 af 10
Jeg inkludere SalesOrderID, da indekset så allerede er endnu mere sorteret, og tilpasset til query en der skal benytte den. Hvis jeg kører query en efter jeg har oprettet dette indeks, får jeg følgende resultat: Igen kan man se en kæmpe forskel på estimated subtree cost, Hvor den uden indeks er på 1.049 og med indeks 0.037. Igen kan man også se, at uden indeks, da er det et indeks scan der bliver udført, hvor der med indekset bliver udført et indeks seek. Ulemper ved indeks: Som ved alt andet, er der også ulemper ved indeks. Opdatering af et indekseret felt tager længere tid, idet indekserne skal sorteres på ny, hver gang der tilføjes eller ændres i feltets værdi. Samt fylder indeksene. Det betyder ikke så meget hvis det er tal og dato-felter, men hvis det er tekstfelter som der bliver indekseret på, så bliver felterne både gemt i tabellen, men også i indekset, og optager derfor meget mere plads. Dette kan medføre en nedsat ydeevne på en maskine med for lidt hukommelse. Jeg vil lige give et eksempel, hvor det ikke er en fordel at benytte indeks. Jeg bruger følgende query: Side 8 af 10
Den går altså ind på tabellen salesorderdetail og opdatere Unitprice, først ved at gange med 2, og derefter ved at dividere med 2. Jeg har valgt dette, da det egentligt udligner hinanden de to opdate, men det ved databasen ikke, og bruger derfor tid på at kører begge opdate. Hvis jeg kører denne uden indeks, giver det følgende resultater: Hvis jeg laver det samme indeks, som jeg lavede i forrige eksempel på unitprice, og derefter kører query en igen, får jeg følgende resultat: Her kan man altså se at det er omvendt med resultatet. Da er estimated subtree cost meget mindre på query en uden indeks, hvor den er 9.52 og hvor den med indeks er 31.33, så der er virkelig en forskel. Side 9 af 10
Konklusion Ud fra den ovenstående gennemgang, kan man se at man altså skal bruge indeksering med varsomhed. Der er både fordele og ulemper ved indeks. Nogle ting man kan huske ved indeks er at felter, som benyttes som nøgler (både primære og sekundære) bør altid indekseres. Hvis der ofte sorteres efter et bestemt felt, kan det kvalificere feltet til at blive indekseret. Endelig skal der helst ikke ske for megen opdatering på kraftigt indekserede tabeller. Man skal altid gå ind og lave en vurdering på, om det vil hjælpe query en ved at have et indeks, eller om det vil sløve query en. Kildehenvisning: http://www.interspire.com/content/articles/34/1/introduction-to-database-indexes http://en.wikipedia.org/wiki/index_(database) http://odetocode.com/articles/70.aspx http://www.version2.dk/leksikon/indeks http://wps.aw.com/wps/media/objects/7095/7265991/appendices/appendixf.pdf http://www.cc.gatech.edu/classes/ay2005/cs4400_spring/ench14.pdf http://www.cs.sfu.ca/cc/354/zaiane/material/notes/chapter11/node5.html#section0011 21100000000000000 Aflevere af: Malene M. B. Jacobsen DM08207 D. 08.06.10 Side 10 af 10