Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Ähnlich wie Bbs Tjueprosent Nosql
Ähnlich wie Bbs Tjueprosent Nosql (20)
Bbs Tjueprosent Nosql
- 1. BBS tjueprosent – noSql i ny arkivløsning Bjørn Nordlund og Hans-Petter Vadseth
- 2. Hvorfor? Tekst endres i Topp- og Bunntekst 10/7/2009 s.2
- 3. Skjemafri database Tekst endres i Topp- og Bunntekst 10/7/2009 s.3
- 4. En databasetype til alle formål Tekst endres i Topp- og Bunntekst 10/7/2009 s.4
- 5. Skalering Tekst endres i Topp- og Bunntekst 10/7/2009 s.5
- 6. Vi har muligheten BBS 20% Tekst endres i Topp- og Bunntekst 10/7/2009 s.6
- 7. 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.
- 8. Litt teori Tekst endres i Topp- og Bunntekst 10/7/2009 s.2
- 9. Scale and Performance s.9
- 10. Read slaves, caching, Partitioning, Shared everything and shared nothing Tekst endres i Topp- og Bunntekst 10/7/2009 s.11
- 11. Scaling vs functionality, performance and complexity Tekst endres i Topp- og Bunntekst 10/7/2009 s.22
- 12. 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?
- 14. 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
- 15. 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 }
- 16. 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 } }
- 17. Noen grunn til ikke å bruke dette?
- 24. DEMO http://mongoarchive.heroku.com Tekst endres i Topp- og Bunntekst 10/7/2009 s.30
Hinweis der Redaktion
- 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({&quot;tags&quot;:&quot;oslo&quot;).explain()