DBS18 - Strategier for Query-prosessering

Transkript

1 Side 1 for Databaser DBS18 - Strategier for Query-prosessering søndag 22. mai Pensum , side , unntatt og En spørring som blir skrevet i et høynivå-språk, må bli scannet, altså å identifisere de ulike typene ord i spørringen (sql-ord, attributtnavn, tabellnavn); parset, å sjekke at syntaksen er riktig; og validert, sjekke at attributtnavn og tabellnavn faktisk eksisterer. Spørringen får deretter en intern representasjon, ofte i form av en spørringstre, eller en spørringsgraf (DAG). Deretter må databasehåndteringssystemet planlegge en kjøringsstrategi, eller spørringsplan. Det finnes mange forskjellige kjøringsstrategier, og å velge en god en kalles spørringsoptimalisering. Spørringsoptimaliseringsmodulen velger en kjøringsstrategi, og kodegeneratoren genererer kode for å kjøre planen. Runtime Database-prosessoren kjører selve koden Oversette SQL-spørringer til relasjonsalgebra og andre operatorer Spørringer blir tolket som "select-from-where-group by-having"-blokker, så hvis en spørring er nøstet, må man identifisere de ulike blokkene, og deretter gjøre dem om til relasjonsalgebrauttrykk. Når man har identifisert blokkene, så velger spørringsoptimalisereren en kjøringsplan Semi-join og anti-join Semi-join blir brukt for å nøste opp EXISTS, IN og ANY-delspørringer. Hvis man utgjør en semi-join på tabellene T1 og T2 (T1 til venstre), vil den returnere en rad av T1 hvis det finnes en match i T2, og deretter stoppe - den vil altså ikke returnere alle treff den finner, i motsetning til inner join. Anti-join blir brukt for å nøste opp NOT IN, NOT EXISTS og ALL-delspørringer. Hvis man utgjør en anti-join på tabellene T1 og T2 (T1 til venstre), vil en rad i T1 ikke bli med hvis det finnes en match i T2 - altså blir raden returnert kun hvis det ikke finnes en match i T Algoritmer for ekstern sortering Ekstern sortering brukes på store filer som er lagret på disk, og ikke får plass i minnet. Man bruker en sortér-flett-strategi, som går ut på at man sorterer delfiler, kalt "runs", som deretter blir flettet sammen i større sorterte filer. Denne måten å sortere på krever buffer-plass i hovedminne for å utføre den faktiske sorteringen. I bokas algoritme har hvert buffer samme størrelse som én diskblokk. I sorteringsfasen blir deler (runs) av filen som får plass i bufferne lest inn i minnet, sortert ved hjelp av en intern sorteringsalgoritme og skrevet tilbake på disk som en midlertidig sortert delfil. Hvor mange runs som trengs er avhengig av antall filblokker og mengden ledig bufferrom: Eventuelt (hvis du antar at størrelsen på ett buffer = størrelsen på én filblokk):

2 Side 2 for Databaser I flettefasen blir de sorterte "runs"-ene flettet sammen i en eller flere flettepass. Graden av fletting er antallet sorterte delfiler som kan flettes sammen i hvert flettesteg. Ved hvert steg trengs en bufferblokk for hver diskblokk som skal flettes sammen, og det trengs en bufferblokk der resultatet skal lagres, der resultatet vil være større. Antall flettepass blir: Ytelse: Følgende formel er en tilnærming til ytelsen: Der b er antall blokker. I sorteringsfasen blir hver blokk aksessert to ganger, en for å lese og en for å skrive. I hvert flettesteg blir et antall blokker ca. likt de originale blokkene også aksessert to ganger Algoritmer for ekstern sortering Implementasjon av SELECT-operasjon Søkemetoder for enkel seleksjon: Lineært søk hent alle poster og sjekk om attributtverdier tilfredsstiller søkebetingelse. Binært søk hvis søkebetingelsen går på likhet og postene er sortert. Primærindeks hvis det er en likhetsbetingelse på et nøkkelattributt med primærindeks. Hvis det er en større/mindre enn (eller lik)-sammenligning i betingelsen på et nøkkelfelt med primærindeks, finn den som matcher, og deretter alle etter(/på)følgende. Hashnøkkel hvis søkebetingelsen går på likhet på et nøkkelattributt med en hashnøkkel. Bruke en sekundærindeks (b+-tre) Med likhetssammenligning kan dette brukes for å finne én post hvis indeksfeltet er unikt, eller for å finne flere poster hvis det ikke er det. Kan også brukes for verdiområdespørringer (større/mindre enn eller lik). Bruke unclustered B+-tre og heapfil Hvis man søker på indeksfeltet, kan man bruke dette. Da slipper man å åpne heapfilen, siden alle indeksene er i B+-treet Søkemetoder for AND-seleksjoner Det er best hvis det finnes indekseringer, så man slipper og kjøre lineært søk. Når man har AND-er i betingelsene, og flere poster blir returnert (spørringen er ikke basert på nøkkelattributter): Individuell indeks: Hvis det finnes en tilgangssti (access path) på en av attributtene som er brukt i en av betingelsene, kan man finne alle poster som

3 Side 3 for Databaser oppfyller den betingelsen, og deretter sjekke resten. Sammensatt indeks: Hvis det finnes en indeks på sammensatte attributter, der attributtene er med i betingelsene, kan man finne postene som oppfyller betingelsene via indeksen, og deretter sjekke de gjenværende betingelsene. Snitt av postpekere: Hvis flere av attributtene i betingelsene er indeksert (sekundær), og disse indeksene gir en mengde med postpekere, kan man ta snittet av mengdene, og eventuelt sjekke de resterende betingelsene Søkemetoder for OR-operasjon Dette er ikke like enkelt med OR som med AND. For at det skal fungere bra, bør alle betingelser være på attributter som har en indeks - altså, siden det blir en union av forskjellige mengder, kan vi ikke avgrense området, og hvis én av betingelsene ikke inneholder en attributt som er indeksert, må det kjøres et lineært søk Estimere selektiviteten av en betingelse En databasekatalog inneholder følgende informasjon: For hver relasjon (tabell) r, med skjemaet R, der det finnes n tupler: Antallet rader/poster, eller kardinaliteten r(r) Bredden til relasjonen (lengden på hver tuppel) Antallet blokker relasjonen bruker i lagringsområdet. Blokkfaktor, antallet poster per blokk. For hvert attributt A i relasjonen R: Antallet distinkte verdier av A i R Max og min-verdiene til attributtene A i R. Selektiviteten til en betingelse er definert som antallet rader i relasjonen som tilfredsstiller betingelsen ut av hvor mange rader det er i tabellen. Det er ikke alltid slik at man har tilgang til selektiviteten til en betingelse, og da er det mulig å estimere den. Hvis betingelsen for eksempel er basert på en nøkkel, så kan selektiviteten estimeres til å være 1/ r(r). Hvis betingelsen er basert på et ikke-nøkkelattributt med n distinkte verdier, så kan selektiviteten estimeres til å være 1/i, hvis man antar at postene er uniformt fordelt over de distinkte verdiene Implementasjon av JOIN-operasjonen Metoder for å implementere joins Her er bare en beskrivelse av toveis-join. Et join-attributt er en av attributtene det joines på. Nested-loop join Dette er brute-force-versjonen. For hver post i den ene files sjekker den for alle poster i den andre filen om det er en match. Indeksbasert nested-loop join med aksesstruktur for å hente matchende poster Hvis det eksisterer en indeks (eller hash-nøkkel) for en av joinattributtene, si i fil B, så itereres det over fil A, også hentes alle matchende join-attributter direkte fra fil B med indeksen (trenger altså ikke iterere over alle attributter i fil B, de kan hentes direkte). Sorter-flett join Hvis begge filer A og B er fysisk sortert på join-attributtene, kan begge filer scannes samtidig i rekkefølgen til join-attributtene, og matche postene som har like join-attributter. Altså, man trenger kun å gå gjennom filene én gang. Hvis de ikke allerede er sortert, kan de sorteres med ekstern sortering (18.2). Det er også mulig å implementere dette på sekundærindekser, men det kan fort bli mindre effektivt, da postene kan være spredt rundt

4 Side 4 for Databaser på forskjellige blokker, så det blir mange blokkaksesser. Partition-hash join Alle poster i fil A hashes i bøtter med hash-funksjon h. Dette kalles partisjoneringsfasen. For enkelthets skyld antas det at hele fil A får plass i hovedminnet. I den andre fasen, probingsfasen, brukes samme hash-funksjon h på fil B, og hver post fra fil B blir satt sammen med alle matchende poster fra fil A som er hashet i samme bøtte Hvordan bufferplass og valg av OUTER-LOOP-filer påvirker ytelsen til Nested-Loop join Når man skal joine to tabeller med nested-loop join, så har det noe å si hvilken tabell det itereres over i den ytre løkka (outer loop). Hvis man har buffer med plass til n blokker i minnet, så trengs én blokk for resultat-fila og én blokk for inner-loop-filen, ILF. Derfor er det n - 2 blokker tilgjengelig for outer-loop-fila, OLF. For hver gang man leser inn n - 2 blokker fra OLF, må man også lese inn alle blokker fra ILF, og sjekke om noen av postene i ILF matcher med noen i OLF. Hvis videre OLF har x blokker og ILF har y blokker, så antallet innlesninger av blokker fra ILF blir: Antall blokkaksesser blir: Hvis man dermed prøver å joine to filer A og B, der A har 10 blokker og B har 2000, og n = 7. Hvis A er OLF, blir antall blokkaksesser: Hvis B er OLF blir antall blokkaksesser: Hvis i tillegg resultatfilen har z blokker, må det legges til z blokkaksesser for hver gang blokkene skrives tilbake til fil, slik at antall blokkaksesser totalt blir: Hvordan bufferplass og valg av OUTER-LOOP-filer påvirker ytelsen til Nested-Loop join Join-seleksjonsfaktoren er brøkdelen av filer i Inner Loop-fila, ILF, som faktisk vil joines med filer i Outer Loop-fila. Hvis man for eksempel har to filer, Employee og Department, der Employee har 6000 poster lagret i 2000 blokker og Department har 50 poster lagret i 10 blokker. Si videre at man skal joine de to tabellene på avdelingsleder - da vil resultatet inneholde 50 poster, siden det er 50 avdelinger og hver avdeling har én avdelingsleder.

5 Side 5 for Databaser Hvis begge filene har sekundærindekser på join-attributtene med 4 nivåer for Employee, notert e, og 2 nivåer for Department, notert d, og videre at Employee brukes som OLF og Department som ILF. Da blir antall blokkaksesser: I motsetning, hvis Department brukes som OLF og Employee som ILF, blir antall blokkaksesser: Altså, det er mye mer effektivt å bruke Department som OLF, siden den har joinselektivitet lik 1 med hensyn på join-betingelsen (alle rader i Department vil bli joinet), i motsetning til Employee der join-selektiviteten er 50/6000 = 0,0083. Så hvis man skal joine to filer, der det er indeksering for begge join-attributter, er det mest effektivt å bruke den minste fila som OLF.