Det amerikanske selskapet Couchbase kunngjorde denne uken at versjon 2.0 selskapets hovedprodukt, NoSQL-databasen Couchbase Server, er lansert. I den forbindelse har digi.no bedt norske Trond Norbye, utvikler i Couchbase om å fortelle litt om både Couchbase. Han var blant de ti første av dagens omtrent 90 ansatte, da han startet i selskapet for tre år siden.
– Couchbase ble startet for 3 år siden som NorthScale, og var den gangen et overbygg på memcached, med diverse ekstra funksjonalitet. Neste milepæl for oss, under det nye navnet Membase, ble at vi lanserte en «persistensmodell» på dataene. Fortsatt ble memcached protokollen brukt, slik at brukere av memcached som sin cache-løsning, kunne bytte ut backenden med vår persistente backend uten å endre noe i koden sin, sier Norbye.
Han forteller at navnet Couchbase kom etter at Membase og CouchIO (senere kalt CouchOne) slo seg samme i februar 2011. CouchIO var et selskap som tilbød kommersielle tjenester til CouchDB. Ett navn som går igjen er Damien Katz, som tidligere jobbet for IBM med Lotus Notes/Domino. I 2005 etablerte han prosjektet som senere har blitt til Apache CouchDB.
Katz var også medgründer i CouchIO/CouchOne og i Couchbase, hvor han dessuten er teknologidirektør.
– Vi har da bakt deler av CouchDB inn i Couchbase, sier Norbye, men presiserer at det ikke dreier seg om det samme produktet, og viser til denne oversikten over forskjellene.
Blant de mer kjente brukerne av Couchbase, er nettspilleverandøren Zynga, som her forteller om hvordan databasesystemet (som den gang fortsatt het Membase) ble brukt til å løse skaleringsutfordringene.
Én av de store nyhetene i Couchbase 2.0 er støtten for JSON-dokumenter (JavaScript Object Notation). Dette gjør det mulig å modellere dataene slik de er representert i applikasjonen, som objekter og instanser. Det også mulig å indeksere og utføre spørringer på JSON-dokumenter. Ifølge Couchbase kan brukere filtrere på spesifikke verdier, eller verdiområder. Det støttes dessuten flere typer indeksering og MapReduce-teknikker.
– På den måten har vi da gått fra å være en rendyrket «key-value store» til å bli en dokument-database. Hvis man lagrer JSON-dokumenter i databasen, så kan man da skrive sine egne små JavaScript map-funksjoner for å lage egne «views» i databasen, forteller Norbye.
– En av de andre store nyhetene med 2.0 er at vi har lagt inn støtte for replikering mellom datasentra. Det vil si at man kan benytte seg av flere datasenter, og la brukerne bruke det datasenteret som er nærmest. Alternativt kan det brukes som backup, forteller Norbye.
– Dagens internett er en ganske annen hverdag enn man hadde i gamle dager. Tidligere ble stort sett datasystemene brukt av en gruppe mennesker som mer eller mindre jobbet samtidig. Man hadde da som regel noen vinduer man kunne ta tjenester «offline» for å bedrive vedlikehold på dem. Solen går aldri ned på Internett – når vi går hjem fra jobb på ettermiddagen, så starter alltid noen andres arbeidsdag. Å stoppe tjenester er ikke lenger noe alternativ, og der kommer vår datasenter-replikering inn. Dersom man må gjøre vedlikehold på en klynge, så kan man rute trafikken over til et annet datasenter mens man gjør vedlikehold på det første.
Norbye har også mye tanker rundt hva som er det store ved hele NoSQL-trenden.
– Mye har skjedd på «software engineering»-fronten de siste tiårene. Nå til dags kjører man ofte scrum med mange «releaser» og hurtig endring av krav. I «gamle dager» hadde man få releaser, et langt utviklingsløp med mange milepæler også videre. For eksempel lanserer Facebook en ny versjon hver tirsdag. Da går den live til 901 millioner brukere [Facebook passerte faktisk en milliard brukere i oktober, red. anm]. Da kan det rigide skjemaveldet til en relasjonsdatabase være en hemsko. Et stort team med utviklere som jobber på forskjellige deler av systemet, kan føre til at man må kjøre masse «alter table», lage oppdateringsrutiner, etc. I en skjemaløs hverdag som en NoSQL-database, legger utviklerne til de feltene de trenger, og «that's it», forteller Norbye.
Som mange andre som skal forklare noe om IT, kommer han med en bilanalogi.
– Dersom vi skal lagre en bil i en RDBMS (relational database management system, red. anm.), så ville du plukket bilen fra hverandre i alle biter og lagt dem på hver sin hylle i garasjen hver gang du kom hjem fra en kjøretur. Skulle du ut igjen, ja så måtte du sette hele bilen sammen igjen. Dette er en tidkrevende operasjon. Også en database bruker «tid og ressurser» på å «joine» tabeller for å rekonstruere objekter, forteller Norbye.
– I en NoSQL database ville du heller bare parkert bilen i garasjen. Nå er det nok mye raskere å finne ut hvor mange bolter bilen din har hvis du har plukket hele bilen fra hverandre og har dem liggende i en eske på hylla, men er det den primære bruken du har av bilen?, spør Norbye.
– Med en forenklet datamodell i databasen blir det heller ikke «tungt» å benytte database, så vårt motto er at du skal bruke oss som vi var en cache, det vil så at du ikke skriver en masse logikk i applikasjonen for å unngå databasen, avslutter Norbye.
