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.

1. NoSQL, No Worries Vecchi problemi, nuove soluzioni
Stefano Maraspin
MV Associati

2. @maraspin

3. PARTIAMO DA UN CASE STUDY

4. L’OBIETTIVO

5. Classico Stack LAMP/LAPP

7. E SE?

8. DISTRIBUZIONE DATI, LOGICA

10. VOGLIAMO ALTA DISPONIBILITÀ…

11. …E COERENZA SUI DATI

12. Non potete avere tutto, ragazzi!
Prof. Eric Brewer
http://www.cs.berkeley.edu/~brewer/

15. H F

17. Non scordiamo neppure la latenza!

18. Consistency
Partition
Availability
Tolerance

19. Categoria CP:
BigTable
Hbase Categoria CA:
MongoDB* RDBMS
Riak*
Redis Consistency
Memcached
Scalaris
etc.
Categoria AP:
DynamoDB
CouchDB
Partition
Cassandra Availability
MongoDB* Tolerance
Tokyo Cabinet
Riak*
Voldemort
etc.
* Posizione configurabile

20. Categoria CP:
BigTable
Hbase Categoria CA:
MongoDB* RDBMS
Riak*
Redis Consistency
Memcached
Scalaris
etc.
Categoria AP:
DynamoDB
CouchDB
Partition
Cassandra Availability
MongoDB* Tolerance
Tokyo Cabinet
Riak*
Voldemort
etc.
* Posizione configurabile

21. Cosa abbiamo considerato per la scelta?
• Supporto multi-master configurabile
• Facilità di sincronizzazione dati e
applicazione
• Flessibilità del modello dati
• Semplicità

22. Categoria CP:
BigTable
Hbase Categoria CA:
MongoDB RDBMS
Riak
Redis Consistency
Memcached
Scalaris
etc.
Categoria AP:
DynamoDB
CouchDB
Cassandra Partition Availability
MongoDB Tolerance
Tokyo Cabinet
Riak
Voldemort
etc.

23. “designed with the web in mind”

24. 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)

27. SVILUPPATORI
SERVER-SIDE

28. RELAZIONI
METADATI

30. Problema di spazio
16000
DB Size (MB)
14000
12000
10000
8000
6000
4000
2000
0
NB Quanto sopra su update!

31. LA COMPATTAZIONE

32. 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 compattazione
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

33. ULTERIORE ESIGENZA

34. RSS
REST Previsioni
Crawler
API meteo
Video
Eventi
...
CDN

35. RSS
REST Previsioni
Crawler
API meteo
Video
Eventi
? ...
CDN

36. Cosa ci serve?
• Flessibilità del modello dati
• Facilità di dialogo con PHP
• Contesto non distribuito
• Durevolezza non fondamentale
• Prestazioni
• Flessibilità di query

37. Perchè no CouchDB?
• Flessibilità del modello dati
• Facilità di dialogo con PHP
• Contesto non distribuito
• Durevolezza non fondamentale
• Prestazioni
• Flessibilità di query

38. LE QUERY IN COUCHDB: MAP REDUCE

39. Quante visioni hanno
avuto i film in totale?

40. {
"_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
}

41. { { {
"movie": "Spiderman", "movie": "The Gladiator", "movie": "Shrek",
"views": 10 "views": 37 "views": 25
} } }

42. { { {
"movie": "Spiderman", "movie": "The Gladiator", "movie": "Shrek",
"views": 10 "views": 37 "views": 25
} } }
10 37 25

43. { { {
"movie": "Spiderman", "movie": "The Gladiator", "movie": "Shrek",
"views": 10 "views": 37 "views": 25
} } }
10 37 25
47 25

44. { { {
"movie": "Spiderman", "movie": "The Gladiator", "movie": "Shrek",
"views": 10 "views": 37 "views": 25
} } }
10 37 25
47 25
72

45. { { {
"movie": "Spiderman", "movie": "The Gladiator", "movie": "Shrek",
"views": 10 "views": 37 "views": 25
} } }
10 37 25
MAP
47 25
72
4

46. { { {
"movie": "Spiderman", "movie": "The Gladiator", "movie": "Shrek",
"views": 10 "views": 37 "views": 25
} } }
10 37 25
REDUCE
47 25
72
4

47. 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);
}

48. 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);
}

49. “Hu(mongo)us”

50. Cos’è MongoDB:
• Datastore Documentale (JSON)
• Protocollo Binario
• Update in place -> locks!
• Flessibilità nelle query

51. Performance VS Data Safety
Le impostazioni predefinite sono “rischiose” (fsync ogni minuto).
Consigliata la replicazione per “stare tranquilli” e avere alta disponibilità.

52. Replica Set

53. Failover

54. 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

56. TUTTO APPOSTO SIGNORE!

57. 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

58. Perchè no CouchDB, MongoDB?
• Couch occupa troppo spazio, troppo lento
• MongoDB non supportava TTL
• Ci basta qualcosa di molto più semplice

59. “Hey that’s Merz!”

60. Cos’è Redis?
• Key/Value++
• Protocollo Binario
• Salva su RAM (snapshot su disco, evita
problema cold start)
• Necessario avere abbastanza RAM

61. 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

63. COME STANNO ANDANDO LE COSE?

64. DI COSA PARLIAMO?

65. Simuliamo un’esperienza d’uso

66. Simuliamo un’esperienza d’uso

67. Simuliamo un’esperienza d’uso

68. Simuliamo un’esperienza d’uso

69. G=(V,E)

70. Quali sono state le
applicazioni più usate?

71. Database Relazionale
O(log N) O(log M) O(log N)

72. Grafo
O(1)
O(1)
Reperimento nodi adiacenti diretto, senza necessità di consultare un indice

73. “Multiple datamodels support”

74. Modello Dati

75. Di cosa parliamo?
“Interrogazioni“ con Stack Tinkerpop o SQL+

79. ACID BASE
Atomic Basic
Consistent Available
Isolated Soft State
Durable Eventually Consistent

80. Quindi non ho atomicità?
Aggiornamento ordine
Ordine
Oggetto 1
Oggetto 2
Cliente

81. DATABASE RELAZIONALI

82. NOSQL

83. Aggregate Data Model
order_id = 1001
date = 2012-11-10
total_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€

84. SCHEMALESS IS A LIE!

85. Pannello Analisi
Room TV
Controllo Statistiche
Dati

86. Pannello Analisi
Room TV
Controllo Statistiche
API API API
Metadati Dati hotel Statistiche

87. POLYGLOT PERSISTANCE

89. TRADEOFFS

90. VELOCITÀ VS PERSISTENZA

91. DISPONIBILITÀ VS COERENZA

92. SOLIDITÀ, AFFIDABILITÀ

93. E IL MODELLO DATI?

94. 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

95. KEY/VALUE

96. DOCUMENTALE

97. GRAFO

98. A COLONNA

99. COSA PORTARE A CASA?

100. DATABASE RELAZIONALI

101. DATASTORE NOSQL

102. GRAZIE

103. DOMANDE?

104. Eventi di rilievo nell’Information Technology
http://www.hubme.in/
Nome speaker
Mail speaker – company or community

105. http://friuli.grusp.org/
Nome speaker
Mail speaker – company or community

106. Serve aiuto con architetture NoSQL?
http://www.mvassociati.it/
Nome speaker
Mail speaker – company or community

107. Per approfondire

108. Per approfondire

109. Per approfondire

110. 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

111. 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.
Ringrazio il team leader del progetto, Stefano Brenelli, e tutto il team di
sviluppo, per l'interessante, edificante e proficua collaborazione. In
particolare 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 PUG
Friuli per i sempre utili confronti e consigli.
Nome speaker
Mail speaker – company or community