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