Corso introduzione a noSQL , Politecnico di Milano, Sistemi Informativi , 12-11-2013

1. INTRODUZIONE A noSQL
Gianbattista Schieppati (MyTI Srl)
Politecnico di Milano
Corso di Sistemi informativi : 12 -11-2013

2. Mi presento:
Ing. Gianbattista Schieppati
18 anni di esperienze:

Business Intelligence (sviluppato e gestito
Infobusiness prodotto di BI più venduto in
italia)

Enterprise Search Engine (Capo progetto
per lo sviluppo di Bleen Enterprise Search
Engine)

Co-founder di MyTI- Tecnologie
Informatiche

Altri progetti (sviluppo ambienti di
sviluppo, enterprise portal, business
mobile applications, IT strategy)

3. Database Relazionali
Modello
Concettuale
Modello
Logico
Modello
Fisico
ATOMICITÀ: la transazione è indivisibile nella sua esecuzione e la
sua esecuzione deve essere o totale o nulla, non sono
ammesse esecuzioni parziali
COERENZA: quando inizia una transazione il database si trova in
uno stato coerente e quando la transazione termina il
database deve essere in un altro stato coerente
ISOLAMENTO: ogni transazione deve essere eseguita in modo
isolato e indipendente dalle altre transazioni, l'eventuale
fallimento di una transazione non deve interferire con le altre
transazioni in esecuzione
DURABILITÀ: detta anche persistenza

4. Database Relazionali
Caratteristiche:
• Modello ER
• Linguaggio SQL
• Prestazioni legate all’ENGINE
• Scalabilità/robustezza/prestazioni dipendono dalla
implementazione (modello, dati e engine)
4

5. Database Relazionali
• GENERALE :modello formale per rappresentare
“qualsiasi” cosa
• SCHEMA FISSO: dati ben conosciuti, formalizzati ,
ottimizzati per ridurre numero di scritture
• TRANSAZIONE CENTRICO
• OTTIMIZZAZIONE dello Spazio disco
• SCALABILITÀ LIMITATA (costosa) e soprattutto
verticale
5

6. Nuove esigenze
Email, Documenti,
Applicazioni, Utenti,
Musica, Video ….
Prodotti, Utenti,
Musica….
Le transazioni sono importanti solo in certe zone (basket,
pagamenti)
Moltissimi READ da parte degli utenti.
Enormi moli di dati con forma non prevedibile a priori
Un unico ER per Amazon sarebbe in continua riscrittura.
6

7. Nuove esigenze
Scalabilità orizzontale : partizionare dati su più macchine, più datacenter,
più continenti
Disponibilità 99.99% : aumentare fault tolerance in caso di guasti
7

8. Data partitioning
• In caso di grandi quantità di dati è necessario distribuirli su più servers
•
Partizionamento Orizzontale
(sharding)
• Partizionamento Verticale
8

9. Nuovi teoremi
CAP Theorem: (Eric Brewers) :
Un sistema distribuito è in grado di soddisfare al massimo due di queste garanzie allo
stesso tempo, ma non tutte e tre
TOLLERANZA DI
DISPONIBILITA’
COERENZA
PARTIZIONE
(la garanzia che ogni
(il sistema continua a
(tutti i nodi vedono gli
richiesta riceva una
funzionare
stessi dati nello stesso
risposta su ciò che sia
momento)
nonostante arbitrarie
riuscito o fallito)
perdite di messaggi)
9

10. Non si può avere tutto
10

11. Nuovi sistemi
99.99%
Scalabilità
Orizzontale
BASE
Basically Available Soft-state services with Eventual-consistency
Alta Disponibilità per i servizi di primo livello, con meccanismi di pulizia per
risolvere errori o problemi che hanno violato la consistenza.
11

12. NoSQL = Not Only SQL
Caratteristiche comuni
• Non Relazionali
• Schema non rigido
• Scalabile Orizzontalmente
• Per lo più OpenSource
In più
• Non rigido su alcuni dei cardini ACID
• Supporto alla replica
• API semplici
NON supportano tutte le funzioni SQL
• No Join
• No Ref Integrity
12

13. Tipi
Document oriented
• CouchDB
• MongoDB
• SOLR
Column oriented (Tabulari)
• Cassandra
• Hbase
Graph oriented
• InfiniteGraph
• Neo4J
Key-Value store
• Redis
• Riak
• Voldemort (linkedin)
• BigTable (Google)
13

14. Document Oriented
Document oriented
• Gestiscono strutture complesse semi – strutturate
• La struttura del documento non deve essere
conosciuta a priori, può cambiare al volo e
documenti diversi possono avere strutture diverse
• Usati per full text search engines.
14

15. Document Oriented - Esempio
Create
• List<String> likes = new ArrayList<String>();
• likes.add(“pop-corn”);
• likes.add(“kebab”);
• likes.add(“involtini primavera”);
• document.put(“name”,”Gianbattista”);
• doc.put(“age”,43);
• doc.put(“date”, new Date());
• doc.put(“likes”,likes);
• collection.insert(doc);
Read
• document doc=new document();
• doc.put(“name”,”Gianbattista”);
• cursor =collection.find(doc);
• While (cursor.hasNext())
• System.out.println(cursor.next());
• cursor.close()
Su una macchina è sub ottimo
Ma può scalare : MAPREDUCE
mongoDB
15

16. Column store
Column store
• Gestiscono dati strutturati
• Non registra i record come gli ER ma le colonne. Così da
poterle distribuire su più macchine, in base alla loro
importanza
• I gruppi di colonne sono definiti a priori ma in un gruppo
si possono avere schemi liberi
16

17. Key-value store
Key-value store
• Sono gli store più semplici, veloci in scrittura,
velocissimi in lettura ma solo sulla chiave
• Scalabilità facile
• Quelli base gestiscono solo il select from where
CAMPO = chiave
17

18. Key-value store - Esempio
Create
• String id= Long.toString(j.incr(“global:nextUserId”);
• j.set(“uid:”+id+”:name”,”Gianbattista”);
• j.set(“uid:”+id+”:age”,”43”);
• j.set(“uid:”+id+”:date”,new Date().toString());
• j.sadd(“uid:”+id+”:likes”,”pop-corn”);
• j.sadd(“uid:”+id+”:likes”,”kebabs”);
• j.sadd(“uid:”+id+”:likes”,”involtini primavera”);
• j.hset(“uid:lookup:name”,”Gianbattista”,id);
Read
• String id=j.hget(“uid:lookup:name”,”Gianbattista”);
• print(“name”, j.get(“uid:”+id+”:name”));
• print(“age”, j.get(“uid:”+id+”:age”));
• print(“name”, j.get(“uid:”+id+”:date”));
• print(“likes”, j.smembers(“uid:”+id+”:likes”));
SQL ?
• SELECT * from Table where ID=id : devo ciclare
REDIS
Su una macchina è sub ottimo
Ma può scalare : MAPREDUCE
18

19. Graph store
Graph store
• Nodi, relazioni tra i nodi e proprietà keyvalue
• Accesso ai dati mediante algoritmi di
navigazione grafi
19

20. Graph store - Esempio
Create
•Transaction tx =graphDB.beginTx();
•Try {
•firstNode = graphDb.createNode();
•firstNode.setProperty(“name”,”Gianbattista”);
•firstNode.setProperty(“age”,43);
•firstNode.setProperty(“date”, new Date().toString());
•secondNode= graphDb.createNode();
•secondNode.setProperty(“food”,”involtini primavera”,”pop corn”,”kebab”);
•relationship = firstNode.createRelationshipTo(secondNode, RelTypes.LIKES);
•Relationship.setProperty(“likes”,”likes”);
•tx.success();
•} finally {tx.finish();}
Read
•Transaction tx = graphDB.beginTx();
•Try {
•print(“name”, firstNode.getProperty(”name”));
•print(“age”, firstNode.getProperty(”age”));
•print(“date”, firstNode.getProperty(”date”))
•print(“likes”, secondNode.getProperty(”food”));
•tx.success():
•} finally { tx.finish();}
Neo4J
20

21. Quando scegliere un NoSQL?
NoSQL = Not only SQL
NoSQL è SQL frammentato e ottimizzato
Se voglio TUTTO -> SQL
Se voglio POCO ma MEGLIO -> NoSQL
Un sistema SQL standard (Oracle, SQL server, MySQL,
PostGres…) è un sistema complesso che fornisce tutte le
funzioni necessarie per la gestione dei dati:
transazioni, join, ricerca, scalabilità , tipizzazione, ….
Ogni piattaforma noSQL è considerabile come una parte di
un motore relazionale, spinta all’estremo, ma perdendo le
altre funzioni.
21

22. Path decisionale
Plain OLD SQL: Select * from table where ID=$ID
Project Voldemort
(noSQL)
• Key Value Store
Pro
• Velocità in lettura e scrittura
• Consistenza eventuale
• Replicazione automatica
22

23. Path decisionale
-> scrivo codice
Se devo ordinare i
risultati (ORDER BY)
Oppure -> Value
Ordered Data Store
-> scrivo codice
Se devo fare relazioni
tra i dati (JOIN)
Oppure -> Graph
based Store
-> scrivo codice
Se devo gestire
ricerche veloci ed
ordinate con ranking
Oppure -> Document
database
SI CREANO
SISTEMI
COMPOSITI
23

24. Andiamo sul pratico
24

25. Bleen struttura
Frontend
Backend
Engine
Plugins
Scheduler
Searcher
Tagger
Crawler
Storage
Solr
Crawl
Voldemort
Search
Launch
25

26. Bleen – componenti NoSQL
Project Voldemort:
•
•
•
•
•
Key Value data store. Motore originato da Dynamo di Linkedin.
Replicazione automatica su più server
Dati automaticamente partizionati
Consistenza Eventuale o Stretta
Server failure gestito in modo trasparente (disabilita e abilita nodi in
autonomia)
Apache SOLR:
• Document Data store (basato su lucene)
• Full text search , ricerca a facets, ranking, hit highlighting, near realtime, dynamic clustering, alta disponibilità, scalabile , fault tolerant,
indexing distribuito, replicazione load-balancing per le query.
• Usato da: WhiteHouse.gov, NetFix, Instagram, AOL, SourceForge,
eBay, DuckDuckGO…
MySQL : database SQL
26

27. Bleen crawling
Ogni motore usato in parti dell’algoritmo in base alle sue peculiarità
27

28. Bleen BIG DATA
Molti dati
Molto Difformi
Problematiche comuni
(ACL,Presentazione,Ricerca)
Molto variabili
=
BIG DATA
SOLR come Base
Stesso sistema per interagire
TUTTO È UN DOCUMENTO con TUTTE LE FONTI
Titolo, contenuto, ranking
Tag, metadata, tempo
28

29. DA RELAZIONALE A NoSQL
select concat('Cl',IDCLIENTE) as id ,
Concat( CRA1,' ', IDCLIENTE) as title,
Concat( CRA1,' <', IDCLIENTE,'>') as
metacli,
Ifnull(concat('Cliente: ', IDCLIENTE,'
’,RTRIM(ifnull(CRA1,' ')), ' Indirizzo:
', RTRIM(ifnull(CIND,'.')),' Telefono:
',ifnull(CTEL,' '), 'Email: ',
ifnull(CEMAIL,' ') ,'Nota: ',
ifnull(LTRIM(convert (NOTE using
UTF8 )),'')),'nulla') as content,
now() as ts,
'Clienti' as type ,
ifnull(CIND,' ') as indirizzo ,
ifnull(p.DESCRIPAESE,' ') as paese ,
ifnull(CTEL,' ') as telefono ,
ifnull(CPIV,' ') as partitaiva ,
ifnull(CEMAIL,' ') as email
from clienti C INNER JOIN paesi p
on C.PAESE=p.PAESE
where cra1 is not null
Come estraggo
da ER
id,id
title,title
metacli,metadata,Cliente
content,content
type,type
ts,lastModified
indirizzo,attribute,Indirizzo
paese,attribute,paese
telefono,attribute,telefono
partitaiva,attribute,partitaiva
email,attribute,email
paese,tag
Come scrivo in
SOLR
<h2>${entity.title}</h2>
<table style="">
<tr><td><b>Partita iva</b></td>
<td>$entity.getAttribute('partitaiva')}</t
d>
</tr>
<tr><td><b>Paese</b></td>
<td>${entity.getAttribute('paese')}</td>
</tr>
<tr><td><b>Indirizzo</b></td><td>${ent
ity.getAttribute('Indirizzo')}</td>
</tr>
<#assign x =
entity.getAttribute('email')?trim >
….
</table>
Come lo mostro
29

30. DA RELAZIONALE A NoSQL
Come si mostra un Cliente che è registrato su un relazionale
30

31. DA RELAZIONALE A NoSQL
Come si mostra un documento che è registrato sul file system
31

32. Nuovo approccio Filosofico(?)
Se tutto è riconducibile a un documento, tutto ha il significato di un testo scritto
da un essere umano.
• Semantica
• Clusterizzazione
• Catergorizzazione
I documenti scritti (informazioni destrutturate) si relazionano a quelli gestiti da
sistemi(informazioni strutturate) in modo naturale.
Sarebbe molto costoso senza lo “schema libero” tipico del NoSQL
32

33. Caso d’uso
Azienda di servizi di consulenza sul lavoro, sicurezza, medicina, ecologia, formazione e
privacy.
Azienda Knowledge intensive.
L'intero processo aziendale guidato dalla redazione di documenti e dall’assistenza
diretta al cliente tramite un help desk telefonico.
“Obiettivo primario ottenere statistiche sulla quantita di lavoro effettuato dal
personale per il cliente, cosi da poter gestire meglio il rapporto e verificare
l'avanzamento dei progetti”
Fonti dati:
• file system con tutti i documenti aziendali divisi per cliente
• mail con tutte le comunicazioni da e per il cliente
• i centralini telefonici, per tenere sotto controllo le telefonate da e per il cliente
• i fax, inserendo anche un modulo di OCR (interno a Bleen) per consentire la ricerca
testuale sul contenuto;
• il sistema gestionale interno
33

34. Caso d’uso
De strutturate
Conversione
(de)strutturate
Ricerca
Business Intelligence
Strutturate(ER)
Datawarehouse
34

35. Caso d’uso
35

36. Caso d’uso
36

37. Caso d’uso
Informazioni strutturate e destrutturate convivono
37

38. Chiamatemi
Possiamo lavorare su :
Motori di ricerca
Business Intelligence
Semantica
Clusterizzazione e sistemi esperti
Sviluppo di prodotti a tutto tondo
Gianbattista Schieppati
g.schieppati@myti.it
349.67.37.402
Brescia via Orzinuovi 20
(500 metri uscita Brescia Ovest)
www.myti.it www.bleen.it www.bim.it
38

39. Riferimenti
Manuel Scapolan slides
Stefano Maraspin slides
Akmal Chaudhri slides
J.Pokorny slides
Perry Hoekstra slides
Fabrizio Amarilli Fondazione Politecnico di Milano
www.myti.it www.bleen.it www.bim.it
39