Fortsett til innholdet.

myMAYDAY.com - for IT-profesjonelle

Seksjoner
Personlige verktøy
Du er her: Forside » Spotlight » 2007 » Database som filsystem? No way!

Database som filsystem? No way! Database som filsystem? No way!

Document Actions
av helge@mellvik.no [17-09-2007 09:00]  -  kategori(er): DriftTeknologi
Egentlig en selvmotsigende observasjon, siden et filsystem er et databasesystem – optimalisert for lagring og manipulering av filer. Så hvorfor ikke slå dem sammen? Er ikke dagens sofistikerte databasesystemer velegnet til også å håndtere alle slags filer? Og er det ikke det mange av dem i virkeligheten gjør?

Visst er det det. Og ideen er langt fra ny. Denne gangen er det Oracle som bringer problemstillingen på bane. Forrige gang var det Microsoft. Og gangen før det igjen, for godt over 10 år siden, var det Oracle igjen. Hver gang har forslaget rørt opp en mengde støv, skapt diskusjon og til dels opphetede meningsutvekslinger, for deretter å forsvinne. Med god grunn. De faglige, funksjonelle og praktiske argumentene for forandringen har i beste fall vært tynne. Det vi har sittet igjen med er et ønske fra leverandørens side om å skape grunnlag for ny business – helt naturlig, men ideen blir ikke bedre av den grunn.

Og nå er vi altså i gang igjen. Lærer de aldri? Eller er det noe vesentlig som har forandret seg? Ifølge Oracle er det det, men det forekommer oss at selskapet – eller kanskje det kun gjelder enkelte av selskapets representanter – ikke helt har forstått verken problemstillingen eller historien. For vi har hatt databasesystemer siden 70-tallet, og vi har hatt filsystemer siden 60-tallet. Begge har utviklet seg dramatisk i perioden, men de har aldri konvergert. Hvorfor?

Fordi de er laget for, optimalisert for og tilpasset forskjellige oppgaver. Verre er det ikke. Hvorfor reagerte ikke markedet positivt på Oralces idé tidlig på 90-tallet? Fordi markedet oppfattet ideen som dårlig. Datidens databasesystemer manglet vesentlige egenskaper, og var uegnet for formålet. Rundt årtusenskiftet signaliserte Microsoft intensjoner om å bytte ut NTFS-filsystemet i NT/W2k med en SQL-database. Og som så mange andre annonseringer av store forandringer i Windows, døde ideen stille ut etter en periode.

Det samme vil skje denne gangen, og vi tror ikke  at Oracle egentlig har ambisjoner om å plassere sin 11g-database som generelt filsystem. Dette er primært en måte å skaffe seg oppmerksomhet på, men vi undres om ikke oppmerksomheten blir negativ i stedet for positiv, i alle fall blant fagpersoner som forstår problemstillingen. For det er mange gode grunner til at filsystemer og databasesystemer ikke har konvergert - hittil. At en slik konvergering er teknisk og praktisk mulig, er hevet over tvil, og i en verden hvor virtualisering på stadig flere nivåer hører til dagens orden, er det lett å tenke seg at lagringssystemet langt der nede i hierarkiet, langt ute av syne, i virkeligheten er en database – SQLserver, Oracle, mySQL, IngreSQL eller en annen variant. Og de finnes – i spesialiserte, men ikke i generelle systemer – med god grunn: Et filsystem er optimalisert for effektiv og fleksibel håndtering av filobjekter og deres metadata. En veldefinert, oversiktlig og krevende oppgave som samtidig må tilpasses omgivelsene. Filsystemet i mobiltelefonen representerer en ganske annen utfordring enn tilsvarende på laptop'en, for ikke å snakke om på serveren eller på SANet. Derfor finnes det utallige filsystem-varianter – ikke bare for forskjellige oppgaver og omgivelser, men tilhørende ulike generasjoner. På et Linux-system har vi nærmere 10 å velge fra, og nye kommer til år om annet – fordi behovene og teknologien forandrer seg.

Et generelt databasesystem er utviklet og optimalisert med helt andre mål for øyet. At de er fleksible og kan tilpasses forskjellige behov og omgivelser er vel og bra, men deres generelle natur sørger også for at de (fleste) er tunge og komplekse. Og om transaksjonene er aldri så raske, skal det mye mer enn raske transaksjoner av en gitt størrelse til for å konkurrere med et moderne filsystem. Dessuten – som enhver driftsansvarlig automatisk vil tenke: Hvordan redder vi en krasjet disk eller et krasjet filsystem dersom det i realiteten er en database det er snakk om? Må vi finne et system med den riktige programvaren, kjøre kompliserte recovery-prosedyrer og håpe at alt går bra? Er den slags prosedyrer gått ut på dato, hører vi? Fordi databasen har logger, journaler, flashback, 'total recall' og andre avanserte mekanismer?

Visst er vi med på at dette kan være nyttig og verdifullt, men det skurrer likevel. Som driftsansvarlig vegrer vi oss for å bruke kompliserte universalverktøy for spesielle, oversiktlige og forutsigbare oppgaver av den enkle grunn at unødig kompleksitet alltid koster – ikke minst tid. Hva som befinner seg under virtualiseringslaget på et lagringssystem vi aldri kommer under huden på, er irrelevant så lenge vi har de verktøyene og den ytelsen vi trenger. Men på systemer og data-lagre vi har direkte tilgang til og ansvar for, vil vi ha enkle og effektive verktøy som lar seg forstå, feilsøke, feilrette og – når det trengs – flytte. Det enkleste er fortsatt det beste, og det foregår minst like mye forskning på filsystemer i dag som for 10 og 20 år siden. Dersom Oracle, IBM, Microsoft eller Sybase hadde vært ledende i denne forskningen, hadde de latt oss høre det. Vi hører ingen ting – bortsett fra sporadiske avsporinger fra opportunistiske teknologer som synes å mangle praktisk erfaring.

Ja, vi vurderer å bytte filsystem på våre servere i nær fremtid, men det blir ikke noe generelt databasesystem. Det blir nok heller ZFS, med opprinnelse fra Sun Microsystems og med lang utviklings- og fartstid som – ja nettopp – filsystem. Og sist vi sjekket, hadde ZFS alle de egenskapene Oracle skryter av i 11g. Nei forresten, ikke alle, men alle som er relevante for et moderne tjener-filsystem. Riktig verktøy for riktig oppgave. Nå som før.

Ved å logge inn får du tilgang til mer fagstoff, regelmessige oppdateringer og til å kommentere innholdet. Registrering er gratis.