ole petter_1

På tide å løfte dataene ut av relasjonsdatabasen?

Ole Petter Lindstad har kommet til nye erkjennelser om NoSQL.

Noen ganger går man rundt med en følelse av at det er noe man burde finne ut mer om.

Den følelsen har kommet oftere og oftere for min del, det introduseres nye konsepter i en fart som vi teknologer ikke har sett maken til. Der man før ventet på en CD / DVD med ny programvare som ble gitt ut en gang i året eller to, kommer det nye oppdateringer kontinuerlig. Utviklingsmodellene er revolusjonert, med open-source modeller støttet av alt fra Microsoft til et par utviklere på hvert sitt gutterom. Leveransemodellen er nettet, på en eller annen måte. Fysisk utsendte oppdateringer forsvant for 5 år siden eller mer. Software as a Service modellen gjør jo at man ofte ikke vet om oppdateringer engang. For oss utviklere har jo GDD blitt den dominerende modellen (Google Driven Development).

Men meningen med dette blogginnlegget er ikke å bli sittende og mimre over alt som var så mye bedre før. For det var ikke bedre før. Grøsser ved tanken på mengden dokumentasjon og manualer man trengte for å håndtere relativt enkle verktøy. Ikke hadde man noen å spørre heller.

Jeg har lenge tenkt på at jeg burde finne ut litt mer om disse slappfiskene som ikke gidder å strukturere dataene sine i relasjonsdatabaser, men derimot bruker NoSQL. Dette har blitt et begrep som dekker en rekke forskjellig konsepter der man altså ikke bruker SQL men derimot jobber mot dataene på en annen måte. Ikke bare det, de er vanligvis ikke særlig opptatt av å beskrive hvordan dataene skal se ut på forhånd. Det bare årner seg lissom.

Jeg så på det først som latskap. En lett nedvurderende «ungdommen i dag» syn på fenomenet, de gidder ikke engang å finne ut hvordan dataene henger sammen. Og når strukturen i dataene endrer seg vil man alltid trenge å endre på koden og migrere dataene til ny modell. En eller annen modell vil det alltid være, definert eller ikke, og da vil det straffe seg å ha et lemfeldig forhold til de underliggende strukturene. Tenkte jeg.

Ytelse

Men jeg så tidlig et par scenarier hvor NoSQL hadde fordeler. Relasjonsdatabaser skalerer ikke så bra. Datatabeller kan vanskelig håndteres av mange noder på en gang, siden nodene må synkronisere med hverandre på grunn av hvordan dataene lagres. Det finnes derfor en øvre grense for hvor mye en vanlig relasjonsdatabase kan ta imot av informasjon, og over hvor store avstander nodene bør spres over (jo nærmere hverandre jo bedre). En relasjonsdatabase blir raskere jo kraftigere maskinen er, men får ikke bedre ytelse av å spres over et stort antall maskiner. Uten helt spesielle teknikker som bare et fåtall utviklere behersker i alle fall.

Facebook er et typisk eksempel på enorme datamengder, der bare tanken på å samle alt i én database kan gi enhver gammel databasemann frysninger. Det ville rett og slett ikke la seg gjøre.

Men det er et par ting til som er spesielt med Facebook.

Konsistens

Når man har lagret noe i en SQL-database er det garantert der. Alt som blir lagret, gjerne flere ting på en gang, blir lagret i én transaksjon, hvilket garanterer at alt er stabilt og komplett etterpå.

Med Facebook kan vi fire litt på det kravet. Vi legger inn en selfie over nettet, og er vant til at dette noen ganger ikke fungerer 100%. Det kan være nettet som er dårlig, eller rett og slett FB-infrastrukturen som har et problem. Men dette gjør ikke noe, så lenge det ikke er kritisk at det fungerer. Om det ikke fungerer en av 200 ganger, gjør ikke dette noe større for din brukeropplevelse. Du bare prøver igjen, og da fungerer det. Det ville du aldri ha godtatt dersom det hadde vært betaling av en regning i banken. Dessuten er det slik, at avhengig av hvor du er hen i verden, og hvilken server du «traff» når du sjekket Facebook, er det ikke sikkert at alle oppdateringer har nådd frem ennå. Alle serverne som er plassert rundt omkring synkroniserer kontinuerlig, men det betyr at det også tar tid før alle oppdateringer når alle servere. Men siden det er Facebook er det ikke så nøye.

Men hvor mange er det egentlig som har tilsvarende behov som Facebook? Opptil nå har det vært de færreste. En tilsvarende applikasjon med et like globalt publikum har i alle fall ikke jeg laget.

Så jeg lot tanken på NoSQL-baser ligge noen år. Selv om tanken om at jeg burde vite litt mer gnaget.

Store datamengder

For et år siden havnet jeg i et prosjekt der man fikk benyttet all sin tidligere ervervede database-kunnskap til å behandle virkelig store datamengder. Forskjellige teknikker og stjernemodellering ble brukt, og vi fikk det til, men jeg satt allikevel igjen med en følelse at man begynte å nærme seg noen grenser for hva som var mulig. Ikke minst føltes det som om man begynte å jobbe mot relasjonsdatabasen, og ikke med den. Det var på tide å stille noen spørsmål om relasjonene og den absolutte transaksjonelle konsistensen var nødvendig.

Meningen var å lage et analysesystem, og ikke et faktureringssystem. Kravene var dermed ikke lenger absolutte. Man skulle se på trender i dataene, ikke se om små enkeltbetalinger var gått igjennom. Det var dessuten ikke denne databasen som eide dataene, de var aggregert fra flere forskjellige andre steder.

Det ga meg motivasjonen til å se på NoSQL-fenomenet og datalagring generelt på en ny måte.

Elastic Search

Jeg fikk gleden av dra på den første Elastic-konferansen som ble arrangert i San Francisco i mars i år. Elastic er en open-source produktportefølje, som retter seg mot søk og analyse av data. Ingen relasjoner, ingen transaksjoner.

Jeg begynte å diskutere med kolleger som allerede var overbevist om de relasjonsløse databasenes fortreffelighet. Og selvfølgelig Elastic spesielt.

Først måtte vi finne et felles vokabular, og det var et problem for forståelsen at begrepene er brukt til helt forskjellige ting. En indeks i Elastic er f.eks. det samme som en database i SQL, mens en indeks i en SQL-database er forskjellen mellom himmel og helvete når det gjelder ytelse.

En kollega sa: «Tenk deg at du bare laster opp alle dataene i JSON-format (et utflatet format med muligheter for hierarkiske data) til et cluster med servere, og dataene er deretter lette å søke på, aggregere og analysere. Du må tenke at det bare går raskt lissom.»

Hva? Helt uten videre?

Alt har sine begrensninger. Men mengden data som takles via Elastic rett ut av boksen er fascinerende. Vi som har brukt årevis på å lære oss alle triks i boka for å få databasen til å gå raskt, blir enkelt slått av noen jyplinger som stapper enorme mengder data inn i Elastic, og får det til å fungere i løpet av timer, ikke uker.

Er dermed kunnskaper om relasjonsdatabaser overflødige?

Jeg ville ikke basert min fakturering på Elastic, jeg tror på struktur og transaksjoner for å holde på konsistens. Men å analysere fakturaene, og med andre ord pengestrømmen min, derimot. Hvor i landet har jeg flest kunder? Hvor selger jeg mest melk? Når jeg selger melk til noen, selger jeg også smør? Analysere og søke i et datasett uten å vite hva jeg ser etter på forhånd (i SQL-verdenen: uten indekser!).

Det finnes m.a.o. nye muligheter der ute som verden venter på.

Det er på tide å se på datalagring på en ny måte!

Publisert