Side 1 for Databaser DBS16: Disklagring, filstrukturer, hashing onsdag 11. mai 2016 21.26 Pensum: Kapittel 16.116.8, side 541580, men ikke fra dynamic hashing og forover. 16.1 Introduksjon 16.1.1 Minnehierarki og lagringsmedium Beskriver forskjellige typer lagring (primær, sekundær og tertiær). 16.1.2 Lagringsstruktur til databaser Databaser lagrer data permanent på disk, og dette kalles persistent data. Why? For mye data til å lagres i hovedminnet, minnet er ikkevolatilt, og det er 1000 billigere. Primær filstruktur, hvordan postene fysisk er lagret på disk: En heapfil plasserer postene (records) i tilfeldig rekkefølge, etter hverandre (append). I en sortert fil blir postene sortert etter en verdi (for eksempel en av attributtene). En hashfil bruker en hashfunksjon til å bestemme hvor i fila postene skal ligge. Andre typer filer: Trestrukturer, Btrær. Sekundær struktur gir mulighet for å effektivt få tilgang til postert basert på andre felter enn de som er brukt i den primære filorganisasjonen. 16.2 Sekundære lagringsmedium 16.2.1 Hardwarebeskrivelse av diskenheter Beskriver hvordan en magnetisk disk er satt opp (veeeldig teknisk), se denne:
Side 2 for Databaser Data lagret på samme sylinder går mye fortere å hente opp, enn om dataen er distribuert på forskjellige sylindere: Når man leser fra eller skriver til en harddisk, leses eller skrives en blokk til eller fra minnet av gangen. Det er også mulig å lese inn flere blokker, og dette kalles et cluster. En blokk er en del av en sirkel, kalt en track (der sirkler oppå hverandre danner en sylinder) så tracks er delt opp i blokker, med noe greier i mellom kalt interblock gaps. Blokker har en fast størrelse som blir satt ved diskformattering. Skrive til/lese fra: Søketid + roteringsforsinkelse + blokkoverføring Det som tar tid er søketiden (tiden det tar å flytte armen til riktig sylinder) og roteringsforsinkelsen (tiden det tar å rotere disken til riktig posisjon under armen). Til sammenligning tar det ikke så lang tid å overføre blokken, derfor er det vanlig med filstrukturer der relatert data ligger på samme sylinder eller track. Typisk tid ligger fra 9 til 60 millisekunder, og er den store flaskehalsen i databaseapplikasjoner. 16.2.2 Teknikker for å gjøre dataaksess mer effektivt Buffering av data, ny data legges i minnet mens gammel data prosesseres. Relatert data ligger på etterfølgende blokker, og hvis det trengs flere sylindere trengs, brukes etterfølgende sylindere. Innlesing av data før forespørsel hvis en blokk blir lest, blir etterfølgende blokker også lest. Fungerer bra for applikasjoner som antageligvis vil lese etterfølgende blokker. Hvis flere blokker skal leses, gjøres dette på en måte slik at total aksesstid blir minimert, for eksempel ved at armen slipper å bevege seg fram og tilbake. Bruk av loggdisker som kan holde på skrevet informasjon midlertidig alle blokker som skal skrives til disk, blir skrevet til loggdisken, og deretter til harddisken. Bruk av SSDer eller flashminne for gjenoppretting: data skrives til SSD eller flashminne under kjøring av applikasjon, og når disken "ikke har noe å gjøre", skrives dataen fra SSD eller flashminne og til disken.
Side 3 for Databaser 16.2.3 SSDer Senere trend er å bruke SSD et mellomlag mellom minnet og HDD (magnetisk tape). Går mye fortere. Er mye dyrere. 16.2.4 Magnetisk tape Magnetisk tape har ikke tilfeldig aksess, men sekvensiell aksess, så det går kjeeempetreigt. Men veldig mye data kan lagres på magnetisk tape, så det er typisk brukt som backup databaser blir regelmessig skrevet til tape, skulle disken bli ødelagt. Noen applikasjoner bruker også tre disker der hele databasen blir lagret, og bytter mellom disse tre, slik at en disk blir brukt som backup. Det kan også funke å lagre databaser som sjelden blir brukt eller som blir lagret av historiske grunner på magnetisk tape. 16.3 Bufring av blokker Hvis flere blokker skal leses inn i minne, og alle blokkadresser er kjente, kan flere buffer bli reservert i hovedminne for å få det til å gå fortere. Bufring er mest effektivt hvis det kan kjøres parallelt med prosesseringen av dataen, altså hvis det eksisterer flere prosessorer eller en separat disk I/Oprosessor. Da kan prosessoren begynne med prosessering av data, samtidig som (for eksempel) I/Oprosessoren leser inn neste blokk. Dette kalles dobbel bufring. 16.3.1 Bufferbehandling Buffer en del av hovedminnet som er ledig og kan motta blokker fra disk. Bufferbehandling er en del av et databasehåndteringssystem (DBMS), som svarer på forespørsler om data og bestemmer hvilke buffer i minnet som skal brukes. Det er to typer bufferbehandlere en som behandler buffer i hovedminnet og en som behandler buffer i virtuelt minne, slik at kontrollen kan overføres til operativsystemet. Målet til en bufferbehandler er å 1) Maksimere sannsynligheten for at en blokk ligger i minnet 2) Hvis bufferet er fullt, så må en blokk i minnet erstattes, som er lite sannsynlig at skal brukes igjen. Informasjon som en bufferbehandler holder styr på: 1) Pincount: Antall ganger en blokk har blitt spurt etter, eller antallet brukere som bruker blokken. Pinning er å inkrementere pincounten. En unpinned blokk har pincount lik 0. 2) En dirty bit som initielt er satt til 0, og blir satt til 1 hvis en blokk blir oppdatert. Når bufferbehandleren fjerner blokker fra bufferet, sjekker den at blokken er unpinned, og hvis dirty bit er 1, skrives blokken tilbake til disk. Hvis dirty bit er 0 trenger den ikke skrive blokken tilbake. Hvis det ikke er noen unpinned blokker i bufferet, så bufferbehandleren vente. En transaksjon går da enten i ventemodus, eller så kan den aborteres. 16.3.2 Buffererstatningsstrategier 1) LRU, least recently used. Kaster ut blokken som har vært i
Side 4 for Databaser 2) 3) bufferet lengst. Trenger å opprettholde en tabell for når blokker er brukt sist. Klokkepolicy, s. 559 Først in, først ut, FIFO: Blokken som har vært i bufferet lengst blir kastet ut. 16.4 Plassere filposter på disk 16.4.1 Poster og posttyper Data er lagret i form av poster, der hver post er en samling av relaterte dataverdier eller elementer. En samling med feltnavn og deres korresponderende datatyper gir en posttype eller postformatdefinisjon. Forskjellige datatyper: Int, long int, float, string, boolean, date, time, BLOB (binary laarge object, for eksempel bilder, video ) 16.4.2 Filer, fast postlengde og variabel postlengde En fil er en sekvens med poster. Ofte er alle poster i en fil av samme posttype. Fast postlengde: Alle poster i filen har samme lengde Variabel postlengde: Poster i filen kan ha forskjellig lengde. Grunner til at poster har variabel lengde: Felter kan ha variabel lengde Bruke spesielle separatortegn Lagre lengden av feltet før verdien. Noen felter kan ha flere verdier for enkelte poster <feltnavn, feltverdi> I stedet for feltnavn, kan vi bruke felttype som er et heltall. Noen felter i en post er valgfrie En separator for de repeterende verdiene i feltet, og en separator for å indikere at feltet er slutt. Filen inneholder forskjellige posttyper Hver post er innledet av en posttypeindikator. Kan også lagre poster med variabel lengde slik at alle har fast lengde ved å bruke nullverdier men dette er bortkastet plass. 16.4.3 Postblokkering og spredte vs. samlede poster Blokkfaktor: B er størrelsen til blokken, R er størrelsen til postene (der postene fast postlengde) Spredte poster (spanned records): Når en post er spredt utover flere blokker. Dette må brukes hvis posten er større enn blokken. Hvis ikke etterfølgende blokk er brukt, må det være en peker til neste blokk. Samlede poster (unspanned records): Når det ikke er tillatt at poster "krysser blokkgrenser". Dette brukes for poster med fast postlengde, da det gjør postprosessering enklere. Med poster som har variabel postlengde kan begge metoder brukes.
Side 5 for Databaser Med variabel postlengde kan det være forskjellig antall poster i hver blokk, slik at bfr refererer til gjennomsnitts antall poster per blokk. 16.4.4 Tilordning av blokker til disk Sammenhengende tilordning (contiguous allocation): Filblokker blir lagt på etterfølgende diskblokker Lenket tilordning: Hver filblokk har en peker til diskblokken der neste filblokk ligger. Indeksert tilordning: En eller flere indeksblokker har pekere til de faktiske filblokkene. 16.4.5 Filheadere En filheader har informasjon systemprogrammene trenger for å få tilgang til filpostene. Dette inkluderer informasjon om diskadressene til filblokkene, og beskrivelser av posttypene (for eksempel separatorer, feltlengder, rekkefølgen til felt, osv). 16.5 Filoperasjoner Man kan dele opp i to typer operasjoner: Gjenfinningsoperasjoner og oppdateringsoperasjoner. Førstnevnte gjør ingen endringer på dataene, der sistnevnte kan gjøre endringer i form av innsetting, sletting og endring. Liste med forskjellig type operasjoner på side 565566. Skiller mellom filstruktur, hvordan data er organisert i blokker og aksessmetoder, som gir en gruppe metoder som kan brukes på en fil. Merk at ikke alle filstrukturer passer bra til alle typer metoder. Man må planlegge filstrukturen etter hvilke aksessmetoder som skal brukes. 16.6 Heapfiler I en heapfil blir poster lagt til på slutten av filen. Det går veldig fort å sette inn poster det er bare å finne siste blokk, og sette inn posten. Hvis man skal søke etter noe, og det ikke finnes noen indeksering, må man søke lineært gjennom hele filen til man finner det man søker etter. Når man sletter, må man kopiere blokken inn til bufferet, fjerne posten og deretter skrive blokken tilbake til disk. En annen måte å slette filer på, er å ha et flagg som indikerer om en post er gyldig eller ikke. Sletting krever reorganisering av filen, for at det ikke er masse tomme plasser rundt omkring i filen. Man kan bruke en spredt eller samlet struktur, og fast eller variabel postlengde. Endring av poster med variabellengde kan føre til at man må fjerne posten, og sette den inn på nytt av, for endringen kan gjøre så posten ikke lenger passer inn der den var. Hvis en fil har poster med fast postlengde, samlede blokker og sammenhengende tilordning (bruker blokker etter hverandre), så er det lett å finne postenes plassering i filen (typ ite blokk, jte post). Slike filer blir kalt direkte filer. 16.7 Filer med ordnede poster / sorterte filer Sorteringsfelt: Feltet postene blir sortert etter. Hvis sorteringsfeltet også er nøkkelen, så kalles den sorteringsnøkkel.
Side 6 for Databaser Hvis man kjører binærsøk på en sortert fil, kan man kjøre søket på blokkene i stedet for postene. Vanligvis blir log2(b) blokker aksessert ved et binærsøk. Gir ingen fordeler med tanke på tilfeldig eller ordnet aksess på poster basert på de andre feltene. Da må man utføre et lineært søk. Innsetting er tungvint: Må finne plassen der posten skal settes inn, og gjøre plass, som kan kreve at alle poster etter må flyttes "ett hakk fram". En måte å løse det på, er å ha en transaksjonsfil der nye poster blir lagt til og en mesterfil som har de sorterte dataene, så kan transaksjonsfilen og mesterfilen periodevis flettes sammen og sorteres. Dette gjør søking mer komplisert, siden det må søkes i begge filene. Kan bruke merking og periodevis omorganisering ved sletting. Endring: Kommer an på hvilket felt som blir endret og søking. Hvis man søker etter sorteringsfeltet, kan man bruke binærsøk, ellers må man bruke lineærsøk. Hvis man endrer verdien på et ikkesorteringsfelt, går dette fint, forutsatt fast postlengde. Ellers må posten slettes og settes inn på nytt. Sjeldent man bruker sorterte filer i databaser, med mindre man har en ekstra path kalt primærindeks. Hvis sorteringsfeltet ikke er en nøkkel, er det en clustered fil. 16.8 Filer med ordnede poster / sorterte filer En fil som er organisert basert på hashing er kalt en hashfil. Feltet som brukes til hashing, blir kalt hashfeltet, og hvis dette feltet er en nøkkel, blir det kalt hashnøkkel. 16.8.1 Intern hashing Hashing for interne filer (antar innad i filene, hashing av selve postene). Starter med å beskrive ulike typer hashfunksjoner, side 573574. Ved kollisjon kan man bruke åpen adressering (første ledige plass etter), chaining (har en peker til overflytområder) eller multiple hashing (flere hashfunksjoner, bruker neste hvis første ikke funker). Målet med en god hashingfunksjon er å fordele postene jevnt utover med minimalt av kollisjoner, og å gjøre dette samtidig som at adresseområdet er forholdsvis fullt. Det er best å ha en hashfil som er mellom 70% og 90% fullt, så hvis vi forventer r poster, bør vi velge antall lokasjoner M slik at r/m er mellom 0.7 og 0.9. 16.8.2 Ekstern hashing for diskfiler Ekstern hashing er å hashe for diskfiler. Adresseområdet er lagd av bøtter, der hver bøtte kan inneholde flere poster. En bøtte er enten en enkelt diskblokk eller et cluster av sammenhengende blokker. Kollisjon ved ekstern hashing er ikke så ille, da det kan være flere poster i samme bøtte. Men man må ta høyde for at bøtta kan bli full. I statisk hashing gjøres dette ved å ha blokker tilegnet til overflyt. Da må det opprettes pekere til disse. Rekkefølgebevarende hashfunksjoner "tar vare på" rekkefølgen. Det er ikke så mange av de.
Side 7 for Databaser Sletting gjøres ved å fjerne posten fra blokken, og eventuelt flytte en post tilbake fra overflytblokken. Sletting fra overflytblokker gjøres ved å bare fjerne posten, og ha en lenket liste med ubrukte plasser i overflytblokkene. Endring avhenger av hvilket felt som skal endres og søkefelt. Hvis søking går på likhet med hashfelt, kan man hashe, ellers må man søke lineært i fila. Hvis man skal gjøre endringer på hashfeltet, må det hashes på nytt og posten må potensielt flyttes, og hvis man ikke skal gjøre endringer på hashfeltet er dette trivielt. 16.8.3 Hashingteknikker som muliggjør dynamisk filutvidelse Ulempen med statisk hashing, er at adresserommet er fiksert. Det kan potensielt være mye ubrukt plass hvis det man har lite data, ellers så kan det bli for fullt. Extendible hashing: Aksesstrukturen er basert på den binære representasjonen av hashverdien. Adresserommet utvides basert på mengden poster som hashes. Global dybde beskriver hvor mange adresser som finnes, typ 2global dybde (trenger ikke nødvendigvis adresseres til like mange blokker, flere adresser kan peke på samme blokk). Lokal dybde beskriver hvor mange bits som skal vurderes for hver bøtte. Hvis en bøtte blir full, inkrementeres den lokale dybden med én, og man legger til en ekstra bøtte. Hvis det skjer flere slettinger, kan den lokale dybden dekrementeres. Beskriver hvordan dette funker, side 578579. Fordelene med extendible hashing er at ytelsen ikke faller selv om filen blir større, i motsetning til statisk hashing, der kollisjoner og antall blokkaksesser øker. I tillegg trenger man ikke forhåndsreservere blokker. Plassen som trenges for å opprettholde adressetabellen er neglisjerbar. Splitting av blokker tar heller ikke så mye tid, siden det bare er postene i blokken som ble splittet som må distribueres på nytt. Det som kan ta litt tid er dobling eller halvering av adressetabellen. Ulemper er at man må søke i adressetabellen før man kan finne riktig bøtte, noe som resulterer i to blokkaksesser, men dette er ikke så ille.