NoSQL. Definizione. Nella seconda metà degli anni 2000 Google, Amazon, Facebook studiavano nuove modalità di memorizzazione persistente dei dati

Transcript

1 NoSQL TESTO CONSIGLIATO Definizione 2 Nella seconda metà degli anni 2000 Google, Amazon, Facebook studiavano nuove modalità di memorizzazione persistente dei dati Google è BigTable Amazon è DynamoDB Facebook è Cassandra Il movimento nasce nel 2009 Nome scelto per attirare partecipanti a un incontro fra sviluppatori di DBMS open-source, distribuiti, non relazionali

2 3 Principali vantaggi modello relazionale DBMS relazionali (SQL) ottimi per Persistenza dei dati I DBMS consentono di organizzare la memorizzazione di grandi quantità di dati utili L estrazione di dati tramite query SQL è semplice Integrazione di applicazioni diverse L accesso ai dati è facilitato dalla separazione fra organizzazione fisica e organizzazione logica Gestione della concorrenza (transazioni) Portabilità e manutenibilità grazie allo standard SQL Criticità del modello relazionale per lo sviluppo di applicazioni web nel 21 secolo 4 Disadattamento di impedenza Il modello relazionale elabora insiemi di tuple Ciascuna tupla è un insieme di attributi semplici Una struttura dati complessa da luogo a numerose relazioni

3 5 Esempio di disadattamento di impedenza Interfaccia utente per un modulo d ordine e corrispondenti tabelle nel modello relazionale Criticità del modello relazionale per lo sviluppo di applicazioni web nel 21 secolo 6 Basi di Dati orientate all integrazione Uno degli scopi primari del modello relazionale La Base di Dati centralizzata ottimizza mediamente l accesso da parte di applicazioni diverse Basi di Dati orientate all applicazione L archivio dei dati ottimizzato rispetto all unica applicazione che vi deve accedere Applicazioni diverse possono cooperare scambiando dati usando il formato XML e il protocollo HTTP XML consente la definizione di strutture dati complesse Coerenza dei dati a carico delle applicazioni

4 Criticità del modello relazionale per lo sviluppo di applicazioni web nel 21 secolo 7 Rapida crescita a fine anni 90 delle imprese i cui profitti derivano dal web (dot-com) Espansione supporto HW attraverso cluster di computer a basso costo Alta scalabilità a costi contenuti L uso di basi di dati relazionali richiede un sistema di memorizzazione centralizzato acquisto di licenze per ogni processore/nodo I DBMS relazionali non sono stati sviluppati per essere eseguiti su sistemi cluster NoSQL 8 Non indica un modello, né un prodotto, né una famiglia di prodotti. E un movimento che promuove sistemi di memorizzazione persistente alternativi al modello relazionale Ciascun sistema NoSQL è orientato a un particolare dominio applicativo Lista di progetti NoSQL su

5 Caratteristiche comuni sistemi NoSQL 9 Nati nel 21 secolo per le imprese del web non comprendono i modelli pre-sql era BC Before Codd Open-source Adatti a essere eseguiti da un cluster Assenza di uno schema Consente l uso di record con numero di attributi variabile Non supportano interrogazione con linguaggio SQL Operazioni sulla base di dati eseguite tramite API DBMS relazionali e DB NoSQL 10 Non devono essere considerati come antagonisti MA come soluzioni complementari, ciascuna adatta a un particolare ambiente operativo In una azienda moderna coesistono basi di dati relazionali e basi di dati NoSQL si può parlare di Sadalage & Fowler

6 11 Modelli di Dati Aggregati Modelli dei dati 12 I modelli dei dati descrivono il modo con cui i dati sono manipolati dagli utilizzatori I modelli di memorizzazione dei dati descrivono il modo con cui i dati sono registrati in modo persistente Nel mondo ideale dovrebbe essere sufficiente lavorare solo a livello dei modelli logici ma l ottimizzazione delle prestazioni richiede la conoscenza del modello di memorizzazione

7 Modelli dei dati aggregati 13 Gli approcci NoSQL possono essere suddivisi in quattro modelli di dati key-value document store column-family graph Caratteristica comune: sono orientati all aggregazione Orientamento all aggregazione 14 Nel modello relazionale le entità sono rappresentate come tuple di valori Non è possibile avere una tupla o una lista di valori annidata in un altra tupla Il modello relazionale è idoneo a rappresentare entità con struttura semplice Un indica una collezione di oggetti in relazione fra loro, da considerare come una unità Rappresenta dati con struttura complessa

8 Esempio Modello relazionale (UML) per un sito di e-commerce 15 Esempio Un possibile stato del RDBMS per un sito di e-commerce 16

9 Esempio Modello orientato all aggregazione per un sito di e-commerce 17 Esempio Definizione in JSON di aggregati del sito di e-commerce 18 Il valore è in tutti gli aggregati

10 Esempio Altro modello orientato agli aggregati per un sito di e-commerce 19 Tutti gli ordini di un cliente sono all interno dell aggregato Cliente Esempio Definizione in JSON di aggregati del sito di e-commerce 20

11 Progettazione per aggregati 21 Diverse possibilità di definire aggregati. La scelta dipende principalmente dall aggregazione di dati coinvolta nelle operazioni più frequenti Ad es., potrei voler spesso accedere ai dati dei clienti e a tutti gli ordini che hanno fatto oppure potrei voler spesso accedere ai soli ordini singolarmente Se la base di dati risiede in un cluster, si memorizzano sui singoli nodi i dati già aggregati minimizzazione tempi di accesso ai dati aggregati Accesso ai dati 22 Oggetti inseriti in un unico aggregato Aggregati separati per Clienti e Ordini

12 Modello relazionale e aggregati 23 Il modello relazionale non prevede il costrutto aggregazione E espresso attraverso il vincolo di integrità referenziale Vantaggio del modello relazionale aggregate-ignorant E un modello generale dei dati, non legato alle operazioni più frequenti sulla base di dati Consente di esprimere in modo semplice una ampia varietà di operazioni di manipolazione dei dati Un modello con aggregati è specializzato per alcune manipolazioni dei dati frequenti Aggregati e proprietà ACID 24 I modelli NoSQL non sempre garantiscono le proprietà ACID Atomicità a livello di singolo aggregato In molti modelli NoSQL è compito del programmatore garantire l atomicità su operazioni che coinvolgono più aggregati La gestione della coerenza è più complessa rispetto al modello relazionale

13 25 I modelli e In questi modelli ciascun aggregato possiede un identificatore key-value nessuna struttura nei dati la base di dati tratta ciascun aggregato come un blob di bit senza significato (opacità della base di dati) possibile recuperare solo interi aggregati in base all id document è presente una struttura che impone dei vincoli flessibilità nella manipolazione dei dati interrogazioni anche in base ai campi della struttura 26 Il modello Primo esempio: BigTable realizzato da Google Memorizzazione per colonne anziché per righe Colonne aggregate attraverso una mappa a due livelli

14 27 Il modello basato su I nodi contengono informazioni semplici Un nome o elementi di tipo chiave-valore Gli archi rappresentano le relazioni fra i nodi Utili per interrogazioni del tipo: mostra gli oggetti che piacciono a Barbara e Anna Facebook usa un modello a grafi: Bronson et al., TAO: Facebook s Distributed Data Store for the Social Graph (USENIX 2013) Basi di dati senza schema 28 Una delle caratteristiche comuni ai modelli NoSQL è l assenza di uno schema In principio ogni informazione memorizzata potrebbe essere descritta da attributi diversi Lo schema nei modelli NoSQL è implicito nel codice dell applicazione usato per accedere ai dati La memorizzazione di dati con modelli NoSQL non è adatta per l accesso ai dati da applicazioni diverse

15 29 KEY-VALUE DATABASES Definizione 30 Le basi di dati di tipo key-value sono le più semplici da usare dal punto di vista delle API Un contenitore del tipo chiave-valore è una tabella hash. Confronto fra la terminologia Oracle e Riak

16 key-value store 31 La chiave consente di individuare l entità, mentre il valore è un blob di dati. blob = binary large object Alcuni DB di tipo key-value Riak Redis Memcached DB HamsterDB Amazon DynamoDB Project Voldemort Modelli di memorizzazione dei dati Un unico bucket che contiene una sola coppia chiave-valore che rappresenta l utente e il suo acquisto Un unico bucket in cui è possibile specificare chiavi distinte per recuperare i singoli oggetti nel bucket 32 Scalabilità attraverso sharding sul valore della chiave

17 Interrogazioni nel modello key-value 33 Le interrogazioni possono coinvolgere solo la chiave Si recupera il blob associato e eventuali altre condizioni sui valori nel blob devono essere verificate a livello applicativo Spesso la chiave è creata automaticamente ad es., numero progressivo di un ordine ma può anche essere una , un nome utente Quando usare il modello key-value 34 Memorizzazione di informazioni di sessione per applicazioni web Gestione profili utente e relative preferenze Rappresentazione del carrello della spesa in applicazioni di commercio elettronico

18 Quando non usare il modello key-value 35 Gestione di dati in relazione fra loro Transazioni con operazioni multiple Interrogazioni sui dati ( valore associato alla chiave) Necessità di operare su insiemi di dati 36 DOCUMENT DATABASES

19 Modello dei dati 37 Questo è il modello più simile alle basi di dati relazionali memorizza documenti XML, JSON, ecc. Confronto fra la terminologia Oracle e MongoDB Caratteristiche del modello document 38 Ciascun documento ha uno schema sono possibili interrogazioni su campi del documento Documenti diversi di una stessa base di dati possono avere schemi diversi che condividono solo alcuni attributi Alcuni DB di tipo document MongoDB CouchDB Terrastore OrientDB RavenDB

20 Esempi di documenti di una base di dati 39 Documento 1 Documento 2 MongoDB: Rappresentazione della relazione WORKS_ON 40

21 MongoDB: Rappresentazione della relazione WORKS_ON Interrogazioni Esempi con MongoDB SELECT * FROM order diventa db.order.find() SELECT * FROM order WHERE customerid = "883c2c5b4e5b diventa db.order.find({"customerid":"883c2c5b4e5b"}) SELECT * FROM customerorder, orderitem, product WHERE customerorder.orderid = orderitem.customerorderid AND orderitem.productid = product.productid AND product.name LIKE '%Refactoring% diventa db.orders.find({"items.product.name":/refactoring/})

22 Quando usare il modello document 43 Registrazione di eventi (event logging) Consente di registrare eventi diversi, ciascuno con il proprio insieme di attributi Content Management Systems (CMS) Piattaforme per blog Web Analytics Applicazioni commercio elettronico Quando non usare il modello document 44 Necessità di effettuare transazioni complesse che coinvolgono numerose operazioni Interrogazioni che coinvolgono aggregati la cui struttura è variabile

23 45 COLUMN-FAMILY STORES Proprietà 46 I dati sono rappresentati attraverso una chiave associata a un insieme di valori, e i valori appartengono a una famiglia di colonne

24 Basi di dati di tipo column-family 47 Appartengono a questa tipologia Cassandra Hbase Hypertable Amazon DynamoDB Esempio di column family 48

25 Linguaggio DDL e DML in Cassandra 49 Cassandra ha un suo linguaggio (CQL) simile a SQL CREATE COLUMNFAMILY Customer ( KEY varchar PRIMARY KEY, name varchar, city varchar, web varchar); INSERT INTO Customer (KEY,name,city,web) VALUES ('mfowler,'martin Fowler,'Boston,' Interrogazioni in Cassandra 50 SELECT * FROM Customer SELECT name,web FROM Customer SELECT name,web FROM Customer WHERE city='boston Nonostante la somiglianza con SQL, CQL non supporta tutte le interrogazioni SQL Non è possibile usare interrogazioni annidate Non è possibile l operazione di join Di solito la clausola WHERE è semplice

26 Quando usare il modello column-family 51 Registrazione di eventi (event logging) Content Management Systems (CMS) Piattaforme per blog Contatori Ad es., visitatori di una pagina web Gestione scadenze Ad es., licenze software in prova per un periodo di tempo limitato Quando non usare il modello columnfamily 52 Necessità di transazioni con proprietà ACID Interrogazioni con funzioni di aggregazione (ad es., SUM, AVG)

27 53 POLYGLOT PERSISTENCE A ciascun dato, il suo modello 54 Approccio tipico: unico modello di dati per le diverse attività. Polyglot persistence: modelli di dati diversi per ciascuna attività.

28 Evoluzione: dalle basi di dati ai servizi 55 Per semplificare la scrittura di applicazioni che si devono interfacciare a diverse basi di dati si incapsula ciascuna base di dati in un servizio Le applicazioni comunicano con le API del servizio NoSQL e RDBMS 56 Il movimento NoSQL non minaccia l uso dei RDBMS Il modello relazionale è ancora valido per le applicazioni per le quali è stato sviluppato Soluzioni NoSQL sono da preferire a RDBMS per nuove esigenze di memorizzazione e gestione dei dati ricollegabili allo Sviluppo del web e delle sue applicazioni Reti sociali virtuali Evoluzione piattaforme di calcolo