SQL, NoSQL, o entrambi?

SQL, NoSQL, o entrambi?
SQL, NoSQL, o entrambi?
Introduzione
Nella prima parte di questo corso abbiamo fatto una prima introduzione sul quando e
come scegliere un database per risolvere un determinato problema.
In questa parte finale vedremo attraverso un esempio pratico come affrontare tale
scelta fornendo una serie di consigli che non vanno presi come “assoluti”, ma che
vanno adattati sempre per il problema che si vuole affrontare.
Si ricordi che i diversi database sono stati progettati e sviluppati per risolvere diverse
tipologie di problemi. Generalmente quest'ultimi sono complessi e non esiste una sola
soluzione che risolve l'intero problema, ma diverse soluzioni per le diverse parti del
problema.
SQL, NoSQL, o entrambi?
Introduzione
La soluzione migliore, in fase di progettazione e realizzazione di una piattaforma
complessa, è quella che sfrutta il concetto della Polyglot Persistence: con questo
termine si esprime l'idea di realizzare l'applicazione sfruttando un mix delle diverse
tecnologie disponibili per la gestione delle singole attività scegliendo per ciascuna di
esse la più adatta.
Vedremo come con più adatta intendiamo sia l'essere adatta ai dati, all'esperienza
legata alla fruizione dei dati ed al modello di business che si vuole portare avanti.
SQL, NoSQL, o entrambi?
Analisi del progetto
In particolare, per ogni progetto, dovremmo analizzare:
●
Scalabilità
●
Atomicità e transazioni
●
Consistecy VS Availability
Alcuni di questi aspetti saranno fortemente influenzati dalla logica di business e dalla
user experience che si vuole offrire.
SQL, NoSQL, o entrambi?
Analisi del progetto: scalabilità
Il primo aspetto che dobbiamo analizzare per affrontare la progettazione del sistema e
dei suoi componenti e capire la scalabilità del sistema oggetto della nostra
progettazione.
Il progetto punta ad una scalabilità verticale od orizzontale?
Se il progetto (dal punto di vista dei dati e della loro aggregazione) girerà su un solo
server/mainframe allora non ha senso parlare di Polyglot Persistence in quanto, come
ovvio, vengono meno tutte le problematiche che hanno portato alla diffusione dei
sistemi NoSQL. In questo caso va benissimo utilizzare un sistema basato su RDBMS
per la realizzazione del nostro progetto.
SQL, NoSQL, o entrambi?
Analisi del progetto: scalabilità
Se invece la scalabilità è orizzontale allora il sistema va progettato in modo che possa
eventualmente utilizzare più database per la realizzazione dei servizi di cui si andrà a
comporre.
In questo caso, per alcuni dei componenti si punterà ad utilizzare sicuramente
database NoSQL in quanto abbiamo visto che i database RDBMS supportano bene la
scalabilità verticale, ma non quella orizzontale.
SQL, NoSQL, o entrambi?
Analisi del progetto: atomicità e transazioni
Il secondo aspetto che va analizzato è l'importanza dell'atomicità e dell'utilizzo delle
transazioni per l'intero progetto che si vuole realizzare o per alcuni dei dati (anche in
forma aggregata).
Per quel che riguarda l'atomicità l'aspetto su cui focalizzarsi è capire se questa
proprietà serve sull'inserimento di un singolo dato oppure su una serie di dati.
Nel primo caso abbiamo che molti sistemi NoSQL, ma non tutti, la garantiscono per il
loro dato aggregato (es. un document): infatti, quando abbiamo illustrato il CQL di
Cassandra abbiamo visto che la singola operazione di INSERT di una riga è atomica ed
isolata.
Se invece ci interessa l'atomicità sull'inserimento di più dati, ovvero ci interessa una
transazione, il database che va bene per questo utilizzo è RDBMS.
SQL, NoSQL, o entrambi?
Analisi del progetto: Consistecy VS Availability
Il terzo aspetto che va analizzato è il bilanciamento che vogliamo ottenere fra
Consistecy ed Availability. Anche queste proprietà vanno analizzate in relazione ai
singoli aspetti del progetto.
Come già visto la scelta fra consistency ed availability viene fatta solo se suddividiamo i
dati in partizioni distribuite (anche geograficamente). In caso contrario abbiamo sia
consistency che availability.
La scelta non è binaria, ma è SEMPRE un bilanciamento fra le due.
SQL, NoSQL, o entrambi?
Un caso d'Uso
Il caso d'uso che vogliamo progettare è quello della seguente piattaforma di E-Commerce
E-Commerce Platform
Shopping
cart data
Completed
orders
Customer
social graph
BI / DW
?
Log
Session
data
Report
Inventory &
item price
SQL, NoSQL, o entrambi?
Caso d'uso: User Experience
Per la progettazione della piattaforma dobbiamo analizzare gli aspetti illustrati in
precedenza tenendo conto sia della user-experience che si vuole offrire attraverso il
progetto e la logica di business che si vuole realizzare.
SQL, NoSQL, o entrambi?
Caso d'uso: Analisi delle esigenze
Acquirente
Venditore
Login
Analisi Report
Inserimento e update
prodotto
Ricerca
Nome del prodotto
BI e DW
Descrizione del prodotto
Sistema
Prodotto
Inserimento nel carrello del prodotto
Tracking delle
operazioni e log
Completamento acquisto del prodotto
Transazione bancaria
Analisi Batch
Salvataggio
report
Suggerimenti
acquirente
basato su reti
sociali
SQL, NoSQL, o entrambi?
Caso d'uso: Analisi delle esigenze
Acquirente
Venditore
Login
Analisi Report
Inserimento e update
prodotto
Ricerca
Nome del prodotto
BI e DW
Descrizione del prodotto
Sistema
Prodotto
Inserimento nel carrello del prodotto
Tracking delle
operazioni e log
Completamento acquisto del prodotto
Transazione bancaria
Analisi Batch
Salvataggio
report
Suggerimenti
acquirente
basato su reti
sociali
SQL, NoSQL, o entrambi?
Caso d'uso: Prodotto
Per ogni prodotto vogliamo che questo abbia:
(a) Nome del prodotto
(b) Descrizione libera (con campi variabili)
(c) Metatag per la descrizione rapida del prodotto
(d) Dati del venditore
(e) Prezzo
(f) Disponibilità (numero di pezzi)
SQL, NoSQL, o entrambi?
Caso d'uso: Prodotto
Per ogni prodotto vogliamo che questo abbia:
(a) Nome del prodotto
(b) Descrizione libera (con campi variabili)
(c) Metatag per la descrizione rapida del prodotto
(d) Dati del venditore
(e) Prezzo
(f) Disponibilità (numero di pezzi)
(a), (b) e (c) sono dati che verranno modificati raramente e dovranno essere sempre
disponibili per la visualizzazione anche se non ancora aggiornati con l'ultima modifica (per
logica di business si punta ad avere una vetrina con più prodotti possibili anche se
mancano ad esempio prezzo e disponibilità).
Quindi si ha eventual consistency, alta availability e ci interessa l'atomicità sull'inserimento
di queste informazioni. Soluzione ideale: Key-Value store o Document store.
SQL, NoSQL, o entrambi?
Caso d'uso: Prodotto
Per ogni prodotto vogliamo che questo abbia:
(a) Nome del prodotto
(b) Descrizione libera (con campi variabili)
(c) Metatag per la descrizione rapida del prodotto
(d) Dati del venditore
(e) Prezzo
(f) Disponibilità (numero di pezzi)
(d) sono dati che verranno modificati raramente e dovranno essere sempre disponibili per
la visualizzazione. Alcuni di questi sono “sensibili” come l'IBAN per i pagamenti ed è
importante che siano aggiornati con l'ultima modifica effettuata e se non aggiornati
potenzialmente è meglio non visualizzarli.
Quindi si ha consistency, e ci interessa l'atomicità sull'inserimento di queste informazioni.
Soluzione ideale: RDBMS o database NoSQL con consistency.
SQL, NoSQL, o entrambi?
Caso d'uso: Prodotto
Per ogni prodotto vogliamo che questo abbia:
(a) Nome del prodotto
(b) Descrizione libera (con campi variabili)
(c) Metatag per la descrizione rapida del prodotto
(d) Dati del venditore
(e) Prezzo
(f) Disponibilità (numero di pezzi)
(e) e (f) sono dati che verranno modificati dinamicamente si dovrà visualizzare sempre il
più recente.
Soluzione ideale: RDBMS.
Nota: potrebbe accadere che per logica di business la certezza dell'informazione
(soprattutto per la disponibilità) venga spostata nella fase di gestione del carrello in modo
da fornire agli utenti la pagina prodotto “completa”.
SQL, NoSQL, o entrambi?
Caso d'uso: Acquirente
Per ogni acquirente vogliamo gestire:
(a) Dati utente
(b) Dati di login
(c) Acquisti
(d) Storico ricerche
(e) Storico acquisti
(f) Collegamenti con altri utenti
SQL, NoSQL, o entrambi?
Caso d'uso: Acquirente
Per ogni acquirente vogliamo gestire:
(a) Dati utente
(b) Dati di login
(c) Acquisti
(d) Storico ricerche
(e) Storico acquisti
(f) Collegamenti con altri utenti
(a) vengono modificati raramente (es. carta di credito predefinita, indirizzo di spedizione
predefinito). Per quanto si tratti di dati spesso “sensibili” si noti che la loro modifica non è
contemporanea al loro utilizzo.
Soluzione ideale: RDBMS o database NoSQL con consistency.
SQL, NoSQL, o entrambi?
Caso d'uso: Acquirente
Per ogni acquirente vogliamo gestire:
(a) Dati utente
(b) Dati di login
(c) Acquisti
(d) Storico ricerche
(e) Storico acquisti
(f) Collegamenti con altri utenti
(b) vengono inseriti una volta ed eventualmente a volte viene modificata la password. Lo
scopo è garantire l'accesso alla piattaforma il più velocemente possibile.
Soluzione ideale: Key-value Store
SQL, NoSQL, o entrambi?
Caso d'uso: Acquirente
Per ogni acquirente vogliamo gestire:
(a) Dati utente
(b) Dati di login
(c) Acquisti
(d) Storico ricerche
(e) Storico acquisti
(f) Collegamenti con altri utenti
(c) la procedura di acquisto dal carrello deve essere garantita ed atomica (devo garantire
prezzo prodotto, sua presenza in magazzino, buon fine della procedura bancaria). Ho
quindi una transazione.
Soluzione ideale: RDBMS.
SQL, NoSQL, o entrambi?
Caso d'uso: Acquirente
Per ogni acquirente vogliamo gestire:
(a) Dati utente
(b) Dati di login
(c) Acquisti
(d) Storico ricerche
(e) Storico acquisti
(f) Collegamenti con altri utenti
(d) e (e) gli storici vanno memorizzati sia per essere utilizzati come storico nella pagina utente,
sia come fonti di dati per Business Intelligence e Data Warehouse. In questo caso è molto
importante l'availability e che il dato singolo sia inserito correttamente in maniera atomica.
Questi dati saranno la sorgente per altri tool per BI e/o DW(es. possono essere processati
usando HIVE).
Soluzione ideale: Column store.
SQL, NoSQL, o entrambi?
Caso d'uso: Acquirente
Per ogni acquirente vogliamo gestire:
(a) Dati utente
(b) Dati di login
(c) Acquisti
(d) Storico ricerche
(e) Storico acquisti
(f) Collegamenti con altri utenti
(f) se vogliamo monitorare i collegamenti sociali fra gli utenti ovvero con categorie di essi
abbiamo necessità di memorizzare le relazioni in modo dinamico.
Soluzione ideale: Graph Database.
Nota: nonostante gli RDBMS siano dei sistemi relazionali non gestiscono le relazioni
come i graph DB e quindi sono poco adatti alla generazione di relazioni complesse e
variabili.
SQL, NoSQL, o entrambi?
Un caso d'Uso: Possibile Soluzione
E-Commerce Platform
Shopping
cart data
Session
data
Customer
social graph
Key-Value
Store
(Es. Voldemort)
BI / DW
Log
DW
Store / HDFS
(Es. HIVE)
Graph
Store
(Es. Neo4j)
Completed
orders
Report
Inventory &
item price
Document
Store
(Es. MongoDB)
Column Family
Store
(Es. HBASE)
RDBMS
(Es. OracleDB)