NoSQL, No Worries: Vecchi Problemi, Nuove Soluzioni

1,793 views

Published on

Slide del talk sulle basi di dati non relazionali (NoSQL) al Codemotion di Venezia del 17/11/2012. Presentato un caso di studio di architettura basata su CouchDB, MongoDB, Redis e OrientDB, oltre che diversi concetti relativi ai datastore NoSQL.

Published in: Technology

NoSQL, No Worries: Vecchi Problemi, Nuove Soluzioni

  1. 1. NoSQL, No Worries Vecchi problemi, nuove soluzioniStefano MaraspinMV Associati
  2. 2. @maraspin
  3. 3. PARTIAMO DA UN CASE STUDY
  4. 4. L’OBIETTIVO
  5. 5. Classico Stack LAMP/LAPP
  6. 6. E SE?
  7. 7. DISTRIBUZIONE DATI, LOGICA
  8. 8. VOGLIAMO ALTA DISPONIBILITÀ…
  9. 9. …E COERENZA SUI DATI
  10. 10. Non potete avere tutto, ragazzi! Prof. Eric Brewer http://www.cs.berkeley.edu/~brewer/
  11. 11. H F
  12. 12. Non scordiamo neppure la latenza!
  13. 13. ConsistencyPartition AvailabilityTolerance
  14. 14. Categoria CP: BigTable Hbase Categoria CA: MongoDB* RDBMS Riak* Redis Consistency Memcached Scalaris etc.Categoria AP:DynamoDBCouchDB PartitionCassandra AvailabilityMongoDB* ToleranceTokyo CabinetRiak*Voldemortetc. * Posizione configurabile
  15. 15. Categoria CP: BigTable Hbase Categoria CA: MongoDB* RDBMS Riak* Redis Consistency Memcached Scalaris etc.Categoria AP:DynamoDBCouchDB PartitionCassandra AvailabilityMongoDB* ToleranceTokyo CabinetRiak*Voldemortetc. * Posizione configurabile
  16. 16. Cosa abbiamo considerato per la scelta?• Supporto multi-master configurabile• Facilità di sincronizzazione dati e applicazione• Flessibilità del modello dati• Semplicità
  17. 17. Categoria CP: BigTable Hbase Categoria CA: MongoDB RDBMS Riak Redis Consistency Memcached Scalaris etc.Categoria AP:DynamoDBCouchDBCassandra Partition AvailabilityMongoDB ToleranceTokyo CabinetRiakVoldemortetc.
  18. 18. “designed with the web in mind”
  19. 19. Cos’è CouchDB?• Datastore che parla HTTP• Modello dati documentale (JSON)• Pensato per contesti distribuiti• Replicazione master-master• Può contenere intere applicazioni Web lato client HTML/CSS/JS (couchapp)
  20. 20. SVILUPPATORISERVER-SIDE
  21. 21. RELAZIONIMETADATI
  22. 22. Problema di spazio16000 DB Size (MB)1400012000100008000600040002000 0 NB Quanto sopra su update!
  23. 23. LA COMPATTAZIONE
  24. 24. Prestazioni durante la compattazione• 350 evt/sec in inserimento• 3000 evt/sec se in batch mode• 100 evt/sec su update• 10 evt/sec durante compattazioneNB: dati forniti unicamente per dare ordini di grandezza. Test eseguiti su server entry level IBM x3550 M3, 1x3.60GHz Xeon, 4GB RAM, Dischi SAS in RAID 0; CouchDB configurato con httpd max_connections = 2048, exportERL_MAX_PORTS=4096, export ERL_FLAGS="+A 4«, fsync
  25. 25. ULTERIORE ESIGENZA
  26. 26. RSS REST Previsioni Crawler API meteo Video Eventi ...CDN
  27. 27. RSS REST Previsioni Crawler API meteo Video Eventi ? ...CDN
  28. 28. Cosa ci serve?• Flessibilità del modello dati• Facilità di dialogo con PHP• Contesto non distribuito• Durevolezza non fondamentale• Prestazioni• Flessibilità di query
  29. 29. Perchè no CouchDB?• Flessibilità del modello dati• Facilità di dialogo con PHP• Contesto non distribuito• Durevolezza non fondamentale• Prestazioni• Flessibilità di query
  30. 30. LE QUERY IN COUCHDB: MAP REDUCE
  31. 31. Quante visioni hannoavuto i film in totale?
  32. 32. { "_id": "39c7c57daddba704c2b04606de000a2f", "info_type": "view", "movie": "Spiderman", "views": 10}{ "_id": "39c7c57daddba704c2b04606de001373", "info_type": "view", "movie": "The Gladiator", "views": 37}{ "_id": "39c7c57daddba704c2b04606de000c92", "info_type": "view", "movie": "Shrek", "views": 25}
  33. 33. { { { "movie": "Spiderman", "movie": "The Gladiator", "movie": "Shrek", "views": 10 "views": 37 "views": 25} } }
  34. 34. { { { "movie": "Spiderman", "movie": "The Gladiator", "movie": "Shrek", "views": 10 "views": 37 "views": 25} } } 10 37 25
  35. 35. { { { "movie": "Spiderman", "movie": "The Gladiator", "movie": "Shrek", "views": 10 "views": 37 "views": 25} } } 10 37 25 47 25
  36. 36. { { { "movie": "Spiderman", "movie": "The Gladiator", "movie": "Shrek", "views": 10 "views": 37 "views": 25} } } 10 37 25 47 25 72
  37. 37. { { { "movie": "Spiderman", "movie": "The Gladiator", "movie": "Shrek", "views": 10 "views": 37 "views": 25} } } 10 37 25MAP 47 25 724
  38. 38. { { { "movie": "Spiderman", "movie": "The Gladiator", "movie": "Shrek", "views": 10 "views": 37 "views": 25} } } 10 37 25REDUCE 47 25 724
  39. 39. Map:function(doc) { if (doc.info_type == view) { emit(doc.movie, doc.views); }} { "_id": "39c7c57...", "info_type": "view", "movie": "The Gladiator", "views": 37 }Reduce:function (key, values, rereduce) { return sum(values);}
  40. 40. Map: Il problema è qui!function(doc) { if (doc.info_type == view) { emit(doc.movie, doc.views); }} { "_id": "39c7c57...", "info_type": "view", "movie": "The Gladiator", "views": 37 }Reduce:function (key, values, rereduce) { return sum(values);}
  41. 41. “Hu(mongo)us”
  42. 42. Cos’è MongoDB:• Datastore Documentale (JSON)• Protocollo Binario• Update in place -> locks!• Flessibilità nelle query
  43. 43. Performance VS Data SafetyLe impostazioni predefinite sono “rischiose” (fsync ogni minuto).Consigliata la replicazione per “stare tranquilli” e avere alta disponibilità.
  44. 44. Replica Set
  45. 45. Failover
  46. 46. A cosa fare attenzione?• Nomi su database/collection: su errore, lui crea le entità specificate senza avvisare*• Ordinamenti senza indici: raggiunto un certo quantitativo di dati non rallenta ma errore*• Non farsi coinvolgere dalla flessibilità di query e cercare di costruirci sopra DB con relazioni * esperienze con driver PHP
  47. 47. TUTTO APPOSTO SIGNORE!
  48. 48. Cosa ci serve per un sistema di monitoring?• Performance• Semplicità• Expiration automatico dei valori• Gestione del cold start• Non è un problema la perdita di dati -> Ok persistenza volatile, no replicazione
  49. 49. Perchè no CouchDB, MongoDB?• Couch occupa troppo spazio, troppo lento• MongoDB non supportava TTL• Ci basta qualcosa di molto più semplice
  50. 50. “Hey that’s Merz!”
  51. 51. Cos’è Redis?• Key/Value++• Protocollo Binario• Salva su RAM (snapshot su disco, evita problema cold start)• Necessario avere abbastanza RAM
  52. 52. Dialogare con Redis// Memorizzare un valore> SET status ok// Collezioni> SADD luci_accese camera bagno// Valore con scadenza prefissata> SET status ok> EXPIRE status 10 // in secondi
  53. 53. COME STANNO ANDANDO LE COSE?
  54. 54. DI COSA PARLIAMO?
  55. 55. Simuliamo un’esperienza d’uso
  56. 56. Simuliamo un’esperienza d’uso
  57. 57. Simuliamo un’esperienza d’uso
  58. 58. Simuliamo un’esperienza d’uso
  59. 59. G=(V,E)
  60. 60. Quali sono state leapplicazioni più usate?
  61. 61. Database RelazionaleO(log N) O(log M) O(log N)
  62. 62. Grafo O(1) O(1)Reperimento nodi adiacenti diretto, senza necessità di consultare un indice
  63. 63. “Multiple datamodels support”
  64. 64. Modello Dati
  65. 65. Di cosa parliamo? “Interrogazioni“ con Stack Tinkerpop o SQL+
  66. 66. ACID BASEAtomic BasicConsistent AvailableIsolated Soft StateDurable Eventually Consistent
  67. 67. Quindi non ho atomicità? Aggiornamento ordineOrdine Oggetto 1 Oggetto 2 Cliente
  68. 68. DATABASE RELAZIONALI
  69. 69. NOSQL
  70. 70. Aggregate Data Modelorder_id = 1001date = 2012-11-10total_amount = 10.00€ name = Johnny surname = Appleseed product_name: Pear quantity: 2 item_price: 2.50€ total_price: 5.00€ product_name: Mango quantity: 1 item_price: 5.00€ total_price: 5.00€
  71. 71. SCHEMALESS IS A LIE!
  72. 72. Pannello AnalisiRoom TV Controllo Statistiche Dati
  73. 73. Pannello AnalisiRoom TV Controllo Statistiche API API API Metadati Dati hotel Statistiche
  74. 74. POLYGLOT PERSISTANCE
  75. 75. TRADEOFFS
  76. 76. VELOCITÀ VS PERSISTENZA
  77. 77. DISPONIBILITÀ VS COERENZA
  78. 78. SOLIDITÀ, AFFIDABILITÀ
  79. 79. E IL MODELLO DATI?
  80. 80. Dimensioni Key Value Colonne Documentale A grafo > 90% dei casi d’uso Complessità Tratto da: http://www.slideshare.net/emileifrem/an-overview-of-nosql-jfokus-2011
  81. 81. KEY/VALUE
  82. 82. DOCUMENTALE
  83. 83. GRAFO
  84. 84. A COLONNA
  85. 85. COSA PORTARE A CASA?
  86. 86. DATABASE RELAZIONALI
  87. 87. DATASTORE NOSQL
  88. 88. GRAZIE
  89. 89. DOMANDE?
  90. 90. Eventi di rilievo nell’Information Technology http://www.hubme.in/ Nome speaker Mail speaker – company or community
  91. 91. http://friuli.grusp.org/ Nome speaker Mail speaker – company or community
  92. 92. Serve aiuto con architetture NoSQL? http://www.mvassociati.it/ Nome speaker Mail speaker – company or community
  93. 93. Per approfondire
  94. 94. Per approfondire
  95. 95. Per approfondire
  96. 96. http://www.flickr.com/photos/leandrociuffo/4128603357/ http://www.flickr.com/photos/uggboy/8043043095/Photo Credits: http://www.flickr.com/photos/47108884@N07/6949078701/ http://www.flickr.com/photos/22750018@N05/4268345597/ http://www.flickr.com/photos/latt/509790815/ http://www.flickr.com/photos/iita-media-library/4808291918/ http://www.flickr.com/photos/portofsandiego/7777282856/ http://www.flickr.com/photos/shareandenjoy/7074965023/ http://www.flickr.com/photos/miggslives/5351504116/ http://www.flickr.com/photos/jabb/6956142046/ http://www.flickr.com/photos/mr_g_travels/863720665/ http://www.flickr.com/photos/polkadotcreations/2480587587/ http://www.flickr.com/photos/ppym1/387781444/ http://www.flickr.com/photos/ephotion/171928602/ http://www.flickr.com/photos/sepehrehsani/5766453552/ http://www.flickr.com/photos/jpstanley/69523927/ http://www.flickr.com/photos/lodigs/2833648828/ http://www.flickr.com/photos/freefoto/3844247553/ http://www.flickr.com/photos/ilri/7839428936/ http://www.flickr.com/photos/maugiart/5014963068/ http://www.flickr.com/photos/toptechwriter/3069396941/ http://www.flickr.com/photos/31492524@N00/3801200094/ http://www.flickr.com/photos/iita-media-library/5762064624/ http://www.flickr.com/photos/gewitterhexer/5540504147/ http://www.flickr.com/photos/djnordic/167433120/ http://www.flickr.com/photos/aidanwojtas/5879866927/ http://www.flickr.com/photos/dhwright/8012651441/ http://www.flickr.com/photos/capcase/4970062870/ http://www.flickr.com/photos/birminghammag/7979485144/ Nome speaker Mail speaker – company or community
  97. 97. Il know how utilizzato per la preparazione di questa presentazione è stato inbuona parte acquisito durante lo sviluppo del sistema Hotel OnAir diconcezione e proprietà di VDA Multimedia Spa, cui il case study di cui si èfatto accenno fa riferimento.Ringrazio il team leader del progetto, Stefano Brenelli, e tutto il team disviluppo, per linteressante, edificante e proficua collaborazione. Inparticolare ringrazio: Carlo Anselmi, Maurizio Battistella, Manuel Bitto,Nicola Busanello, Antonino Murador, Antonio Parrella, Nicola Pressi,Stefano Valle, Riccardo Zamuner, Michele Zanon, Tiziano Zonta.Ringrazio anche i colleghi Diego Drigani e Dario Tion, nonchè tutto il PUGFriuli per i sempre utili confronti e consigli. Nome speaker Mail speaker – company or community

×