Skip to end of metadata
Go to start of metadata
  • Dato: Onsdag 14. Oktober 2009. 18:00-21:00
  • Sted: Scotsman
  • Tema: #noSQL

Invitasjon

Da starter vi vårt første IASA møtet i høst. Denne gang ser vi på temaet "noSQL", dvs. hvordan ser verden ut dersom vi designer løsninger uten relasjonsdatabaser? Bruk av relasjonsdatabaser har nærmest vært en fast rammebetingelse, og noe vi har tatt for gitt, og dermed designet resten av systemløsningen for å få den til å virke opp mot problemet vi skal løse.

Ofte må det mange ekstra verktøy og rammeverk til for å få det til å fungere + at det må ytterligere knep til for å få det til å gå raskt nok rundt. Av og til så lemper vi også innholdet over på et annet medium (flate filer med XML) for å få til samspill med andre løsninger eller få det til å gå raskt nok rundt. I den siste tiden så har også søkemotorer seilet opp med teknologi som både er mer effektivt og gjør det enda mer aktuellt å vurdere alternativer.

Derfor ønsker vi å gå dypere inn i det temaet og har invitert foredragsholdere med erfaringer, meninger og innsikt i temaet til å dele dette med oss. Etterpå kjører vi debatt for å få en meningsutveksling fra ulike ståsted.

Det er fortsatt plass til foredragsholdere, så meld gjerne inn forslag hvis dere er interessert.

Agenda

1800: Intro og velkommen - sørg for øl eller andre forfriskninger
1815: Foredrag rundt noSQL (eller proSQL for de som vil det)

1930: Ny forsyninger og forberedelse til debatt
1945: Debatt

Påmelding

RSVP

0 people attending
Name Organization
There are no attendees registered for this event.

Twitter feed fra møtet

Could not retrieve http://search.twitter.com/search.atom?q=%23iasa+%23nosql&since=2009-10-14 - Page not permitted. Gone
Labels:
medlemsmøte medlemsmøte Delete
year2009 year2009 Delete
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.
  1. Oct 15, 2009

    Bra presentasjoner! I vårt miljø ser det fortsatt ut til å være på "dette kan bli bra i fremtiden"-nivå, så det blir spennende å se hva som skjer fremover. Forhåpentligvis kan noe komme med erfaringer fra faktisk bruk på kommende møter.

    Jeg måtte gå før debatten, så godt mulig at dette er gjentagelser av hva som ble sagt der.

    Flere av problemene som vi ønsker å løse ved å gå bort fra SQL tror jeg i stor grad også kan løses uten å kase SQL-databasen på sjøen:

    • Bedre og bedre ORM-verktøy øker støtten for refaktorering ned i databasen
    • Design for horisontal skalering kan løses ved hjelp av bedre tjenesteorientering og bedre arkitektur for kommunikasjon mellom tjenestene (dette la jeg til en tema-forslag om)
    • Skyen og alt det den medfører av fordeler (og ulemper) kan brukes for SQL like godt som noSQL

    Så min titt inn i krystallkulen sier at vi på kort sikt vil løse disse utfordringene på måter som er mindre risikofylte (for forretningen) enn å gå bort fra relasjonsdatabaser.

  2. Oct 15, 2009

    Demo av "nosqlarkivet" ligger i skyen. Det er bare å teste ut for den som har lyst.

    http://mongoarchive.heroku.com/

    Kort oppsummering

    • RESTful ruby applikasjon basert på sinatra webrammeverk og mongomapper
    • Deployet på heroku (http://heroku.com)
    • MongoDb backend levert fra mongoHQ (http://mongohq.com)
      ==> skalering i applikasjon og (soon to be) datalag
  3. Oct 15, 2009

    Notater fra panel-debatten:

    Kjetil J. Dahl, Jason fra Sun, Kjetil fra tidligere FAST, jobber nå med Cassandra, Mikael Svenson fra Comperio, Bjørn Nordlund fra BBS, Trond Arve Wasskog fra BEKK

    Totto: Hva er ansvaret til databasen, hva skal den egentlig gjøre?
    KJD: Skal du skrive, lese, slette, summere - det er mange caser som en DB skal og kan gjøre
    Fra salen (Erik D): Hva er det man typisk bruker RDBMS til
    TAW: Data som skal lagres over tid - de finnes der uavhengig av applikasjonen
    Bjørn N: Fristende å bruke den til integrasjon - fordi den er god på isolasjon. Den er treg og skalerer ikke, men den klarer akkurat det - dvs. delte data, distribuerte data. Fungerer, skalerer dårlig
    KJD: I de fleste tilfeller er det så små datamengder, at en relasjonsdatabase fint klarer å få til det

    TAW: De fleste av dagens applikasjoner klarer seg med RDBMS, så det alene er ikke god nok grunn. Men prispress kan gjøre at kompetansen dreier seg og det blir etterhvert enklere, raskere og billigere med alternativene.

    Totto: Er det egentlig så billig. Databasen er jo allerede gratis?

    TAW: Alle trenger det nok ikke - men pris kan gjøre det mer vanlig, og det vil igjen skape mer kompetanse og skape et nytt reellt alternativ - nøkkel/verdi-database. Etterhvert kompetansepress, og enkelhetspress (smidigere og mer endringsvillig).

    Jason: Flickr, LinkedIn, MySpace m.fl. bruker alle mySQL. Det må jo være en god grunn til det.

    TAW: Utviklingen vil forårsake en vridning, det vil gi oss alternativer

    Jason: Riktig at vi må tenke mer - men en database løser de fleste problemer vi har på en god måte

    Bjørn N: Vi bruker RDBMS som integrasjon - men innenfor hver applikasjon bruker vi ofte filer, veldig fokus på transaksjoner og så spytte ut i fil. Er det egentlig så viktig? Det er tross alt det som går inn og det som går ut som er viktig - ikke hva som skjer på veien. Vi trenger å utfordre det mindsettet vi vanligvis tar.

    Totto: Hvor mye koster en transaksjon?

    KJD: Dere sier disse er enkle - det er bullshit - det er spesialskrevet, og overhodet ikke enkelt. Du er nødt til å legge det ut i skyen, og kan ikke sette det opp selv.

    TAW: Notes fungerer - kjempeenkelt

    KJD: Finansapplikasjonen legger du vel ikke der

    TAW: Joda - i de caser hvor man f.eks. legger avanserte metamodeller oppå relasjonsmodellen så er det enklere og bedre med key-value eller dokument databaser

    Bjørn N: Joda - det er enkelt, så lenge du gjør det enkelt

    KJD: Men da velger du bort masse, og du velger også muligheten til å velge bort leverandør av DB. Vi byttet DB2 mot Oracle uten problemer. Du vil få vendor lockin uten RDBMS.

    Fra salen: Egentlig intet som låser - du kan jo eksportere regelmessig til en relasjonsdatabase dersom du ønsker det

    KJD: Ved veldig mye data så blir du nødt til å flytte prosesseringen til der dataene er, dvs. til cloudet f.eks. Det er en sannsynlig utvikling

    Fra salen: Blander vi kortene - noSQL og cloud, det er forskjellige ting.

    Fra salen: Det er en viss blanding allerede i og med at leverandørene kommer gjerne fra skyen. Du kan fint ha en dokument database uten å være på skyen. Du kan tune det selv.

    Jason: Når du ser på egne datasenter så blir det mer gråsone - når du går for cloud så blir noSQL interessant i seg selv (siden det er det som tilbys)

    Totto: Hva er gode grunner, hvorfor skal jeg velge bort RDBMS?

    Erik D: Når du ikke har noe annet valg

    Jason: Pga. CAP Conjuncture

    Bjørn N: Når du skal hente i helhet det du lagrer

    Mikael: Når du ikke vet helt hvordan dataene dine kommer til å se ut - trenger mer fleksibilitet

    KJD: Hvis du ønsker å sysselsette utviklere - da må du bruke noSQL fordi du må lage masse ting som databasen gjorde før

    Fra salen: Det er utviklere som pusher dette her, og det er vanskelig å finne DBA'er som kan bistå uansett, slik at utviklere da faktisk får mer kontroll, kan refaktorere domenemodellen uten å gjøre masse crap i databasen

    Bjørn N: Tror ikke helt på at dataspesialister skal styre datadefinisjonen - at resten er generalister. Tror heller det er motsatt.

    Totto: Er det makten som er viktig? Hvem som eier dataene?

    TAW: Dette pushes ikke av teknologer - det pushes av markedet som trenger mer fleksibilitet og smidighet (ref. Smidig bølgen)

    KJD: Er det enklere å refaktorere en skjemaløs database enn et skjema. Er ikke problemet pga. at andre bruker det samme skjema egentlig - det samme problemet vil du få med noSQL

    Erik D: Hva med prisen? Det er billigere med tilgang til utviklere enn DBA'er

    Salen: Nå er jo ORM verktøyene så gode, slik at du enkelt kan endre basen. Hvorfor skal man da bruke noe annet?

    TAW: Løser ikke alt - må ta hensyn til data. Når du har et blødende sår mellom koden og dataene dine, så er ORM et dårlig plaster.

    Salen: Gjør vi dette pga. DBA'en? Kan vi løse det på noen annen måte?

    Bjørn N: Ingen grunn til at DBAen skal være med - han må finne sin rolle

    Totto: Ansvaret for spørringer - hvor havner det?

    Mikael: Det som er vanlig er å trekke ut fra databasen, denormalisere og indeksere på nytt grunnlag

    KJD: Full-tekst søk og tags fungerer dårlig på RDBMS

    Salen: Joda - banker har konsistente data. Påstand mot påstand...

    KJD: Hva er risikoen ved å miste en trans? Mao. du kan akseptere inkonsistens i praksis

    KJD: Selv vi i Relasjonsverden har gitt opp - fordi vi kjører optimistisk låsing

    Bjørn N: Bedre å feile raskt når du først feiler

    Totto: Det store havariet i august 2001 EDB/Fellesdata - da var det tross alt mulig, selv om det tok lang tid å rekonstruere dataene

    Fra salen - en med erfaring fra bank som hevder at det er mulig med atomisk transaksjonskontroll - det viser seg at de har lokal kontroll i din bank - kun den ene banken i seg selv har mulighet for å få det til. Det er ikke fullstendig konsistens i hele kjeden. Du har konsistens mot din egen konto. Det viser seg også at du tar det ut fra databasen og opp i applikasjonen - de hadde implementert kompenserende transaksjoner

    Totto: Transaksjoner døde på 70-tallet når vi fikk mer enn en maskin

    Totto: De fleste her har RDBMS på samvittigheten - hva vil det bety å bytte ut RDBMS med en noSQL database - hvilke beslutninger må tas for å gå i en slik retning

    Kjetil: Du får mindre innsyn i databasen - ikke like lett å sjekke hvordan ting gikk. Hva er du vant til fra før som du nå ikke får til.

    KJD: Du må finne ut hva du egentlig trenger. Objektorienterte databaser viste seg å fungere tungt i praksis - sårbart ift. hvordan koden eksekverte.

    Bjørn N: Catch 22 - utbredelse må til før standarder kommer. Hadde jeg tort i dag? Noen må prøve seg uansett.

    KJD: Litt som rails

    Totto: TAW spår at de store vil gjøre det snart . hvorfor?

    TAW: Hvis det blir realistisk å gjøre det, så vil f.eks. BBS vurdere det

    Mikael: Er det noen i Norge som er villige til å levere noe sånt som i skyen

    Bjørn N: Du trenger ikke sky for å få det til - dette er enkel teknologi

    TAW: De norske miljøene er for små - så de storskala miljøene med prisfordeler ser vi kanskje ikke her

    Mikael: BBS har stort driftsmiljø allerede - når skal de til noSQL?

    Bjørn N: Vi har også små løsninger - det er ikke nødvendigvis sammenheng med størrelse og nytte av noSQL. Betalingsløsningene er også lette å partisjonere, slik at de skalerer OK med RDBMS

    Salen: Store web-løsninger vil sikkert vurdere dette - de ønsker seg fleksibilitet og mindre kostnader

    KJD: Håper at Amazon på et tidspunkt etablerer seg i Europa. Samtidig så er det tross alt ikke så strengt. Vi jobber med clearing og har disaster site i Sverige - så det er mulig å ha hostede løsninger utenfor Norge

    Salen: Hva med å implementere samme type løsninger som Amazon selv - og ikke i clouden. Det de gjør er relativt tilgjengelig, og de har tilpasset seg CAP, f.eks. å akseptere eventual consistency.

    Totto: Hver gang det kommer krav om transaksjoner så bør man utfordre det, og finne ut av det reelle kravet og fokusere på å løse det

    KJD: Eventual consistency er ofte mer enn godt nok.

    Totto: databasen har bedre ACID egenskaper enn filsystemet, så det er interessant

    Bjørn N: Av og til så ser man at man trenger akkurat de egenskapene som noSQL gir, og ikke de egenskapene som RDBMS gir - og da blir det definitivt aktuelt. Man bør mao. spesifisere hva man vil ha, og da gå for det som løser behovet

    KJD: Kanskje en utvikling kan være at RDBMS leverandørene tilpasser seg de reelle behovene...

    Bjørn N: mySQL er den mest brukte key/value databasen