INTRODUZIONE A noSQL
Gianbattista Schieppati (MyTI Srl)
Politecnico di Milano
Corso di Sistemi informativi : 12 -11-2013
Mi presento:
Ing. Gianbattista Schieppati
18 anni di esperienze:

Business Intelligence (sviluppato e gestito
Infobusines...
Database Relazionali
Modello
Concettuale

Modello
Logico

Modello
Fisico

ATOMICITÀ: la transazione è indivisibile nella s...
Database Relazionali
Caratteristiche:
• Modello ER
• Linguaggio SQL
• Prestazioni legate all’ENGINE
• Scalabilità/robustez...
Database Relazionali
• GENERALE :modello formale per rappresentare
“qualsiasi” cosa
• SCHEMA FISSO: dati ben conosciuti, f...
Nuove esigenze

Email, Documenti,
Applicazioni, Utenti,
Musica, Video ….

Prodotti, Utenti,
Musica….

Le transazioni sono ...
Nuove esigenze
Scalabilità orizzontale : partizionare dati su più macchine, più datacenter,
più continenti

Disponibilità ...
Data partitioning
• In caso di grandi quantità di dati è necessario distribuirli su più servers
•

Partizionamento Orizzon...
Nuovi teoremi
CAP Theorem: (Eric Brewers) :

Un sistema distribuito è in grado di soddisfare al massimo due di queste gara...
Non si può avere tutto

10
Nuovi sistemi

99.99%

Scalabilità
Orizzontale

BASE
Basically Available Soft-state services with Eventual-consistency
Alt...
NoSQL = Not Only SQL
Caratteristiche comuni
• Non Relazionali
• Schema non rigido
• Scalabile Orizzontalmente
• Per lo più...
Tipi
Document oriented
• CouchDB
• MongoDB
• SOLR
Column oriented (Tabulari)
• Cassandra
• Hbase
Graph oriented
• Infinite...
Document Oriented
Document oriented
• Gestiscono strutture complesse semi – strutturate
• La struttura del documento non d...
Document Oriented - Esempio
Create
• List<String> likes = new ArrayList<String>();
• likes.add(“pop-corn”);
• likes.add(“k...
Column store
Column store
• Gestiscono dati strutturati
• Non registra i record come gli ER ma le colonne. Così da
poterle...
Key-value store
Key-value store
• Sono gli store più semplici, veloci in scrittura,
velocissimi in lettura ma solo sulla c...
Key-value store - Esempio
Create
• String id= Long.toString(j.incr(“global:nextUserId”);
• j.set(“uid:”+id+”:name”,”Gianba...
Graph store
Graph store
• Nodi, relazioni tra i nodi e proprietà keyvalue
• Accesso ai dati mediante algoritmi di
navigazi...
Graph store - Esempio
Create
•Transaction tx =graphDB.beginTx();

•Try {
•firstNode = graphDb.createNode();
•firstNode.set...
Quando scegliere un NoSQL?
NoSQL = Not only SQL
NoSQL è SQL frammentato e ottimizzato

Se voglio TUTTO -> SQL
Se voglio PO...
Path decisionale
Plain OLD SQL: Select * from table where ID=$ID

Project Voldemort
(noSQL)
• Key Value Store

Pro
• Veloc...
Path decisionale
-> scrivo codice
Se devo ordinare i
risultati (ORDER BY)
Oppure -> Value
Ordered Data Store

-> scrivo co...
Andiamo sul pratico

24
Bleen struttura
Frontend

Backend

Engine
Plugins

Scheduler

Searcher

Tagger
Crawler

Storage
Solr

Crawl

Voldemort

Se...
Bleen – componenti NoSQL
Project Voldemort:
•
•
•
•
•

Key Value data store. Motore originato da Dynamo di Linkedin.
Repli...
Bleen crawling
Ogni motore usato in parti dell’algoritmo in base alle sue peculiarità

27
Bleen BIG DATA

Molti dati
Molto Difformi
Problematiche comuni
(ACL,Presentazione,Ricerca)
Molto variabili
=
BIG DATA

SOL...
DA RELAZIONALE A NoSQL
select concat('Cl',IDCLIENTE) as id ,
Concat( CRA1,' ', IDCLIENTE) as title,
Concat( CRA1,' <', IDC...
DA RELAZIONALE A NoSQL

Come si mostra un Cliente che è registrato su un relazionale

30
DA RELAZIONALE A NoSQL

Come si mostra un documento che è registrato sul file system

31
Nuovo approccio Filosofico(?)
Se tutto è riconducibile a un documento, tutto ha il significato di un testo scritto
da un e...
Caso d’uso
Azienda di servizi di consulenza sul lavoro, sicurezza, medicina, ecologia, formazione e
privacy.
Azienda Knowl...
Caso d’uso

De strutturate

Conversione
(de)strutturate

Ricerca

Business Intelligence
Strutturate(ER)

Datawarehouse

34
Caso d’uso

35
Caso d’uso

36
Caso d’uso

Informazioni strutturate e destrutturate convivono

37
Chiamatemi

Possiamo lavorare su :
Motori di ricerca
Business Intelligence
Semantica
Clusterizzazione e sistemi esperti
Sv...
Riferimenti

Manuel Scapolan slides
Stefano Maraspin slides
Akmal Chaudhri slides
J.Pokorny slides
Perry Hoekstra slides
F...
Upcoming SlideShare
Loading in...5
×

No sql introduzione. Corso Sistemi Informativi Politecnico di Milano 12-11-2013

473

Published on

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

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
473
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
18
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

No sql introduzione. Corso Sistemi Informativi Politecnico di Milano 12-11-2013

  1. 1. INTRODUZIONE A noSQL Gianbattista Schieppati (MyTI Srl) Politecnico di Milano Corso di Sistemi informativi : 12 -11-2013
  2. 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. 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. 4. Database Relazionali Caratteristiche: • Modello ER • Linguaggio SQL • Prestazioni legate all’ENGINE • Scalabilità/robustezza/prestazioni dipendono dalla implementazione (modello, dati e engine) 4
  5. 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. 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. 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. 8. Data partitioning • In caso di grandi quantità di dati è necessario distribuirli su più servers • Partizionamento Orizzontale (sharding) • Partizionamento Verticale 8
  9. 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. 10. Non si può avere tutto 10
  11. 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. 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. 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. 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. 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. 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. 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. 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. 19. Graph store Graph store • Nodi, relazioni tra i nodi e proprietà keyvalue • Accesso ai dati mediante algoritmi di navigazione grafi 19
  20. 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. 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. 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. 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. 24. Andiamo sul pratico 24
  25. 25. Bleen struttura Frontend Backend Engine Plugins Scheduler Searcher Tagger Crawler Storage Solr Crawl Voldemort Search Launch 25
  26. 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. 27. Bleen crawling Ogni motore usato in parti dell’algoritmo in base alle sue peculiarità 27
  28. 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. 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. 30. DA RELAZIONALE A NoSQL Come si mostra un Cliente che è registrato su un relazionale 30
  31. 31. DA RELAZIONALE A NoSQL Come si mostra un documento che è registrato sul file system 31
  32. 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. 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. 34. Caso d’uso De strutturate Conversione (de)strutturate Ricerca Business Intelligence Strutturate(ER) Datawarehouse 34
  35. 35. Caso d’uso 35
  36. 36. Caso d’uso 36
  37. 37. Caso d’uso Informazioni strutturate e destrutturate convivono 37
  38. 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. 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
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×