Post on 12-Apr-2017
transcript
BBS tjueprosent – noSql i ny arkivløsningBjørn Nordlund og Hans-Petter Vadseth
Hvorfor?
Tekst endres i Topp- og Bunntekst 10/7/2009s.2
Skjemafri database
Tekst endres i Topp- og Bunntekst 10/7/2009s.3
En databasetype til alle formål
Tekst endres i Topp- og Bunntekst 10/7/2009s.4
Skalering
Tekst endres i Topp- og Bunntekst 10/7/2009s.5
Vi har muligheten
BBS 20%
Tekst endres i Topp- og Bunntekst 10/7/2009s.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/2009s.2
Scale and Performance
s.9
Read slaves, caching, Partitioning, Shared everything and shared nothing
Tekst endres i Topp- og Bunntekst 10/7/2009s.11
Scaling vs functionality, performance and complexity
Tekst endres i Topp- og Bunntekst 10/7/2009s.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 BASESkalering 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) ACIDSkalere er vanskelig - shared everything?
Skjemafri database
• Databasen bryr seg ikke om hvordan dataene dine ser ut.o Fokus på å lagre og tilgjengeliggjøre det du ber om.o "skjema" ligger i applikasjonen
Enkel migrering Versjonering av skjema og applikasjon sammen
o Mister dataintegritet• Data lagres typisk som en helhet, ikke i hht til en tablellstruktur
o Mangler joins og "normalisering"• Dynamisk
o "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 VoldemortTokyo CabinetOracle BerkleyDB
Tekst endres i Topp- og Bunntekst 10/7/2009s.27
Key Valuehpv Navn:Hans-Petter,
Email:hpv@bbs.no
bjn Navn:Bjørn,Email:bjn@bbs.no,Tlf:22890000Status:i pappaperm
Operasjoner:
Get (key)Put(key, value)Remove (key)
Kolonnebaserte
Tekst endres i Topp- og Bunntekst 10/7/2009s.28
Key(rad) Kolonne:Value
hpv Personalia:{ navn:Hans-Petter},Kontakt:{ mail:hpv@bbs.no}
bjn Personalia:{navn:Bjørn},Kontakt:{mail:bjn@bbs.noTlf:22890000}Hbase
CassandraHypertable
Operasjoner:
Get (key, column:identifier)Put(key, column:identifier, value)Remove (key)
Map/reduse for mer avanserte spørringer
Dokumentorienterte
Tekst endres i Topp- og Bunntekst 10/7/2009s.29
Dokument{ id:hpv navn:Hans-Petter Kontaktinfo:{ mail:hpv@bbs.no }}
{ navn:Bjørn, id:bjn Kontaktinfo:{ mail:bjn@bbs.no Tlf:22890000 }}
CouchdbMongoDBLotus Notes
Operasjoner:
get(name=value)Put(json)Remove (name=value)Find(><!= …)Count()Sum()....
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øsningLagre ustrukturerte og strukturerte data. Lagre binærfiler (images og annet) med metadata (dato og tags)Oppslag på unik arkivreferanse (uuid)Søk i tagsOppslag/søk på vilkårlig nøkkel/kolonneREST grensesnitt
Ny kul teknologi (I skyen:)
Ruby applikasjon basert på sinatra webrammeverk og mongomapperDeployet på heroku (heroku.com)MongoDb backend levert fra mongoHQ (mongohq.com)
=> utrolig rask og enkel utvkling=> "uendelig" skalering i applaget (heroku,amazon)=> soon to be "uendelig" 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).
DEMOhttp://mongoarchive.heroku.com
Tekst endres i Topp- og Bunntekst 10/7/2009s.30