Polyglot Persistence
•
0 likes•462 views
Lightning Talk at Norwegian Developer Conference 2013
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
More from Ole-Martin Mørk
Recently uploaded
Recently uploaded (20)
Polyglot Persistence
- 4. One database
- 7. NEED NUMBER 1 Read and write data
- 8. Need number 1 Key-Value Store read and write data Application KV
- 9. NEED NUMBER 2 Search the data
- 10. Need number 2 Search Engine search the data Application KV Search
- 11. NEED NUMBER 3 Relational search
- 12. Need number 3 Graph Database relational search Application KV Search Graph
- 16. NEED NUMBER 4 Generate reports
- 17. Need number 4 RDBMS generate reports Application KV Search Graph Events RDBMS
- 19. Thank you! Ole-Martin Mørk @olemartin Bekk Consulting AS
Editor's Notes
- Jegskalsnakkeomarkitektur.Hvaer starting point for god arkitektur?Arkitektur-arbeid starter forhåpentligvis med åavdekkebehov. For åvitehvaoghvordan vi skallagenoesåmå vi kjennetil needs the application should fulfill
- Vi tegnerbokser, og vi tegner linesSystemenesnakkersammenpåforskjelligeprotokollerNoesynkront, noeasynkrontSome need to be up all the time, some need low responsetimewe keep on drawing, vi skaperdetsystemetsomsvarerpå needs bådetilfunksjonelleogikke-funksjonellebehov.Tilslutttegner vi inn et repository, en database.
- Challenge vi møtervedåtegne inn én database er at en database ofteikkevilværenoktilå meet the customers needsBruker du en relasjonsdatabasesåfår du utfordringer med performance, object relational impedance ogskaleringBruker du en key-value-database får du utfordringer med oppløsningenpådataeneogrelasjonerBruker du en grafdatabasefår du utfordringer med skaleringog lookupsUansetthvilken database du velgersåvil du fåutfordringer. Vi erklar over disseutfordringene, likevelvelger vi åikkegjørenoe med det
- Vi harsålett for åvelgesammedatabaseteknologihver gang, utenå se nøyepåbehovene.Hvis vi studererbehovenenøye, såvil vi se at valgavdatabasetechnologyikkeersåenkeltsom man skulletro..
- Dersom du ønskerpersistensiarkitekturen din såerdetfordi du ønskerålagreog lese data. Deterdetprimærebehovet.Do The Simplest Thing That Could Possibly Work. Nårbehoveterålagreog lese data, såerdetenkleste en ren key/value store. Detviktigstemålet med databasener at den erenkelog at domenet matcher de lagrededataene best mulig
- Detervelog bra åkunne lese ogskrive data. Men man måsom regel kunnesøkeidataeneogså. Vi ønskeråfinnepersonervhanavn. Vi ønskeråfinneallesomharadressei Oslo etc etc.. og en key-value store erikkeså god påfulltekstsøk.. forsåvidtikke en relasjonsdatabaseheller.. Så vi trenger en søkemotor. Detteer et behovjeghar sett oppståi mange forskjelligeprodukter. Microsoft kjøpte Fast så de kunnefå en søkemotoriSharepoint. De haddeallerede en relasjonsdatabaseibunn, men fantut at detvargreitåbrukelittpengerpå en søkemotor. Allecms-verktøyharbåde database ogsøkemotor, ogfleresaksbehandlingsapplikasjonerjegharværtborteihardettebehovet.Så.. for åkunnesøkegodtivåredataersåtenger vi en søkemotor..ogdeterjoikkenoe problem. Vi legger inn et kalltilsøkemotorenhver gang vi oppdatererdatabasen. Kanskje hiver opp en synkroniseringsjobbhvernatt for åværesikker.. men dettekomplisererikkearkitekturenvårveldig
- En ting søkemotorerikkeerså bra påerrelasjonssøk. Si for eksempeljegskallaget en ansattdatabase for et konsulenthus. Selgerenskriver et tilbud for en kunde, ogkundenhar stilt kravtilfagkunnskapogerfaring. Han ønsker kun konsulentersomharjobbet med F# hos minimum 2 kunder. Den spørringenerlitt lei åfåtili en relasjonsdatabase. I en grafdatabaseerdennespørringenveldigenkel, ogikkeminstlynrask.Så for dettebehovetvelger vi oss en grafdatabase.
- Her erdetmyesomkangågalt.. men detblirmyedupliseringavlogikk her.For detførste. Applikasjonenkanikkeforholdesegtilalledisseforskjelligedatabasene.. så vi fjernerrelasjonen.I tillegg. Databasenebørhellerikkekjennetilhverandre, så vi fjernerdem
- Ogsåreorganiserer vi litt..
- Så…Visnakker med en key value store, men vi snakkerikke med noenandre.For at de andreskalfånoe data åforholdesegtil, såinnfører vi en eventstore. Alleendringerav data ivårapplikasjon lager en event. Våredatabaserlytterpådennekøen, ogoppdatererdataene sine lokalt. Serpåeventen, oglagrer de dataenesomerinteressante for seg.Dettebørforøvrigvære en persistent eventstore. Hvisgrafdatabasengårned for en periode, såskal man kunnespilletilbake events somermistet, eller man fårbehov for en heltny database…
- Plutseligkommerdatavarehusfolkenepåbanene, ellerøkonomene, ellerstatistikkgutta.. De vilgenerererapporter. De vil ha statistikk..Hyggeligdet, ogviktig.. Detenesteproblemeter at vi harikkenoen database somtilfredstillerderesbehov. Detteerikkenoe problem. Vi hareventstoren, ogdeterikkeværreennåpluggepå en relasjonsdatabasesomlytterpåeventeneog vi er good to go..Tre store positive ting med dette. 1. Vi kjenteikketilbehovet for rapportertidligere, men pgaeventstoremodellensåkunne vi enkeltleggetil en ny database 2. Iom at alleeventene ligger lagretsåkan vi enkeltsetteopp en ny database med gamle data utenåmåttekjøre en styggkonverteringsjobb. 3. Rapporteringsdatabasenbrukes kun avdem, ikkeavoss. Så de kankjøresåtungerapporter de vil. Detpåvirkerikkevårapplikasjondetminste.
- Sådetteer polyglot persistence.Man vet at detikkefinnesnoen silver bullet. Programming language, libraries, operating systems.. and database!Så man velger den databasensomtilfredstiller de behovene man har der og da..Dettemåikkeimplementeres med en event drevetarkitektur, men dethjelper..Man girkundendet den vil ha først, ogkanenkeltutvidesdersomdetdukkeroppnyebehovetterhvert. For detgjør det..