Hvordan databasesystemene kan hjelpe RAM-produsentene Kreativ bruk av RAM i DBMSer Ragnar Normann
Innhold Litt databasehistorie Litt UiO datahistorie Hvorfor (manglende) minnebruk i DBMSer er blitt et problem Søkbare data og indekser Rindex-prosjektet Hva Rindex er, hva som er gjort, og hva resultatene er Videre planer
Litt databasehistorie I 1964 Bachman & Williams (General Electric) lanserer IDS (Integrated Data Store), en 2-skjemaarkitektur nettverksdatabase 1968 IBM lanserer IMS (Information Management System) en hierarktisk database 1970 Codd presenterer det teoretiske grunnlaget for relasjonsdatabaser 1974 Stonebraker starter utviklingen av Ingres med spørrespråket QUEL IBM starter utviklingen av System/R med spørrespråket SQL
Litt databasehistorie II 1977 Oracle lanseres (med SQL!) (første kommersielle relasjonsdatabase) 1978 IBM lanserer System/R kommersielt 1980 Kommersiell versjon av Ingres Informix lanseres 1982 DB2 erstatter System/R 1984 Sybase lanseres 2001 IBM kjøper Informix (Multimediadatabase) 2004 Informix er integrert med/i DB2
RAM-veksten ved UiO 1961 Wegematic med 128 ord (< 1 kb) 1962 IBM 1620 I med ca 10 kb 1964 IBM 1620 II med ca 30 kb 1967 CDC 3300 med 288 kb 1976 CDC 3300 med 384 kb 1976 DEC10 med ca 1 MB 1980 DEC10 med ca 3 MB (2003 Ragnars hjemme-mac har 1 GB)
Dagens DBMS-marked I følge Computerworld hadde DB2 og Oracle ved utløpet av 2004 omtrent like store markedsandeler til sammen nesten 90% Antall MySQL- og MS-SQLserver-brukere øker, men det har liten innvirkning på seriøs bruk: bank, børs og forsikring helsevesenet forvaltningen forsvaret holder seg alle til de to store
Problemstilling Dagens ledende kommersielle DBMSer ble designet mens 4 MB var en svært stor (og svært dyr) hukommelse Ingen tunge databaseapplikasjoner vil i dag bli kjørt på en maskin med mindre enn 4 GB RAM Mitt spørsmål er da: Hva burde ha vært gjort annerledes hv
RAM-databaser En løsning er å lese hele databasen inn i RAM Spørringer blir svært raske Oppdateringer
Ikke-søkbare data I I henhold til SQL:1999-standarden skal to ikkesøkbare datatyper understøttes: Clob Character large object Dette er store tekstobjekter, f.eks. en roman Blob Binary large object Dette er store binærobjekter som lyd, bilder og video Både Oracle og DB2 håndterer i siste versjon blober og clober som er større enn 4GB
Ikke-søkbare data II Restriksjoner på blober og clober i SQL: Det er ikke lov å lage indekser på dem Det er ikke lov å sammenligne to blober eller to clober i WHERE-delen av et SQL-spørsmål De kan ikke inngå i nøkler eller fremmednøkler I forhold til SQL fremstår ikke-søkbare data derfor som «passive data» De søkbare dataene er vanligvis vesentlig mindre i volum
Rindex-prosjektet Rindex står for RAM-basert indeks Prosjektet er et Master-prosjekt Jeg planla opprinnelig 3 generasjoner med masterstudenter Første generasjon (Tomas Are Haavet og Kjell-Magne Øierud) ble ferdig i mars 2005 Andre genersjon er i gang og ventes ferdig i juni 2006 Tredje generasjon er ikke begynt, men ventes ferdig i juni 2007
Rindex-plattformen I Rindex begrenser seg (i det minste foreløpig) til relasjonsdatabaser I motsetning til rene RAM-databaser forutsetter Rindex at relasjonene (dataene) ligger på disk Rindex er designet som et overbygg på andre DBMSer Til nå har vi brukt Oracle og en sterkt forenklet SQL
Rindex-plattformen II Vi har til nå valgt å lagre alle primærindeksene (indekser på primærnøklene) på disk Vi genererer indekser i minnet for alle attributter det er fornuftig å gjøre sammenligninger med det vil i praksis si alle indekserbare attributter, inklusive attributtene i primærnøkkelen Hittil har vi bare sett på spørringer Vi er så vidt begynt å se på oppdateringer
Indeksimplementasjon Oppslag i databasen gjøres ved bruk av relasjonenes primærnøkler En linje i en sekundærindeks for et attributt inneholder attributtverdien og en peker til «sin» linje i primærindeksen Hvert søkbart attributt har eksakt en sekundærindeks, og dette er det eneste sted hvor attributtverdien lagres Primærindeksen består altså av pekere inn i sekundærindeksene
Dynamiske indekser Primær- og sekundærindeksene opprettes idet Rindex startes Ved eksekvering av spørsmål mot databasen bruker Rindex tilsvarende indeksstrukturer til å lagre mellomresultatene (disse strukturene inneholder altså bare pekere) Når et spørsmål refererer til flere attributter, vil det i eksekveringsplanen være behov for å bytte ut en referanse til en sekundærindeks med en referanse til en annen indeks (de to referansene gjelder samme tuppel, men forskjellig attributt)
Tidlige erfaringer Opprinnelig ble indeksene organisert som hashstrukturer med lenket overløp Tidlige målinger viste at vel 90% av CPU-tiden ble brukt av substitusjonsoperatoren (rutinen som bytter ut en indeks med en annen) Tomas Are Haavet har i sin masteroppgave gjort en teoretisk og empirisk undersøkelse av fem alternative datastrukturer for indeksene Resultat: Finurlig bruk av gammeldagse inverterte filer ga redusert CPU-tid med en faktor mellom 7 og 8 (med samme minnebruk)
Genereringstid Idet Rindeks startes, blir de statiske indeksene bygget opp Vår testdatabase (filmdatabasen) har ca 550 000 poster og tar 12MB Genereringen av indekser for filmdatabasen tok ca 1 1/2 minutt CPU-tid brukt var 20 s (bruker + system) Forsøk viser at 5s/MB er en øvre grense for genereringstiden
Rindex og Oracle I Kjell-Magne Øierud foretok i sin masteroppgave en sammenligning av svartider for spørsmål mot to Oracle-databaser med og uten bruk av Rindex For spørsmål som består av join-er og en konjunksjon av seleksjoner, er Rindex helt overlegen med en faktor som varierer fra 5 til 20 Gevinsten var størst for numeriske data og minst for lange tekster (varchar(40))
Rindex og Oracle II For spørsmål med disjunksjoner er effekten av Rindex mindre, men det er vanskelig å lage spørsmål hvor Rindex har negativ effekt Øierud konkluderer med at det er grunn til å se nærmere på implementasjonen av unionoperatoren Merk: Jeg presiserer at dette ikke er en sammenligning av Rindex og Oracle. Det som er gjort, er å sammenligne Oracle brukt med og uten overbygningen Rindex.
Planer og vyer I Tema for den pågående fase av Rindexprosjektet er håndtering av oppdateringer Dersom den nåværende implementasjonen av indekser viser seg å være uhensiktsmessig, må vi se på alternativer En mulig kandidat er CSB-trær (Cache Sensitive B-trees) Dessuten kan beste løsning være avhengig av fordelingen mellom spørringer og oppdateringer
Planer og vyer II Rindex må håndtere et større subsett av SQL (egenjoin og subqueries er viktig) I tredje generasjon har jeg tenkt å få undersøkt «generering ved behov»-løsningen Flere forslag mottas med takk