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