Your SlideShare is downloading. ×
  • Like
Polyglot Persistance con PostgreSQL, CouchDB, MongoDB, Redis e OrientDB
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Now you can save presentations on your phone or tablet

Available for both IPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Polyglot Persistance con PostgreSQL, CouchDB, MongoDB, Redis e OrientDB

  • 2,176 views
Published

Pirma parte del seminario su NoSQL al DiTeDi di Udine del 15/12/2012. Affrontato il caso di studio di un'architettura enterprise, basata su datastore relazionali (PostgreSQL) e non (CouchDB, MongoDB, …

Pirma parte del seminario su NoSQL al DiTeDi di Udine del 15/12/2012. Affrontato il caso di studio di un'architettura enterprise, basata su datastore relazionali (PostgreSQL) e non (CouchDB, MongoDB, Redis e OrientDB).

Published in Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
No Downloads

Views

Total Views
2,176
On SlideShare
0
From Embeds
0
Number of Embeds
2

Actions

Shares
Downloads
31
Comments
1
Likes
6

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Polyglot Persistance Esempio di architettura basata su PostgreSQL, CouchDB, MongoDB, Redis e OrientDB DiTeDi, Udine - Italia 15-12-2012
  • 2. @maraspin
  • 3. @stefanovalle
  • 4. http://www.mvassociati.it/
  • 5. IL CONTESTO
  • 6. L’OBIETTIVO
  • 7. DATI IN TEMPO REALE
  • 8. REPERIMENTO FEEDBACK IMMEDIATO
  • 9. MENO HARDWARE NEGLI HOTEL
  • 10. Partiamo da stack LAMP/LAPP 11
  • 11. PostgreSQL Backend 12
  • 12. Chi usa PostgreSQL? 13
  • 13. Gestione "meta" dati di: • Hotel • Applicazioni • Configurazioni • Personalizzazioni • Utenti • ACL • RELAZIONI tra essi 14
  • 14. Modello relazionale 15 Film Titolo Nome Categoria Rating Categoria Anno Visioni Gradimenti Voto
  • 15. Diamo un’occhio ai dati… 16 E se voglio cambiare rating per i drammatici?
  • 16. Normalizzazione 17
  • 17. Schema aggiornato 18
  • 18. Come sono memorizzati i dati 19
  • 19. E se vogliamo un report? 20 SELECT film_normal.* , categoria.* FROM film_normal JOIN categoria on categoria.id = film_normal.categoria_id
  • 20. JOIN: Operazione impegnativa 21 X Morale: considerare sempre i benefici della normalizzazione. Ci torniamo tra poco!
  • 21. Indici 22 EXPLAIN ANALIZE SELECT … O(N) -> O(log N)
  • 22. PostgreSQL vs MySQL 23 Idea: SELECT titolo, max(visioni) FROM film; Qual’è il film più visto?
  • 23. MySQL 24 SELECT titolo, max(visioni) FROM film;
  • 24. PostgreSQL 25 SELECT titolo, max(visioni) FROM film; SELECT titolo, max(visioni) FROM film; SQL error: ERROR: column "film.titolo" must appear in the GROUP BY clause or be used in an aggregate function at character 8 In statement: SELECT titolo, max(visioni) FROM film;
  • 25. PostgreSQL 26 SELECT titolo, max(visioni) FROM film; SELECT titolo, max(visioni) FROM film; SQL error: ERROR: column "film.titolo" must appear in the GROUP BY clause or be used in an aggregate function at character 8 In statement: SELECT titolo, max(visioni) FROM film;
  • 26. 27 Disclaimer: Ciò non significa che non utilizziamo anche MySQL in determinati contesti Ocio però!
  • 27. Perchè cio? 28 Risultato Casuale SELECT titolo, max(visioni) FROM film;
  • 28. Tabelle Sparse 29
  • 29. Possibile Soluzione 30 CREATE VIEW film AS SELECT titolo, anno, visioni FROM film_provider1 UNION SELECT titolo, anno, visioni FROM film_provider2;
  • 30. POI SU UPDATE…
  • 31. Alternativa 32
  • 32. Supporto per Ereditarietà 33 CREATE TABLE film ( id integer NOT NULL, titolo character varying(50), anno integer, visioni integer ); CREATE TABLE film_provider1 ( gradimenti integer ) INHERITS (film); CREATE TABLE film_provider2 ( voto integer ) INHERITS (film);
  • 33. Comportamento dell’Ereditarietà 34 select * from film; select * from film_provider1;
  • 34. Write Ahead Log (Journal) • Apri il Log • Scrivici informazioni tipo “Questo dato va qui (offset)” • Scrivi il file • Tenta il salvataggio su disco (fsync) • Modifica i dati • Segna sul Log che le operazioni sono state compiute 35 http://www.depesz.com/2011/07/14/write-ahead-log-understanding-postgresql-conf-checkpoint_segments-checkpoint_timeout-checkpoint_warning/
  • 35. Durevolezza dei Dati 36
  • 36. MVCC 37 Supporto AutoVacuum
  • 37. Replicazione con LOG – 8.4 38
  • 38. Replicazione Streaming - 9.0 39
  • 39. Replicazione Sincrona - 9.1 40
  • 40. Failover 41
  • 41. Cosa portare a casa: • Solido e Affidabile (Ingres 1974) • Potenti strumenti di programmazione (PL/PGSQL, PL/Python, PL/Java, ...) • Object-Relational Database (eredità) • Interessanti add-ons (IE fuzzystrmatch) • Replicazione Master/Slave Integrata • PostGIS • Community estesa, know how consolidato 42
  • 42. Da dove eravamo partiti? 43
  • 43. E SE…
  • 44. DISTRIBUZIONE DATI E LOGICA
  • 45. 47
  • 46. COERENZA DEI DATI
  • 47. DISPONIBILITÀ DEL SERVIZIO
  • 48. Non potete avere tutto, ragazzi! Prof. Eric Brewer http://www.cs.berkeley.edu/~brewer/
  • 49. Se volete distribuire una base dati, qualora si venga a creare un partizionamento, dovete scegliere tra coerenza dei dati e disponibilità del servizio. CAP Theorem, Nancy Lynch and Seth Gilbert, “Brewer's conjecture and the feasibility of consistent, available, partition-tolerant web services”, ACM SIGACT News, Volume 33 Issue 2 (2002), pg. 51-59.
  • 50. Vediamo che significa 52
  • 51. Vediamo che significa 53 Uno o più nodi non raggiungibili: partizonamento
  • 52. Vediamo che significa 54 HotelFarm Uno o più nodi non raggiungibili: partizonamento
  • 53. 55
  • 54. RINUNCIA ALLA DISPONIBILITÀ?
  • 55. Non scordiamo neppure la latenza!
  • 56. CAP Theorem 58 Consistency Availability Partition Tolerance
  • 57. Soluzioni disponibili 59 Consistency Availability Partition Tolerance Categoria CP: BigTable Hbase MongoDB Redis Memcached etc. Categoria CA: RDBMS etc. Categoria AP: DynamoDB CouchDB Cassandra SimpleDB Tokyo Cabinet Riak Voldemort etc.
  • 58. Soluzioni disponibili 60 Consistency Availability Partition Tolerance Categoria CP: BigTable Hbase MongoDB Redis Memcached etc. Categoria CA: RDBMS etc. Categoria AP: DynamoDB CouchDB Cassandra SimpleDB Tokyo Cabinet Riak Voldemort etc.
  • 59. Come abbiamo scelto? • Supporto multi-master • Facilità di sincronizzazione applicazione • Flessibilità del modello dati • Semplicità 61
  • 60. Soluzioni disponibili 62 Consistency Availability Partition Tolerance Categoria CP: BigTable Hbase MongoDB Redis Memcached Scalaris etc. Categoria CA: RDBMS GreenPlum etc. Categoria AP: DynamoDB CouchDB Cassandra SimpleDB Tokyo Cabinet Riak Voldemort etc.
  • 61. 63 “designed with the web in mind”
  • 62. Cos’è CouchDB? • Datastore Documentale (JSON) • Interfaccia HTTP • Replicazione master-master (con filtri) • Può contenere applicazioni Web HTML/CSS/JS (Couchapp) • Pensato per contesti distribuiti • Un progetto dalla storia “travagliata” 64
  • 63. Incontriamo Futon (demo live) 65
  • 64. Schemaless 66
  • 65. Schemaless 67
  • 66. Replicazione Semplice 68 Supporto per modalità PULL e PUSH
  • 67. Ma Semplice Davvero! 69 Aggiornati non solo i dati ma anche le viste (design docs)
  • 68. Scenario di conflitto 70 CouchDB – The definitive guide – O’Reilly
  • 69. Risoluzione del Conflitto 71 CouchDB – The definitive guide – O’Reilly
  • 70. Versioni • ID / _rev • Meglio generare da se gli ID (sequenziali) • Aggiornamenti atomici sui documenti • Aggiornamento ottimista, MVCC • Coerenza Eventuale 72
  • 71. POSSIAMO RISOLVERE I CONFLITTI
  • 72. O CERCARE DI EVITARLI
  • 73. Progettiamo per evitarli 75 { "titolo": "Il Padrino", "sommario": "..." "visioni": 3873, "gradimenti": 185, } Provider Camera 1 Camera 2
  • 74. Progettiamo per evitarli 76 { "titolo": "Il Padrino", "sommario": "...", "visioni": 3873, "gradimenti": 185, } Provider Camera 1 Camera 2 { "titolo": "Il Padrino", "sommario": "...", "visioni": 3873, "gradimenti": 185, }
  • 75. Progettiamo per evitarli 77 { "titolo": "Il Padrino", "sommario": "..." } Provider Camera 1 Camera 2 { "titolo": "Il Padrino", "visioni": 3873, "gradimenti": 185, } MVCC
  • 76. Progettiamo per evitarli 78 { "titolo": "Il Padrino", "sommario": "..." } Provider Camera 1 Camera 2 { "titolo": "Il Padrino", "visioni": 3873, "gradimenti": 185, } { "titolo": "Il Padrino", "visioni": 3873, "gradimenti": 185, } { "titolo": "Il Padrino", "sommario": "..." }
  • 77. 79
  • 78. 80
  • 79. CouchApps 81
  • 80. LOGICA LATO CLIENT
  • 81. SVILUPPATORI SERVER-SIDE
  • 82. 84
  • 83. RELAZIONI METADATI
  • 84. Classico Backend 86
  • 85. WebApps Generate Server Side 87
  • 86. 88
  • 87. E QUINDI PRESENTATE AI CLIENT
  • 88. Alto consumo di disco 90 0 2000 4000 6000 8000 10000 12000 14000 16000 DB Size (MB) NB Quanto sopra su update!
  • 89. Btree+, che Succede? 91 Questione di affidabilità, performance
  • 90. COMPATTIAMO QUANDO POSSIBILE…
  • 91. Indicatori di Performance • 350 evt/sec in inserimento • 3000 evt/sec se in batch mode • 100 evt/sec su update • 10 evt/sec durante compattazione 93 • NB: dati forniti unicamente per dare ordini di grandezza. Test eseguiti su server entry level IBM x3550 M3, 1x3.60 GHz Xeon, 4GB RAM, Dischi SAS in RAID 0 • CouchDB configurato con httpd max_connections = 2048, export ERL_MAX_PORTS=4096, export ERL_FLAGS="+A 4«, fsync
  • 92. 94
  • 93. 95
  • 94. DI COSA AVREMMO BISOGNO?
  • 95. SHARDING
  • 96. Sharding 98
  • 97. Da considerare: • Inerentemente più rischioso • Più onerosa la manutenzione e il backup degli shard • Delicato decidere con quali criteri • In SQL: “Join” tra shards costosi. Replicazione delle tabelle “globali” – es. categorie film 99
  • 98. Una possibile soluzione 100
  • 99. Recap su CouchDB: • Ottima soluzione per contesti distribuiti • Non adatto per situazioni con frequenti aggiornamenti e carichi (ingenti) costanti • API REST aiuta a scalare le letture • Bigcouch in aiuto sulle scritture • Architetture innovative con le Couchapp • Si possono usare strumenti Tipici Web: HAproxy, Nginx 101
  • 100. Da Tenere a Mente: • Attenzione alla generazione degli ID, specie se distribuiti • Lo spazio su disco cresce e la compattazione «inchioda» lo strumento • I «driver» disponibili non sempre sono di alta qualità... 102
  • 101. Da Tenere sotto controllo: • TouchDB database CouchDB compatibile, adatto all’embedding in device mobili • PouchDB libreria js: come avere CouchDB nel browser 103
  • 102. Ulteriori Esigenze 104
  • 103. “L’aggregatore” 105 RSS Previsioni meteo Vimeo Eventi ... Aggregatore
  • 104. Architettura dell’aggregatore 106 RSS Previsioni meteo Vimeo Eventi ... REST API Crawler CDN
  • 105. Cosa scegliamo? 107 RSS Previsioni meteo Vimeo Eventi ... REST API Crawler CDN ?
  • 106. Cosa ci serve? • Flessibilità del modello dati • Semplicità • Facilità di dialogo con PHP • Scalabilità sulle letture • Flessibilità di query 108
  • 107. Perché no CouchDB? • Flessibilità del modello dati • Semplicità • Facilità di dialogo con PHP • Scalabilità sulle letture • Flessibilità di query 109
  • 108. INTERAGIRE CON COUCHDB
  • 109. Quante visioni hanno avuto i film in totale?
  • 110. MAP REDUCE
  • 111. 113 { "_id": "39c7c57daddba704c2b04606de001373", "info_type": "view", "movie": "The Gladiator", "views": 37 } { "_id": "39c7c57daddba704c2b04606de000a2f", "info_type": "view", "movie": "Spiderman", "views": 10 } { "_id": "39c7c57daddba704c2b04606de000c92", "info_type": "view", "movie": "Shrek", "views": 25 }
  • 112. 114 { "movie": "Spiderman", "views": 10 } { "movie": "The Gladiator", "views": 37 } { "movie": "Shrek", "views": 25 }
  • 113. 115 { "movie": "Spiderman", "views": 10 } { "movie": "The Gladiator", "views": 37 } { "movie": "Shrek", "views": 25 } 10 37 25
  • 114. 116 { "movie": "Spiderman", "views": 10 } { "movie": "The Gladiator", "views": 37 } { "movie": "Shrek", "views": 25 } 10 37 25 47 25
  • 115. 117 { "movie": "Spiderman", "views": 10 } { "movie": "The Gladiator", "views": 37 } { "movie": "Shrek", "views": 25 } 10 37 25 47 25 72
  • 116. 118 { "movie": "Spiderman", "views": 10 } { "movie": "The Gladiator", "views": 37 } { "movie": "Shrek", "views": 25 } 10 37 25 47 25 72 MAP
  • 117. 119 { "movie": "Spiderman", "views": 10 } { "movie": "The Gladiator", "views": 37 } { "movie": "Shrek", "views": 25 } 10 37 25 47 25 72 REDUCE
  • 118. In CouchDB 120 function(doc) { if (doc.info_type == 'view') { emit(doc.movie, doc.views); } } Map: { "_id": "39c7c57...", "info_type": "view", "movie": "The Gladiator", "views": 37 }
  • 119. Cosa fa il map? 121 Map: function(doc) { if (doc.info_type == 'view') { emit(doc.movie, doc.views); } } { "movie": "Spiderman", "views": 10 } { "movie": "The Gladiator", "views": 37 } { "movie": "Shrek", "views": 25 } 10 37 25
  • 120. Cosa fa il reduce? 122 Reduce: function (key, values, rereduce) { return sum(values); } 10 37 25 47 25
  • 121. Dov’è il problema? 123 function(doc) { if (doc.info_type == 'config') { for (param in doc.params) { emit(param, doc.params[param]); } } } Map: Reduce: .... Non possiamo avere parametri in input! Viste precalcolate su ciascun documento
  • 122. 124 “Hu(mongo)us”
  • 123. About MongoDB • Datastore Documentale (JSON) • Database / Collezioni • Protocollo Binario • Tanto Marketing • Veloce quasi come /dev/null :-P • Update in place -> locks! • Flessibilità nelle query • Autosharding 125
  • 124. Interagire con il DB è banale 126
  • 125. Attenzione! 127
  • 126. Query 128 // operatori di confronto db.notizie.find({tipo: {$ne: ‘cnn’}, ora_reperimento: {$gt: 1352505039} }); // eventi di oggi e (necessariamente) domani db.evento.find( { data: { $all: [ ‘2012-11-10’, ‘2012-11-11’ ] } } ); // eventi di oggi e/o domani db.evento.find( { data : { $in : [‘2012-11-10’ ‘2012-11-11’ ] } } ); // eventi di una giornata sola db.evento.find( { data : { $size: 1 } } ); // cerca dentro gli array db.previsioni.find( { ‘settimana.temp_max’ : 20 } );
  • 127. Performance VS Durevolezza 129 Le impostazioni predefinite (32bit e <v2.0) sono “rischiose” (no journal)
  • 128. Performance VS Durevolezza 130 MongoDB a 32bit NON VA USATO in PRODUZIONE!
  • 129. Replica Set 131 http://docs.mongodb.org/manual/core/replication/
  • 130. Automated Failover 132
  • 131. Recap su MongoDB: • Semplice (arma a doppio taglio!) • Linguaggio d’interrogazione potente • Ottima documentazione • Flessibilità nella configurazione • Driver disponibili per molti linguaggi • Sviluppo molto attivo • Supporto 133
  • 132. Fare attenzione a: • Opzione safe, journaling • Si inchioda negli ordinamenti se non definiti indici • Attenzione ai nomi! • Non farsi coinvolgere e cercare di costruirci sopra DB relazionali 134
  • 133. 135
  • 134. TUTTO A POSTO SIGNORE!
  • 135. Cosa abbiamo considerato? • Performance • Semplicità • Expiration automatico dei valori • Gestione del cold start • Non è un problema la perdita di dati -> Ok persistenza volatile, no replicazione 137
  • 136. Perchè no Couch/Mongo? • Couch occupa troppo spazio, troppo lento • MongoDB poteva starci (soprattutto perché TTL introdotte da poco – 12/09); • Ma ci sono soluzioni più semplici… 138
  • 137. 139 “An open source, advanced key-value store”
  • 138. About Redis • Key/Value++ • Progetto Italiano (Salvatore Sanfilippo) • Protocollo Binario • Sponsorizzato da VMWare • Gestione expiry delle chiavi 140
  • 139. Esempi di query 141 // Memorizzare un valore > SET status ok // Collezioni > SADD luci_accese camera bagno // Valore con scadenza prefissata > SET status ok > EXPIRE status 10 // in secondi
  • 140. Sorted Sets 142
  • 141. Recap su Redis: • E’ molto veloce • Salva su RAM (snapshot su disco) • E’ un’ottima soluzione di caching, evitando problema cold start • Necessario avere abbastanza RAM • Può essere usato per delegare alcuni calcoli costosi 143
  • 142. 144
  • 143. COME STANNO ANDANDO LE COSE?
  • 144. Cosa ci serve? • Gestire grandi moli di dati • Modello di dati che supporti correlazione 146
  • 145. Com’è fatta una nostra app? 147
  • 146. E una sessione d’uso? 148
  • 147. E una sessione d’uso? 149
  • 148. E una sessione d’uso? 150
  • 149. E una sessione d’uso? 151
  • 150. Cosa ci ricorda tutto ciò? 152
  • 151. G=(V,E)
  • 152. Un semplcie grafo 154
  • 153. Con strumenti visti prima… • Query di Couch poco flessibili • Redis assenza indici secondari • MongoDB e Postgres forse ok ma limiti nel traversare nodi non immediatamente adiacenti 155
  • 154. Troviamo le visite a partire dalla dashboard in un determinato periodo
  • 155. Con RDBMS 157 SELECT p1 . * , p2 . * , v . * FROM pagina AS p1 JOIN visita AS v ON v.pagina_da = p1.id JOIN pagina AS p2 ON v.pagina_a = p2.id WHERE p1.id =1 AND v.data_visita >0 AND v.data_visita <4
  • 156. Il problema… 158 SELECT p1 . * , p2 . * , v . * FROM pagina AS p1 JOIN visita AS v ON v.pagina_da = p1.id JOIN pagina AS p2 ON v.pagina_a = p2.id WHERE p1.id =1 AND v.data_visita >0 AND v.data_visita <4 O(log N) O(log M) O(log N)
  • 157. Invece con un grafo: 159 O(1) O(1) Adiacenza senza necessità di consultare un indice!
  • 158. 160 “Multiple datamodels support”
  • 159. Modello Dati 161
  • 160. https://github.com/tinkerpop/blueprints/wiki/Property-Graph-Model
  • 161. Interagire con OrientDB • Protocollo binario / REST • JSON • Tinkerpop Stack: Gremlin, Pipes • SQL(+) 163
  • 162. Select titolo, in.out.in.nome from #16:5
  • 163. Replica Master-Master Sync/Async - Configurabile 165
  • 164. Recap su OrientDB: • Ottima soluzione per gestire relazioni • Traversa 5 Milioni+ di record/sec • Progetto Italiano (Luca Garulli) • ACID • Supporta ereditarietà • Semplice da installare e avviare 166
  • 165. 167
  • 166. Ringraziamento 168 Il know how utilizzato per la preparazione di questa presentazione è stato in buona parte acquisito durante lo sviluppo del sistema Hotel OnAir di concezione e proprietà di VDA Multimedia Spa, cui il case study di cui si è fatto accenno fa riferimento. Ringraziamo il team leader del progetto, Stefano Brenelli, e tutto il team di sviluppo, per l'interessante, edificante e proficua collaborazione. In particolare ringraziamo: Carlo Anselmi, Maurizio Battistella, Manuel Bitto, Nicola Busanello, Antonino Murador, Antonio Parrella, Nicola Pressi, Riccardo Zamuner, Michele Zanon, Tiziano Zonta. Ringraziamo anche i colleghi Diego Drigani e Dario Tion, nonchè tutto il PUG Friuli per i sempre utili confronti e consigli.
  • 167. DOMANDE?
  • 168. http://friuli.grusp.org/
  • 169. http://www.ditedi.it/
  • 170. Image Credits • http://www.flickr.com/photos/leandrociuffo/4128603357/ • http://www.flickr.com/photos/uggboy/8043043095/ • http://www.flickr.com/photos/kky/704056791/ • http://www.flickr.com/photos/shareandenjoy/7074965023/ • http://www.flickr.com/photos/ivyfield/4497654857/ • http://www.flickr.com/photos/craigmarren/6086280669/ • http://www.flickr.com/photos/getbutterfly/6317955134/ • http://www.flickr.com/photos/62698615@N08/5948655391/ • http://20bits.com/article/interview-questions-database-indexes • http://www.flickr.com/photos/iita-media-library/4808291918/ • http://www.flickr.com/photos/47108884@N07/6949078701/ • http://www.flickr.com/photos/rrrodrigo/4139483872/ • http://www.flickr.com/photos/latt/509790815/ • http://www.flickr.com/photos/spine/525988813/ • http://www.flickr.com/photos/latt/509790815/ • http://www.flickr.com/photos/antmoose/116845021/ • http://www.flickr.com/photos/charleylhasa/3374499088/ • http://www.flickr.com/photos/mcascherrypoint/6277623762/ • http://www.flickr.com/photos/superk8/2801590280/ • http://www.flickr.com/photos/cawley/1067814030/ • http://www.flickr.com/photos/mr_g_travels/863720665/ • http://www.flickr.com/photos/cortesdecima/6099516346/ • http://www.flickr.com/photos/portofsandiego/7777282856/ • http://www.flickr.com/photos/22750018@N05/4268345597/ • http://www.flickr.com/photos/petereed/132829587/ • http://www.flickr.com/photos/myfruit/7031263653/ • http://www.flickr.com/photos/maugiart/5014963068/ • http://www.flickr.com/photos/freefoto/3844247553/ • http://www.flickr.com/photos/incognito_rico/69242116/ • http://tinkerpop.com/ • http://www.slideshare.net/lvca/orientdb-distributed-architecture-11h • ttp://www.flickr.com/photos/dobs/4128798936/ 172
  • 171. Grazie per l’attenzione Stefano Maraspin @maraspin s.maraspin@mvassociati.it Stefano Valle @stefanovalle s.valle@mvassociati.it