1.
Esempio di Architettura Distribuita basata su PHP, CouchDB e Mobile PHP Goes Mobile, Milano 13-04-2012Stefano Maraspin @maraspin

2.
Stefano Maraspin Managing Partner di MV Associati Membro Fondatore del PUG Friuli PHP 5 ZCE @maraspin s.maraspin@mvassociati.it2

3.
IL CONTESTO

4.
DOVE VOGLIAMO ARRIVARE?

5.
RAPIDITA’

6.
RISPARMIO

7.
FEEDBACK

8.
FASCINO

9.
I CLIENTI ORDINANO…

10.
LA CUCINA RICEVE

11.
FEEDBACK / REAZIONE IMMEDIATI

12.
Partiamo da...14

13.
…E SE?

14.
Allora...16

15.
Cosa scegliere?17

16.
Incontriamo Mr. Brewer http://www.julianbrowne.com/article/viewer/brewers-cap-theorem http://ksat.me/a-plain-english-introduction-to-cap-theorem/18

17.
Scelta Fatta!19

18.
Cos’è CouchDB? • Datastore Documentale (schemaless) • Database / Documenti • JSON • REST20

19.
Incontriamo Futon21

20.
Replicazione Semplice Supporto per modalità PULL e PUSH22

21.
Ma Semplice Davvero! Aggiornati non solo i dati ma anche le viste (design docs)23

22.
Versioni • ID / _rev • Aggiornamento ottimista, senza lock • MVCC • Aggiornamenti atomici sui documenti • Coerenza Eventuale24

23.
Scenario di conflitto CouchDB – The definitive guide – O’Reilly25

24.
Risoluzione del Conflitto CouchDB – The definitive guide – O’Reilly26

25.
CouchApps27

26.
Implicazione28

27.
SAREMO PRESTO DISOCCUPATI!

28.
…o forse no30

29.
Classico Backend31

30.
Business Logic32

31.
Poi tutto impacchettato33

32.
Mandato a CouchDB Localmente, poi si arrangia lui…34

33.
E QUINDI PRESENTATO AI CLIENT

34.
L’ELEFANTE LA SPUNTA SEMPRE!

35.
Parecchia scelta • Chill • Doctrine CouchDB • PHP CouchDB Extension • PHPillow • Sag • Settee • Plain CURL (don’t forget it’s HTTP)37

36.
UNA PALLOTTOLA D’ARGENTO?

37.
Alto consumo di disco 16000 DB Size (MB) 14000 12000 10000 8000 6000 4000 2000 0 NB Quanto sopra su update!39

38.
Che Succede? Questione di affidabilità, performance40

39.
C’è dell’altro • Mantenuta traccia dei documenti eliminati (replicazione) • Spazio su disco viene dedicato anche alle viste (che vengono precalcolate e quindi mantenute incrementalmente) • Quando si esegue la compattazione, fa prima una copia di tutti i dati41

40.
COMPATTIAMO QUANDO POSSIBILE…

41.
Raw Performance • 3000 evt/sec in batch mode • 400 evt/sec inserimento • 100 evt/sec update • 10 evt/sec update durante compattazione43

42.
Possiamo sempre scalare…44

43.
O forse no?45

44.
Una soluzione al problema46

45.
La Morale • CouchDB è un’ottima soluzione per contesti distribuiti • Non è adatto per le situazioni in cui ci siano frequenti aggiornamenti sui dati e carichi (ingenti) costanti • L’API REST ci aiuta a scalare le letture • Bigcouch viene in aiuto sulle scritture • L’utilizzo combinato di PHP e couchapp sembra una strada promettente47

46.
DOMANDE?

47.
Photo Credits • http://www.flickr.com/photos/saechang/4402720421/ • http://www.flickr.com/photos/koocbor/4738285092/ • http://www.flickr.com/photos/whykkk/6311281715/ • http://www.flickr.com/photos/whykkk/6311776616/ • http://www.flickr.com/photos/neeta_lind/2517034517/ • http://www.flickr.com/photos/sebastian_bergmann/2087764869/ • http://www.flickr.com/photos/mr_g_travels/863720665/sizes/l/in/photostream/ • http://www.flickr.com/photos/dobs/4128798936/sizes/l/in/photostream/ • other pictures come from fotolia archives49

48.
Grazie per l’attenzioneStefano Maraspin@maraspins.maraspin@mvassociati.it