• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Bbs Tjueprosent Nosql
 

Bbs Tjueprosent Nosql

on

  • 2,313 views

NoSql presentation at IASA norway meeting. The point is to choose a db solution that fits your needs between functionality, scaling and complexity. Nothing is for free, but rdbms is not the only ...

NoSql presentation at IASA norway meeting. The point is to choose a db solution that fits your needs between functionality, scaling and complexity. Nothing is for free, but rdbms is not the only answer for all problems either.

Statistics

Views

Total Views
2,313
Views on SlideShare
2,311
Embed Views
2

Actions

Likes
0
Downloads
9
Comments
0

1 Embed 2

http://www.slideshare.net 2

Accessibility

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • Tanken på å slippe databaseskjema var forlokkende.
  • One size fits all? Er det en naturlov at alle data må lagres i en relasjonsdatabase. For ikke så lenge siden var det ikke mulig å lage en applikasjon uten mange lag, appserver, ejb osv..
  • Arkivcase der vi har har problemer med skaleringer og utviding av funksjonalitet Store datamengder 10Tb, 350 mill elementer i enkelte tabeller.
  • Inspirert av Google med fler Vi kan søke om å få ca 20% av tiden vår til noe vi selv ønsker å drive med.
  • Det er i dette landskapet du skal bevege deg. Vil du ha funksjonalitet, joind, konsistens i basen, eller skalere enkelt og billig?
  • Atomicy Consistency Isolation Durability Basically Available Soft-state Eventual consistency noSql har typisk valgt vekk tradisjonell databasefunksjonalitet og overlatt det til klienten samtidig som de har kunnet styrke ting som skalering og tilgjengelighet. Dette er ting som relasjoner, skjema, spørringer, joins og transaksjoner. Noen er heller ikke ACID compliant. Men som regel er de i allefall atomicy (ikke transaksjoner), ofte konsistent, men ikke nødvendigvis, durability er ikke altid like garantert (forsinkelse på transaksjonslogger etc) Mye varianter, men de fleste har til felles å kunne lagre vilkårlige data, slå opp på nøkkel og flere har fokus på sharding løsninger – som er ekte skalerbart.
  • Større fleksibilitet Flytter skjema opp i applikasjonen. ” Tabeller” og ”kolonner” opprettes dynamisk ved behov. Enklere migrering. Versjonering av skjema sammen med koden. Enklere i en distribuert verden siden man slipper oppdatering Man trenger noe skjema greier indekser..
  • Enkle raske og skalerbare Litt enkle for mange problemer? Typisk kun key som er indeksert Det finnes varianter med unike/ multiple keys Mange varianter av hva som kan legges inn som value
  • Inspirert av Google Bigtable   Det man kaller en multidimensjonal key value db   Key/value med ett skjema (kolonner må predefineres)   Muligheter for å behandle kolonner på forskjellig måte, for eksempel komprimering   Key er typisk indeksert map reduse for å gjøre søk og operasjoner i data. Bedre egnet som en dataanalyse enn onlinedatabase? Vanskelig å forstå konseptet.
  • Data lagret som en struktur (typisk json eller xml)   Felter inne i dokumentet kan indekseres individuelt.   Mye funksjonalitet   Enkle å forstå
  • Det er ikke noen grunn til at noSql baser skal være dårligere eller mindre sikre enn sql baser, dette kommer helt ann på modenheten til produktene og tilgangen på verktøy. I dag er ikke dette like bra, men tiden vil vise, vil de store stille seg bak initiativene, hvem vil overleve etc...
  • et argument for sql baser er ofte at data varer lengre enn applikasjoner og det er rett, men som regel ender du likevel opp med en eller annen eksport/import strategi fordi integrasjon rett mot en denormalisert base er vanskelig, og påtvinger deg legacy datamodell. Dokumenter er mer representative og enklere å gjenbruke. uansett, lag en export all/import all strategi!
  • Vis koden  - modellen - noen rest verb Vis deploy til heroku - se startmeldingene Legg inn et dokument - finn dokumentet - Legg til et nytt dokument med nytt felt - finn basert på nytt felt Last opp noen bilder - Søk på metadata Slett med poster appen   Vis mongoHq grensesnitt  Se filer Se index Kjør en db.images.find({"tags":"oslo").explain()

Bbs Tjueprosent Nosql Bbs Tjueprosent Nosql Presentation Transcript

  • BBS tjueprosent – noSql i ny arkivløsning Bjørn Nordlund og Hans-Petter Vadseth
  • Hvorfor? Tekst endres i Topp- og Bunntekst 10/7/2009 s.2
  • Skjemafri database Tekst endres i Topp- og Bunntekst 10/7/2009 s.3
  • En databasetype til alle formål Tekst endres i Topp- og Bunntekst 10/7/2009 s.4
  • Skalering Tekst endres i Topp- og Bunntekst 10/7/2009 s.5
  • Vi har muligheten BBS 20% Tekst endres i Topp- og Bunntekst 10/7/2009 s.6
  • Vi ønsket oss en databaseløsning hvor vi enkelt kunne lagre det vi ville og lett finne det igjen.    Vi ønsket en løsning som var enkel å sette opp, som kunne kjøre hvor som helst   Vi ønsket en dynamisk løsning som kunne vokse med applikasjonen, endres og skaleres opp eller ned etter behov.
  • Litt teori Tekst endres i Topp- og Bunntekst 10/7/2009 s.2
  • Scale and Performance s.9
  • Read slaves, caching, Partitioning, Shared everything and shared nothing Tekst endres i Topp- og Bunntekst 10/7/2009 s.11
  • Scaling vs functionality, performance and complexity Tekst endres i Topp- og Bunntekst 10/7/2009 s.22
  • SQL vs noSQL noSQL Ikke noe skjema, data som hører sammen lagres sammen. Ikke normalisert, ikke integritet. Referanser mellom data.   key/value, (tables, collections)   Spørringer, serverside funksjoner, map reduce finnes hos noen Indexer og profilering finnes hos noen   BASE Skalering er noe enklere - shared nothing   s.21 SQL Fast skjema, normaliserte data, integritet. Primærnøkler, fremmednøkler og indexer Transaksjoner   Spørringer og joins   Profiling (explain)     ACID Skalere er vanskelig - shared everything?
  • Skjemafri database
      • Databasen bryr seg ikke om hvordan dataene dine ser ut.
        • Fokus på å lagre og tilgjengeliggjøre det du ber om.
        • "skjema" ligger i applikasjonen
          • Enkel migrering
          • Versjonering av skjema og applikasjon sammen
        • Mister dataintegritet
      • Data lagres typisk som en helhet, ikke i hht til en tablellstruktur
        •   Mangler joins og "normalisering"
      • Dynamisk
        • "Databaser", "tabeller" og "kolonner" opprettes ved behov
      • Data som skal være søkbare trenger en form for skjema 
    s.26 Ett naturlig steg etter å ha flyttet logikk ut av databasen?
  • Key/value Project Voldemort Tokyo Cabinet Oracle BerkleyDB Tekst endres i Topp- og Bunntekst 10/7/2009 s.27 Operasjoner: Get (key) Put(key, value) Remove (key) Key Value hpv Navn:Hans-Petter, Email:hpv@bbs.no bjn Navn:Bjørn, Email:bjn@bbs.no, Tlf:22890000 Status:i pappaperm
  • Kolonnebaserte Tekst endres i Topp- og Bunntekst 10/7/2009 s.28 Hbase Cassandra Hypertable Operasjoner: Get (key, column:identifier) Put(key, column:identifier, value) Remove (key) Map/reduse for mer avanserte spørringer Key(rad) Kolonne:Value hpv Personalia:{   navn:Hans-Petter }, Kontakt:{   mail:hpv@bbs.no } bjn Personalia:{ navn:Bjørn }, Kontakt:{ mail:bjn@bbs.no Tlf:22890000 }
  • Dokumentorienterte Tekst endres i Topp- og Bunntekst 10/7/2009 s.29 Couchdb MongoDB Lotus Notes Operasjoner: get(name=value) Put(json) Remove (name=value) Find(><!= …) Count() Sum() .. .. Dokument {   id:hpv   navn:Hans-Petter   Kontaktinfo:{      mail:hpv@bbs.no   } } {   navn:Bjørn,   id:bjn   Kontaktinfo:{     mail:bjn@bbs.no     Tlf:22890000   } }
  • Noen grunn til ikke å bruke dette?  
  • Er det bra nok?
    • Dette er umodne produkter, verktøystøtten er ikke bra nok, det er ikke sikkert nok.
    • => Men det er ikke noen grunn til at de ikke kan bli bedre og like bra som RDBMS løsninger.
  •  
    • Data varer lenger enn applikasjoner, vi må ha RDBMS
    •  
    • => Export/import strategi! (kan testes)
  •  
    • Vi driver med bank, vi må ha rdbms
    • => Ikke alle applikasjoner i bank er like
    • I dag brukes blant annet filer for lagring og transport
    • Vi har allerede midlertidig inkonsistent state
    • Vi benytter allerede key value (caching, blobs etc)
    • Lemper allerede på constraints og normalisering for ytelse
    • ORM
    • Vi har allerede manuell feilhåndteringer
    • Vi benytter allerede optimistisk låsing med versjonering
  •  
    • Kan vi klare oss uten transaksjoner, joins og konsistens i basen?
  • Applikasjonen
    • En ny arkivløsning
    • Lagre ustrukturerte og strukturerte data. 
    • Lagre binærfiler (images og annet) med metadata (dato og tags)
    • Oppslag på unik arkivreferanse (uuid)
    • Søk i tags
    • Oppslag/søk på vilkårlig nøkkel/kolonne
    • REST grensesnitt
  • Ny kul teknologi (I skyen:)
    • Ruby applikasjon basert på sinatra webrammeverk og mongomapper
    • Deployet på heroku (heroku.com)
    • MongoDb backend levert fra mongoHQ (mongohq.com)
    • => utrolig rask og enkel utvkling
    • => &quot;uendelig&quot; skalering i applaget (heroku,amazon)
    • => soon to be &quot;uendelig&quot; skalering i databaselaget (mongohq,sharding, amazon)
    • => Mongo gir oss mer enn de fleste noSql løsninger med et rikt query språk, indexer, profilering (explain), og mulighet til å kjøre serverside funksjoner (som for eksempel map reduce).
  • DEMO http://mongoarchive.heroku.com Tekst endres i Topp- og Bunntekst 10/7/2009 s.30