Gianbattista Schieppati (MyTI Srl)

Politecnico di MilanoCorso di Sistemi informativi : 12 -11-2013

INTRODUZIONE A noSQL

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)

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)

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

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 prioriUn unico ER per Amazon sarebbe in continua riscrittura.

7

Nuove esigenze

Disponibilità 99.99% : aumentare fault tolerance in caso di guasti

Scalabilità orizzontale : partizionare dati su più macchine, più datacenter, più continenti

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

• Partizionamento Orizzontale (sharding)

• Partizionamento Verticale

8

9

Nuovi teoremiCAP Theorem: (Eric Brewers) :

Un sistema distribuito è in grado di soddisfare al massimo due di queste garanzie allo stesso tempo, ma non tutte e tre

COERENZA(tutti i nodi vedono gli stessi dati nello stesso

momento)

DISPONIBILITA’(la garanzia che ogni richiesta riceva una

risposta su ciò che sia riuscito o fallito)

TOLLERANZA DI PARTIZIONE

(il sistema continua a funzionare

nonostante arbitrarie perdite di messaggi)

10

Non si può avere tutto

11

Nuovi sistemi

BASEBasically Available Soft-state services with Eventual-consistency

Scalabilità Orizzontale

99.99%

Alta Disponibilità per i servizi di primo livello, con meccanismi di pulizia per risolvere errori o problemi che hanno violato la consistenza.

12

NoSQL = Not Only SQL

• Non Relazionali• Schema non rigido• Scalabile Orizzontalmente• Per lo più OpenSource

Caratteristiche comuni

• Non rigido su alcuni dei cardini ACID• Supporto alla replica• API semplici

In più

• No Join• No Ref Integrity

NON supportano tutte le funzioni SQL

13

Tipi• CouchDB• MongoDB• SOLR

Document oriented

• Cassandra• Hbase

Column oriented (Tabulari)

• InfiniteGraph• Neo4J

Graph oriented

• Redis• Riak• Voldemort (linkedin)• BigTable (Google)

Key-Value store

14

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.

Document oriented

15

Document Oriented - Esempio• 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);

Create

• document doc=new document();• doc.put(“name”,”Gianbattista”);• cursor =collection.find(doc);• While (cursor.hasNext())

• System.out.println(cursor.next());

• cursor.close()

Read

Su una macchina è sub ottimoMa può scalare : MAPREDUCE

mongoDB

16

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

Column store

17

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

Key-value store

18

Key-value store - Esempio• 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);

Create

• 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”));

Read

• SELECT * from Table where ID=id : devo ciclare

SQL ?

Su una macchina è sub ottimoMa può scalare : MAPREDUCEREDIS

19

Graph store

• Nodi, relazioni tra i nodi e proprietà key-value

• Accesso ai dati mediante algoritmi di navigazione grafi

Graph store

20

Graph store - Esempio•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();}

Create

•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();}

Read

Neo4J

21

Quando scegliere un 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.

NoSQL = Not only SQL

NoSQL è SQL frammentato e ottimizzato

Se voglio TUTTO -> SQLSe voglio POCO ma MEGLIO -> NoSQL

22

Path decisionale

Project Voldemort (noSQL)• Key Value Store

Pro• Velocità in lettura e scrittura• Consistenza eventuale• Replicazione automatica

Plain OLD SQL: Select * from table where ID=$ID

Path decisionale

SI CREANO SISTEMI COMPOSITI

23

Se devo ordinare i risultati (ORDER BY)

-> scrivo codice

Oppure -> Value Ordered Data Store

Se devo fare relazioni tra i dati (JOIN)

-> scrivo codice

Oppure -> Graph based Store

Se devo gestire ricerche veloci ed

ordinate con ranking

-> scrivo codice

Oppure -> Document database

24

Andiamo sul pratico

25

Bleen struttura

Storage

Engine

Solr Voldemort

Frontend Backend

Crawler

Scheduler

Searcher

Plugins

Tagger

Crawl Search Launch

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 real-

time, 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

27

Bleen crawlingOgni motore usato in parti dell’algoritmo in base alle sue peculiarità

28

Bleen BIG DATA

Molti datiMolto DifformiProblematiche comuni (ACL,Presentazione,Ricerca)Molto variabili

= BIG DATA

SOLR come BaseTUTTO È UN DOCUMENTOTitolo, contenuto, rankingTag, metadata, tempo

Stesso sistema per interagire con TUTTE LE FONTI

29

DA RELAZIONALE A NoSQLselect 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.PAESEwhere cra1 is not null

id,idtitle,titlemetacli,metadata,Clientecontent,contenttype,typets,lastModifiedindirizzo,attribute,Indirizzopaese,attribute,paesetelefono,attribute,telefonopartitaiva,attribute,partitaivaemail,attribute,emailpaese,tag

Come estraggo da ER

Come scrivo in SOLR

Come lo mostro

<h2>${entity.title}</h2><table style=""><tr><td><b>Partita iva</b></td> <td>$entity.getAttribute('partitaiva')}</td></tr> <tr><td><b>Paese</b></td><td>${entity.getAttribute('paese')}</td></tr><tr><td><b>Indirizzo</b></td><td>${entity.getAttribute('Indirizzo')}</td></tr><#assign x = entity.getAttribute('email')?trim >

….</table>

30

DA RELAZIONALE A NoSQL

Come si mostra un Cliente che è registrato su un relazionale

31

DA RELAZIONALE A NoSQL

Come si mostra un documento che è registrato sul file system

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

33

Caso d’usoAzienda 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

34

Caso d’uso

Strutturate(ER)

De strutturate

Datawarehouse

Conversione (de)strutturate

Business Intelligence

Ricerca

35

Caso d’uso

36

Caso d’uso

37

Caso d’uso

Informazioni strutturate e destrutturate convivono

38

Chiamatemi

Possiamo lavorare su :Motori di ricerca Business IntelligenceSemanticaClusterizzazione e sistemi espertiSviluppo di prodotti a tutto tondo

Gianbattista Schieppatig.schieppati@myti.it349.67.37.402

Brescia via Orzinuovi 20 (500 metri uscita Brescia Ovest)

www.myti.it www.bleen.it www.bim.it

39www.myti.it www.bleen.it www.bim.it

Riferimenti

Manuel Scapolan slides Stefano Maraspin slidesAkmal Chaudhri slides J.Pokorny slides Perry Hoekstra slidesFabrizio Amarilli Fondazione Politecnico di Milano