NOSQL Origini e Significato. NOSQL = NO a SQL. NOSQL = Not Only SQL

Dimensione: px
Iniziare la visualizzazioe della pagina:

Download "NOSQL Origini e Significato. NOSQL = NO a SQL. NOSQL = Not Only SQL"

Transcript

1 NOSQL

2 NOSQL Origini e Significato NOSQL = NO a SQL NOSQL = Not Only SQL Il termine NOSQL fu introdotto da Carlo Strozzi nel 1998 per indicare il suo database relazionale open-source che non aveva una interfaccia SQL standard. Il termine attualmente indica tutti quei database che sono: non relazionali, distribuiti, open-source (spesso) e scalabili orizzontalmente.

3 NOSQL Introduzione un po' di storia Anni '70 Nascono i database relazionali - I supporti di memorizzazione sono altamente costosi - I dati vengono normalizzati per il loro inserimento nel database - L'organizzazione dei dati dipende da loro stessi e non dall'uso che sarà fatto Anni '80 Vengono introdotti i sistemi RDBMS - Si introduce il modello Client/Server - Il linguaggio SQL diventa lo standard per l'interrogazione dei database Anni '90 Nascita del World Wide Web e inizio della diffusione massiva di Internet

4 NOSQL Introduzione un po' di storia Anni 2000 Nascita del Web Diminuisce notevolmente il costo dei sistemi di memorizzazione - Diffusione dell'e-commerce - Diffusione dei social media - Crescita esponenziale dei dati prodotti

5 NOSQL Introduzione un po' di storia Anni 2000 Nascita del Web Diminuisce notevolmente il costo dei sistemi di memorizzazione - Diffusione dell'e-commerce - Diffusione dei social media - Crescita esponenziale dei dati prodotti Necessità di scalare con il crescere dei dati

6 NOSQL Introduzione un po' di storia A questo punto la scalabilità dei sistemi RDBMS distribuiti non è più sufficiente per stare al passo con la velocità desiderata di produzione e consumo dei dati. Nascono quindi i database NOSQL per rispondere alle esigenze che con i RDBMS non potevano affrontare ovvero la necessità di una alta scalabilità orizzontale invece che una Scalabilità verticale scalabilità verticale (limitata) tipica dei RDBMS. Scalabilità orizzontale

7 NOSQL Introduzione un po' di storia

8 NOSQL RDBMS VS NoSQL

9 RDBMS vs NOSQL Fine delle relazioni? Dire che un sistema NoSQL è non relazionale significa che adottandolo si è costretti a rinunciare alle relazioni fra i dati? No! Anzi... NoSQL significa non tanto rinunciare al linguaggio SQL quanto rinunciare al rigido formalismo matematico, detto algebra relazionale, che è alla base di tutti i sistemi RDBMS e quindi liberarsi dai vincoli che esso impone.

10 NOSQL Fine delle relazioni? Quali sono questi vincoli? Ricordiamo che i sistemi RDBMS richiedono un processo di normalizzazione sui dati che consente di evidenziare le caratteristiche essenziali dei dati e le relazioni che tra essi intercorrono, eliminando tutte le ridondanze. Il risultato è un modello astratto dei dati, detto schema, che definisce univocamente la struttura e il tipo dei dati e li separa in tabelle.

11 NOSQL Fine delle relazioni? Due conseguenze fondamentali del processo di normalizzazione sono: - la necessità di utilizzare dei JOIN per ricostruire le informazioni da elaborare; operazione costosa sia computazionalmente che temporalmente; - la rigidità dello schema: - aggiungere un campo o una relazione rende necessario bloccare l'intero database fino a che la modifica non è completata; - solo i dati conformi allo schema possono essere memorizzati; Il costo relativo di questi vincoli aumenta con l'aumentare delle dimensioni dei dati da trattare e rende impossibile un'efficace scalabilità orizzontale.

12 RDBMS vs NOSQL Fine delle relazioni? I sistemi NoSQL non nascono quindi con l'obiettivo di rinunciare alle relazioni tra i dati ma, al contrario, dal desiderio di avere la massima libertà possibile di modificare ed alterare nel tempo sia la struttura dei dati che le relazioni che tra essi intercorrono. Per questo motivo si fondano su: - una organizzazione/memorizzazione dei dati in formati meno astratti e più vicini (ed utili) all'applicazione che li dovrà elaborare; - l'assenza di uno schema rigido che consenta di aggiungere nuovi dati, anche molto dissimili dai precedenti, e nuove relazioni senza la necessità di modificare la struttura del database e senza bloccarne l'accesso.

13 RDBMS vs NOSQL Acidi vs Basi Le caratteristiche ed i punti di forza dei sistemi RDBMS vengono spesso sintetizzate con l'acronimo ACID; per evidenziare il diverso approccio ai dati dei sistemi NoSQL alcuni dei loro punti di forza sono stati sintetizzati nell'acronimo BASE. A tomicity B asically C onsistency A vailable, I solation S oft State, D urability E ventually Consistent

14 RDBMS vs NOSQL CAP Theorem Perché abbandonare le proprietà ACID? Il CAP Theorem sostanzialmente dimostra che è impossibile garantire le proprietà ACID in un sistema distribuito e scalabile orizzontalmente. Quindi il superamento delle proprietà ACID non è un vezzo ma un passaggio obbligatorio qualora si voglia costruire un sistema distribuito.

15 RDBMS vs NOSQL CAP Theorem Nel 2000 Brewer teorizzo il seguente teorema noto CAP theorem: un sistema distribuito può fornire contemporaneamente solo due fra le seguenti garanzie: Consistency (Consistenza): tutti i nodi vedono gli stessi dati nello stesso momento; Availability (Disponibilità): il sistema risponde a tutte le richieste; Partition tolerance (Tolleranza al Partizionamento): il sistema continua ad operare anche se alcune sue parti rimangono isolate dalle altre in modo arbitrario (ovvero se il grafo che rappresenta il sistema è disconnesso).

16 RDBMS vs NOSQL CAP Theorem CA Consistency L'intersezione tra queste tre regioni è nulla. CP Partition Tollerance Availability AP

17 RDBMS vs NOSQL CAP Theorem Perché è impossibile garantire le proprietà ACID su un sistema distribuito? Un limite fondamentale di cui ci si dimentica spesso quando si progetta un software, anche nel caso di web services, è che la velocità della luce è costante. Questo fatto apparentemente irrilevante implica che un segnale che deve attraversare l'atlantico impiega circa 30 ms. cosa che rende estremamente complesso realizzare un sistema distribuito, altamente scalabile, fortemente interattivo e dunque indipendente dalla latenza.

18 RDBMS vs NOSQL CAP Theorem Vediamo attraverso alcuni diagrammi il significato del CAP Theorem. Nel diagramma sono illustrati due nodi N1 e N2 che condividono un dato V ( ognuno ne ha una copia) il cui valore è V0. Su ciascun nodo gira un algoritmo (A e B) che possiamo considerare sicuro, privo di errori, prevedibile ed affidabile. A scrive un nuovo valore su V B legge il valore di V.

19 RDBMS vs NOSQL CAP Theorem In un mondo ideale la rete sarebbe sempre affidabile e il trasferimento di informazioni istantaneo

20 RDBMS vs NOSQL CAP Theorem In un mondo reale la rete non sempre é affidabile e il trasferimento di informazioni non è istantaneo... N1 1 N1 A V1 Vo N1 A 2 A V1 3 V1 M N2 N2 B 1 N2 B Vo 2 B Vo 3 V0 V0

21 RDBMS vs NOSQL CAP Theorem In altri termini, il CAP Theorem ci dice che se vogliamo un sistema che sia - highly available, ovvero in grado di lavorare con latenza minima; - costituito da centinaia o migliaia di nodi - e che ciascun nodo sia tollerante alle interruzioni di rete ( messaggi persi, non recapitati, fallimento di processi, guasti hardware) allora dobbiamo accettare il fatto che ci saranno alcuni momenti in cui - un nodo sarà convinto che il valore di V sia V0 - ed un altro nodo sarà convinto che il valore di V sia V1

22 RDBMS vs NOSQL CAP Theorem CA Come ovviare ai limiti imposti dal CAP Theorem? Ci sono 3 possibilità: Consistency Availability 1 : CA - rinunciare alla Partitition Tolerance ovvero forzare tutti i dati richiesti da una transazione in un'unica macchina CP Partition Tollerance o quantomeno datacenter, con ovvi limiti alla scalabilità. Questo è tipicamente quello che si fa con i tradizionali RDBMS. AP

23 RDBMS vs NOSQL CAP Theorem CA Le altre due opzioni, con diverse sfumature, sono quelle adottate dai sistemi NoSQL 2 : CP rinunciare a qualcosa in termini di Availabilty per garantire consistenza Consistency Availability e robustezza al partizionamento; 3 : AP rinunciare a qualcosa in termini di Consistenza per garantire robustezza al partizionamento; disponibilità e CP Partition Tollerance AP

24 RDBMS vs NOSQL ACID Properties Atomicità: la transazione è indivisibile nella sua esecuzione e la sua esecuzione deve essere o totale o nulla, non sono ammesse esecuzioni parziali; Consistenza: quando inizia una transazione il database si trova in uno stato consistente e quando la transazione termina il database deve essere in un altro stato consistente, ovvero non deve violare eventuali vincoli di integrità, quindi non devono verificarsi contraddizioni (inconsistenza) tra i dati archiviati nel DB; 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, si riferisce al fatto che una volta che una transazione abbia richiesto un commit, i cambiamenti apportati non dovranno essere più persi.

25 RDBMS vs NOSQL ACID Properties Le proprietà ACID garantiscono l integrità e la consistenza del dato, ma per consentire la transazionalità impongono forti limiti alle performance ed alla scalabilità orizzontale. I produttori di sistemi RDBMS per ridurre i limiti alla scalabilità dei loro sistemi hanno sviluppato un protocollo denominato Two Phase Commit (2PC) che prevede che: - il coordinatore delle transazioni richiede a tutti i db coinvolti dalla transazione di effettuare un pre-commit per verificare la fattibilità dell'operazione; - ogni database effettua il pre-commit e invia una risposta al coordinatore; - se tutte le risposte sono positive il coordinatore conferma la transazione e le modifiche vengono apportate, altrimenti viene invocato un rollback.

26 RDBMS vs NOSQL BASE properties Giocoforza si è dovuto adottare una versione rilassata delle proprietà ACID che favoriscono la replicazione dei dati per aumentare la scalabilità orizzontale e la disponibilità del dato a scapito della consistenza (in senso ACID). Queste proprietà sono sintetizzate dall'acronimo : BASE = Basically Available, Soft state, Eventual consistency.

27 NOSQL Differenze RDBMS e NOSQL Basically Available. L'approccio NoSQL predilige la disponibilità del dato anche in presenza di molteplici errori. Viene ottenuto utilizzando un approccio altamente distribuito replicando i dati su un gran numero di sistemi di memorizzazione. E' la consistenza nel senso del teorema CAP. Soft state. Si abbandona la consistenza nel senso delle proprietà ACID. Lo stato del sistema può quindi variare nel tempo, teoricamente anche senza input specifici. Eventual consistency. Significa che in un qualche istante futuro i dati arriveranno in uno stato consistente (nel senso ACID). Non ci sono garanzie, ovviamente, su quando ed in quanto tempo questo avverrà. Questo perché: il sistema deve risponde subito alle richieste dei client; le modifiche ai dati si propagano in maniera asincrona fra i vari nodi.

28 NOSQL Tipologie di sistemi NoSQL

29 NOSQL Tipologie di NOSQL Proprio perché i database NOSQL sono incentrati sui dati esistono, ne esistono di diverse tipologie ed esistono diverse varianti all'interno della stessa tipologia. Le quattro tipologie principali di database NOSQL sono:

30 NOSQL Key-value stores I Key-Value stores puntano sugli aspetti di Availability e Partition Tolerance del teorema CAP e prendono origine dall'articolo di Amazon dove descriveva il suo database Dynamo. Lo scopo di Amazon era quello di avere un database altamente scalabile dove si potesse accedere ai dati in modo affidabile il più velocemente possibile in quanto i database relazionali non scalavano alla velocità necessaria. Lo sviluppo di Dynamo fu iniziato nel Esempi di database: Amazon Dynamo, Voldemort (Linkedin), MemcacheDB, Riak, Redis, BerkleyDB...

31 NOSQL Key-value stores I database Key-Value stores sono la più semplice tipologia di database NOSQL. Ad ogni chiave è associato un blob binario oscuro che può contenere qualsiasi tipologia di dato (stringa di testo, documento, immagine, video, ecc...). KEY VALUE Key 1 Key 2 Key 3 Stringa Key 4 Blob datatype

32 NOSQL Key-value stores KEY Key 1 Key 2 Key 3 Key 4 VALUE Il vantaggio è che si ha una struttura altamente scalabile con una API di interrogazione del database molto semplice: Aggiungi una coppia key/value Recuperare un blob data la sua chiave Cancellazione di una chiave Le differenze principali rispetto al modello relazionale: Una query restituisce un solo elemento I value possono contenere qualsiasi tipo di dato Lo svantaggio è che non c'è nessun modo di eseguire query basate sul contenuto del valore in quanto i blob sono oscuri.

33 NOSQL Document stores Sono orientati alla conservazione di documenti; quindi a differenza di quanto accade con i Key-Value stores, il contenuto non è una black-box ma è accessibile ed indicizzabile I Document stores si basano su un modello proposto già negli negli anni '80 da Lotus Notes; non a caso uno dei fondatori di CouchDB, Damien Katz, ha dichiarato Couch is Lotus Notes built from the ground up for the web. Esempi di DB: MongoDB, CouchDB, Couchbase...

34 NOSQL Document stores Lo scopo di questa tipologia di database è quella di archiviare in modo efficiente sia i documenti che il loro contenuto, perciò consentono di creare indici secondari in modo da poter recuperare i documenti anche in base al loro contenuto, metadati o combinazioni di essi. Inoltre, gli indici sono quasi sempre realizzati simili a quelle tipiche dei sistemi RDBMS che consentono ricerche per uguaglianza; per intervallo; indici su più attributi; riferimenti ad altri documenti.

35 NOSQL Document stores Esiste una limitata analogia fra i Document DB e gli RDBMS che si può riassumere in questa tabella e che può aiutare a comprenderne meglio l'organizzazione Relazionale Document stores Tabella Collection Riga Document Colonna Coppia Key/Value Join Non presente* I JOIN non sono presenti, ma i riferimenti verso altri documenti possono essere visti come una sorta JOIN. Va rimarcato che i documenti non hanno uno schema e che quindi possono essere costituiti da coppie key/value, coppie key/array, o anche documenti annidati.

36 NOSQL Document stores Il formato in cui vengono memorizzati i documenti è generalmente standard, anche se più raramente in alcuni casi vengono memorizzati file di documenti veri e propri (es. PDF, DOC ). Il formato più utilizzato è il JSON, gli altri formati utilizzati sono XML, YAML e BSON. Questo è dovuto principalmente anche alla forte integrazione che questi database hanno con Javascript. Inoltre, la possibilità di ottenere modelli di dati complessi senza rinunciare alle performance, li ha resi molto diffusi per siti web e di e-commerce, e gestione documentale.

37 NOSQL Column family stores I database Column family si ispirano all'articolo di Google dove descriveva il suo database Bigtable. Bigtable è un sistema di memorizzazione distribuito per la gestione di dati strutturati progettato per scalare su grandissime dimensioni: petabyte di dati distribuiti su migliaia di server. Dal 2006, Bigtable, è usato da Google in oltre 60 progetti. Esempi di DB: Bigtable, Hbase, Hypertable, Cassandra...

38 NOSQL Column family stores Column family store indica che il database è organizzato per colonne invece che per righe come nei RDBMS semplicità nell'aggiungere o modificare un record durante la lettura dei record si potrebbero leggere dati non necessari vengono letti solamente i dati di interesse la scrittura di una tupla richiede accessi multipli Ottimale per repository di grandi dimensioni che sono read-intensive

39 NOSQL Column family stores Un Column Family Store può esser visto come una mappa ordinata; multi-dimensionale; persistente; indicizzata per row key, column key e timestamp; Poiché ad ogni dato è associato un timestamp è possibile avere anche un versioning dei dati. Inoltre ogni riga può avere un numero differente di colonne, cosa che di fatto rende questo database una matrice multidimensionale sparsa. I column family si dividono in: Standard column family Super column family

40 NOSQL Column family: Standard Column Family La row key (la chiave più esterna ) identifica l'aggregato, che a sua volta mappa una o più famiglie di colonne dove possono essere presenti diversi valori associati column key. ad una diversa

41 NOSQL Column family: Super Column Family Un estensione dello Standard Column Family è rappresentato dal Super Column Family. Questo aggiunge modello un semplicemente ulteriore livello di indicizzazione fra la row key e l insieme delle colonne, la cosiddetta super column. Questa chiave viene utilizzata per raggruppare attributi correlati fra di loro, appartenenti allo stesso aggregato. Questa organizzazione ha vari vantaggi fra cui: dati più ordinati ed utilizzabili dalle applicazioni; sharding più efficiente.

42 NOSQL Column family stores Altri vantaggi dei Column family database sono: I valori in una singola colonna sono memorizzati in maniera contigua e conservati in specifici column datafile; I dati all'interno di ciascun column datafile sono dello stesso tipo, questo li rende ideali per la compressione; La memorizzazione per colonna permette di migliorare le performance delle query in quanto permette l'accesso diretto alle colonne; Alte performance nelle query di aggregazione (es. COUNT, SUM, AVG, MIN, MAX).

43 NOSQL Graph Quest'ultima tipologia di database NOSQL, a differenza delle precedenti, è relazionale, in quanto il suo focus è memorizzare i dati e le relazioni fra loro esistenti. I Graph stores sono ispirati dalla teoria dei grafi. E' la tipologia di database ideale per la gestione di social network e simili, nonché sistemi intelligenti che facciano uso di clustering e generazione di regole. Esempi di DB: Neo4j, OrientDB, AllegroGraph, InfiniteGraph...

44 NOSQL Graph Nome: Roberto Età: 36 Nome: Francesca Età: 34 Marca: Opel Modello: Corsa I nodi del grafo sono i dati ed hanno coppie key/value.

45 NOSQL Graph Nome: Roberto Età: 36 Ama Nome: Francesca Età: 34 Vive con Ama Possiede dal: 2008 Guida Marca: Opel Modello: Corsa Le relazioni sono gli edge del grafo, collegano i nodi, hanno una etichetta e possono avere coppie key/value. Inoltre, la semantica delle relazioni dipende dall'applicazione e quindi possono essere sia riflessive (es. Vive con) che no (es. Ama).

46 NOSQL Un punto di vista applicativo Confronto NoSQL

47 NOSQL Un punto di vista applicativo Una chiave di lettura molto interessante sui sistemi NoSQL è quella proposta da Martin Fowler nel suo libro NoSQL Distilled, che si fonda sull'utilizzo tipico che viene fatto di queste tecnologie. La prima domanda che si pone è: esiste davvero una linea di demarcazione netta tra Key-Value Stores e Document Stores?

48 NOSQL Un punto di vista applicativo Metadata customer ID: 4156 La risposta è NO. La maggior parte dei KV store consente di aggiungere dei metadati indicizzabili con cui recuperare velocemente i values associati (rendendoli simili ai document store) La maggior parte dei Document, associano automaticamente un ID al document che tipicamente viene recuperato per intero (ciò che si fa con i KV)

49 NOSQL Un punto di vista applicativo Anche i Column-Store, pur avendo una struttura più complicata, possono essere visti come degli Aggregate Store. Ogni Column-Family raggruppa un insieme di colonne simili che possono essere recuperate attraverso un'unica operazione. Ad esempio in una Colum-Family si possono racchiudere i dettagli dell'ordine Ed in un'altra i dettagli dei singoli Item associati all'ordine.

50 NOSQL Aggregate Storage Possiamo considerare i sistemi NoSQL come degli Aggregate Storage, cioè dei sistemi che ci consentono di memorizzare entità complesse (così come le abbiamo in RAM nella nostra applicazione) con un'unica operazione, come se fossero un'unica entità indivisibile. Consideriamo il caso banale di un ordine con più elementi al suo interno. In RAM avremo almeno un oggetto Order e un oggetto Item per ogni elemento. Tuttavia, anche discorsivamente, quando pensiamo di salvare l'ordine o leggere i dettagli dell'ordine, pensiamo all'ordine come un'unica entità complessa che vogliamo leggere e scrivere con un'unica operazione.

51 NOSQL Aggregate Storage I sistemi RDBMS ci costringono a spargere i dati su tante tabelle distinte e separare un' operazione in tante sotto-operazioni.....che poi raggrupperemo in una transazione per poter avere atomicità e consistenza.

52 NOSQL Aggregate Storage I sistemi NoSQL invece ci consentono di memorizzare l'intera struttura complessa come un unico Aggregato, così come lo abbiamo in RAM. KV : Aggregato == Value Document : Aggregato == Documento Col-Store : Aggregato == RowID + ColFamily

53 NOSQL Aggregate Storage - Drawbacks Esistono tuttavia delle controindicazioni nell'uso dei sistemi NoSQL. Supponiamo di voler fare un po' di analisi ed elaborare delle statistiche sulle vendite: Product Curr. Sales Prev. Sales PR PR PR

54 NOSQL Aggregate Storage - Drawbacks Ciò che stiamo facendo in questo caso è cambiare il cuore dell'aggregato. In questo caso l'aggregazione non sarà più incentrata sugli ordini, ma sui prodotti perché ci interessano gli andamenti delle vendite in diversi periodi dell'anno. Questo con i sistemi RDBMS risulta facile, basta cambiare leggermente la QUERY e le regole di raggruppamento. Con i sistemi NoSQL è invece molto più scomodo ottenere questo risultato e tipicamente si effettuano dei Job MapReduce che analizzano l'intera base dati. L'uso dei sistemi NoSQL risulta dunque vantaggioso quando l'accesso ai dati avviene per lo più in forma aggregata. Se invece si ha necessità di cambiare spesso forma di aggregazione un sistema RDBMS può essere più adatto.

55 NOSQL Aggregate Storage Fanno storia a se i Graph DB che invece hanno un approccio diametralmente opposto e presentano una parcellizzazione delle informazioni ancor più estrema di quella dei sistemi RDBMS.

56 NOSQL Confronto RDBMS vs NoSQL

57 RDBMS vs NoSQL MySQL vs Mongo Effettuare un confronto approfondito tra sistemi così diversi è molto complesso. Per dare un'idea dell'impatto delle caratteristiche ACID su un sistema distribuito e dei potenziali vantaggi di sistemi basati sul modello BASE, riportiamo i risultati di un confronto tra - MySQL installato in modalità distribuita e - MongoDB eseguiti nel dipartimento di High Performance Computing della Università di Edimburgo nel 2013.

58 RDBMS vs NoSQL MySQL Schema

59 RDBMS vs NoSQL Mongo Schema

60 RDBMS vs NoSQL Test 1 : Simple Query Test 1: Il primo test riguarda l'esecuzione di una query semplice che coinvolge una sola tabella. SELECT * FROM Users WHERE username = 'username'

61 RDBMS vs NoSQL Test 1 : Simple Query Tempo di esecuzione delle queries in diverse configurazioni:

62 RDBMS vs NoSQL Test 1 : Simple Query Numero di queries al secondo

63 RDBMS vs NoSQL Test 2 : Query with SELF JOIN Test 2: Il secondo test è più complesso e richiede l'utilizzo di un SELF JOIN SELECT 'Favourites.song_id' AS fsid, 'Favourites.userid' AS fuid FROM Favourites AS b INNER JOIN Favourites AS a ON b.user_id = a.user_id WHERE a.song_id = AND a.user_id!=

64 RDBMS vs NoSQL Test 2 : Query with SELF JOIN Tempo di esecuzione delle queries in diverse configurazioni:

65 RDBMS vs NoSQL Test 2 : Query with SELF JOIN Numero di queries al secondo

66 RDBMS vs NoSQL Test 3 : Complex Query Test 3: Il terzo test è ancora più complesso e richiede l'utilizzo di - una nested query e - 2 INNER JOIN SELECT 'Songs.release_id' AS sid, 'Releases.id' AS rid FROM Songs INNER JOIN Releases ON Songs.release_id = Releases.id WHERE artist_id IN (SELECT 'Genres.artist_id' AS gaid FROM Genres AS g INNER JOIN Artists AS a ON g.artist_id = a.id WHERE a.name = 'artist_name' )

67 RDBMS vs NoSQL Test 3 : Complex Query E' evidente come, anche in un setup piuttosto semplice come quello del test, crescere della complessità della query i tempi di esecuzione siano nettamente diversi. al

68 RDBMS vs NoSQL Test 4 : Variazione delle dimensioni del DB In questo caso si può notare come il tempo di esecuzione della query nel caso di MySQL aumenti con il crescere delle dimensioni del DB

69 RDBMS vs NoSQL Test comparativo Il test precedente ha messo in evidenza l'impatto negativo sulle performance dovuto ai JOIN ed agli accessi su più tabelle. Impatto percepibile anche in un sistema semplice con pochi dati e poche macchine tutte posizionate all'interno di uno stesso datacenter con connessioni ad alte prestazioni. Vediamo ora un secondo test che coinvolge anche HBase e Cassandra, effettuato su macchine virtuali fornite dagli Amazon Web Services, con un carico di lavoro più consistente ma con letture scritture su tabella singola, quindi senza l'impatto negativo dovuto ai JOIN.

70 RDBMS vs NoSQL Numeri del test Client : 1 Nodo - RAM : 7.5 GB - CPU : 4 Core Server : 4 Nodi - RAM : 15 GB - CPU : 8 Core Dati: Milioni di record - 10 campi per record thread attivi contemporaneamente (client-side)

71 RDBMS vs NoSQL Bulk Load Hbase è risultato il più veloce con 40K op/sec. Al secondo posto troviamo Cassandra con 15K op/sec.

72 RDBMS vs NoSQL Workload A ( 50% read, 50% update)

73 RDBMS vs NoSQL Workload A ( 50% read, 50% update)

74 RDBMS vs NoSQL Workload B ( 95% read, 5% update)

75 RDBMS vs NoSQL Workload B ( 95% read, 5% update)

76 RDBMS vs NoSQL Workload C : read-only N.B: Ricordiamo che si tratta di accessi su singola tabella a record con pochi campi.

77 RDBMS vs NoSQL Workload D ( 90% insert, 10% read)

78 NOSQL RDBMS vs NoSQL Come Scegliere?

79 NoSQL Quando e quale scegliere? Non esiste una riposta univoca a questa domanda. La scelta tra un sistema RDBMS ed una o più delle tipologie di sistemi NoSQL è strettamente legata al problema specifico che si deve affrontare. Nelle prossime slide cercheremo di fornire alcune linee guida che potranno essere d'aiuto nella scelta tra i vari sistemi. Innanzitutto è necessario porsi alcune domande...

80 Come Scegliere? Che vincoli ci impone il nostro problema? Vediamo alcune domande di carattere generale che dovremmo porci prima di decidere: Vincoli legati al modello : - Quante entità ci occorrono per modellare il problema? - Quante relazioni abbiamo tra le diverse entità? Quanto sono fitte? - Che probabilità c'è che lo schema possa cambiare? Con quale frequenza? Vincoli legati all'accesso ai dati: - Quanto è stringente il vincolo di consistenza? Dev'essere assoluta? E' ammissibile un ritardo di qualche ms o di qualche secondo nella propagazione degli aggiornamenti? - L'accesso ai dati avverrà su tutti i campi di un record o solo su alcuni di essi? - Le elaborazioni richiederanno l'accesso a più tabelle? O saranno concentrate solo su alcune colonne (es. data, prezzo, disponibilità...)?

81 Come Scegliere? Macro categorie di applicazioni Per orientarci meglio possiamo definire tre macro categorie che ci aiutino a capire i pro e i contro delle diverse soluzioni: - Applicazioni prettamente Transazionali: caratterizzate da forti vincoli di consistenza e certezza dell'informazione; - Applicazioni prettamente Computazionali, caratterizzate dalla necessità di eseguire elaborazioni anche complesse sui dati; - Applicazioni prettamente Interattive e Web Oriented: caratterizzate dalla presenza di un numero elevato di utenti e di dover loro garantire tempi di risposta molto brevi;

82 Come Scegliere? Applicazioni Transazionali Ad esempio gestione di un punto vendita o gestione risorse umane. Sono caratterizzate da : obbligatorietà della consistenza ed integrità dei dati; modesto livello di concorrenza (gestibile da una singola macchina) Vincoli sullo schema: tipicamente associate a problemi con dati fortemente strutturati relazioni chiare e strette tra le varie entità relazioni utilizzate di frequente schema stabile e con scarse probabilità di cambiamento

83 Come Scegliere? Applicazioni Transazionali Vincoli sull'accesso ai dati: consistenza (ogni lettura DEVE garantire il valore più aggiornato del dato) Row-Oriented (tipicamente viene letto l'intero record) frequente accesso a più tabelle (JOIN) necessità dell'uso delle transazioni (proprietà ACID)

84 Come Scegliere? Applicazioni Transazionali Pro NoSQL: Column Oriented: possono semplificare la gestione dello schema, che può facilmente variare nel tempo con l'aggiunta di colonne; Document : possono aiutare nella definizione di viste Contro NoSQL: non forniscono supporto alle relazioni (ad eccezione dei Graph DB); non forniscono supporto alle transazioni (no ACID); non forniscono supporto per JOIN o viste sui dati (tranne alcuni Document attraerso il modello MapReduce, che però non è facile da usare); Decisione: Questo è il regno dei sistemi RDBMS e difficilmente si possono avere dei vantaggi con sistemi NoSQL.

85 Come Scegliere? Applicazioni Computazionali Sono applicazioni tipicamente orientate all'elaborazione dei dati, ad esempio per la produzione di report di vendite; generazione di statistiche sull'utilizzo di un dato servizio individuazione di trend o altre funzionalità di analytics Tipicamente : operano su un sottoinsieme dei campi del record; fanno un uso piuttosto limitato delle relazioni tra tabelle; Vincoli sullo schema: tipicamente sono associate a schemi strutturati che variano poco nel tempo possono richiedere l'integrazione tra basi di dati diverse e dunque con schemi differenti;

86 Come Scegliere? Applicazioni Computazionali Accesso ai dati: tipicamente utilizzano un sottoinsieme dei campi di un record; Column-Oriented le elaborazioni da eseguire sui dati richiedono operazioni tra valori della stessa colonna associati a record diversi (es. colonna prezzo, colonna vendite ed acquisti, date...) accessi multi-tabella piuttosto rari; consistenza dei dati non stringente è richiesto il valore più recente del dato ma è ammissibile un lieve ritardo nel suo ottenimento in quanto tipicamente le elaborazioni non vengono effettuate in real-time;

87 Come Scegliere? Applicazioni Computazionali Pro NoSQL: Column Oriented: consentono la definizione di uno schema rigoroso e contemporaneamente facilitano l'uso di schemi variabili nel tempo ; Document / Key-Value : possono essere utilizzati ma non forniscono alcun supporto nella verifica dello correttezza dello schema; Possono garantire un notevole incremento di prestazioni durante l'accesso parziale ai record; Possono eseguire molte operazioni la dove sono memorizzati i dati senza necessità di spostarli attraverso la rete; con un sostanziale incremento delle prestazioni; Contro NoSQL: non forniscono supporto alle relazioni (ad eccezione dei Graph DB); l'assenza di regole e relazioni può generare temporanee inconsistenze tra i dati;

Linee di evoluzione dei Database

Linee di evoluzione dei Database Linee di evoluzione dei Database DB NoSQL Linked Open Data Semantic Web Esigenze e caratteristiche Presenza di grandi volumi di dati..crescenti Struttura non regolare dei dati da gestire Elementi relativamente

Dettagli

Diego GUENZI Rodolfo BORASO

Diego GUENZI Rodolfo BORASO Diego GUENZI Rodolfo BORASO NOSQL Movimento che promuove una classe non ben definita di strumenti di archiviazione di dati Un nuovo modo di vedere la persistenza Si differenziano dai RDBMS: Non utilizzano

Dettagli

MongoDB. Un database NoSQL Open-Source

MongoDB. Un database NoSQL Open-Source MongoDB Un database NoSQL Open-Source Database Relazionali I dati sono divisi in tabelle. Ogni tabella è composta da diverse colonne fisse. Le tabelle possono avere riferimenti tra loro. A.C.I.D. I database

Dettagli

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

Dettagli

NoSQL http://nosql. nosql-database.org/ Corso di Laurea Specialistica in Ingegneria Informatica. Corso di Linguaggi e Tecnologie Web A. A.

NoSQL http://nosql. nosql-database.org/ Corso di Laurea Specialistica in Ingegneria Informatica. Corso di Linguaggi e Tecnologie Web A. A. Corso di Laurea Specialistica in Ingegneria Informatica Corso di Linguaggi e Tecnologie Web A. A. 2011-2012 NoSQL http://nosql nosql-database.org/ Eufemia TINELLI Cosa è NoSQL? 1998 il termine NoSQL è

Dettagli

Panoramica dei più diffusi NoSQL Database

Panoramica dei più diffusi NoSQL Database Scuola Politecnica e delle Scienze di Base Corso di Laurea in Ingegneria Informatica Elaborato finale in Basi di Dati Panoramica dei più diffusi NoSQL Database Anno Accademico 2013/2014 Candidato: Buonocore

Dettagli

NOSQL Il database relazionale va in pensione,

NOSQL Il database relazionale va in pensione, Giovedì, 17 maggio 2012 Speaker: Manuel Scapolan NOSQL Il database relazionale va in pensione, avanza il movimento NOSQL RavenDB, database non relazionale, rappresentante del movimento NOSQL Sondaggio

Dettagli

DB NoSQL Analisi prestazionale

DB NoSQL Analisi prestazionale DB NoSQL Analisi prestazionale 1 I database NoSQL... 2 1.1 Perché NoSQL? Il teorema di CAP e il No-SQL data model... 2 1.2 Un confronto tra le famiglie di DB NoSQL... 5 1.3 I database document-oriented

Dettagli

"_id": "555ae00a475a9b259281b21a", "name": "Nicola Galgano", "alias": "alikon", "gender": "maschile", "work": consulente software bancario",

_id: 555ae00a475a9b259281b21a, name: Nicola Galgano, alias: alikon, gender: maschile, work: consulente software bancario, 1 } { "_id": "555ae00a475a9b259281b21a", "name": "Nicola Galgano", "alias": "alikon", "gender": "maschile", "work": consulente software bancario", "company": sto cercando ", "email": "info@alikonweb.it",

Dettagli

INFORMATICA. Applicazioni WEB a tre livelli con approfondimento della loro manutenzione e memorizzazione dati e del DATABASE.

INFORMATICA. Applicazioni WEB a tre livelli con approfondimento della loro manutenzione e memorizzazione dati e del DATABASE. INFORMATICA Applicazioni WEB a tre livelli con approfondimento della loro manutenzione e memorizzazione dati e del DATABASE. APPLICAZIONI WEB L architettura di riferimento è quella ampiamente diffusa ed

Dettagli

NoSQL database: la soluzione Oracle.

NoSQL database: la soluzione Oracle. Scuola Politecnica e delle Scienze di Base Corso di Laurea in Ingegneria Informatica Elaborato finale in Basi di Dati NoSQL database: la soluzione Oracle. Anno Accademico 2013/2014 Candidato: Alfonso Di

Dettagli

HBase Data Model. in più : le colonne sono raccolte in gruppi di colonne detti Column Family; Cosa cambia dunque?

HBase Data Model. in più : le colonne sono raccolte in gruppi di colonne detti Column Family; Cosa cambia dunque? NOSQL Data Model HBase si ispira a BigTable di Google e perciò rientra nella categoria dei column store; tuttavia da un punto di vista logico i dati sono ancora organizzati in forma di tabelle, in cui

Dettagli

POLITECNICO DI MILANO Facoltà di Ingegneria dell Informazione. Modellazione e valutazione delle prestazioni di database NoSQL

POLITECNICO DI MILANO Facoltà di Ingegneria dell Informazione. Modellazione e valutazione delle prestazioni di database NoSQL POLITECNICO DI MILANO Facoltà di Ingegneria dell Informazione Corso di Laurea Magistrale in Ingegneria Informatica Dipartimento di Elettronica, Informazione e Bioingegneria Modellazione e valutazione delle

Dettagli

Cassandra Introduzione

Cassandra Introduzione Introduzione Nasce inizialmente all'interno di Facebook per gestire le ricerche fra i messaggi. Attualmente open-source, è uno dei database NoSQL più diffusi. E' incluso tra i database NOSQL Column family

Dettagli

Concetti fondamentali dei database database Cos'è un database Principali database

Concetti fondamentali dei database database Cos'è un database Principali database Concetti fondamentali dei database Nella vita di tutti i giorni si ha la necessità di gestire e manipolare dati. Le operazioni possono essere molteplici: ricerca, aggregazione con altri e riorganizzazione

Dettagli

Tecnologie NoSQL: HBase

Tecnologie NoSQL: HBase Scuola Politecnica e delle Scienze di Base Corso di Laurea in Ingegneria Informatica Elaborato finale in Basi di Dati Tecnologie NoSQL: HBase Anno Accademico 2014/2015 Candidato: Daniela Bianco matr. N46001409

Dettagli

Data Warehousing e Data Mining

Data Warehousing e Data Mining Università degli Studi di Firenze Dipartimento di Sistemi e Informatica A.A. 2011-2012 I primi passi Data Warehousing e Data Mining Parte 2 Docente: Alessandro Gori a.gori@unifi.it OLTP vs. OLAP OLTP vs.

Dettagli

DBMS (Data Base Management System)

DBMS (Data Base Management System) Cos'è un Database I database o banche dati o base dati sono collezioni di dati, tra loro correlati, utilizzati per rappresentare una porzione del mondo reale. Sono strutturati in modo tale da consentire

Dettagli

Alla scoperta dei Graph Database

Alla scoperta dei Graph Database Alla scoperta dei Graph Database Matteo Pani 24 ottobre 2015 One size doesn t fit all Modellare le relazioni I Graph Database Il Labeled Property Graph Model I Graph-DBMS Neo4j Neo4j Internals Cypher Interagire

Dettagli

Database relazionali e NoSQL a confronto

Database relazionali e NoSQL a confronto Database relazionali e NoSQL a confronto Dimitri De Franciscis 10 aprile 2013 Sommario Scopo di questo lavoro è esplorare le possibilità offerte dai database appartenenti al movimento NoSQL e confrontarli,

Dettagli

CONFRONTO TRA DBMS RELAZIONALI, A COLONNE E NOSQL

CONFRONTO TRA DBMS RELAZIONALI, A COLONNE E NOSQL CONFRONTO TRA DBMS RELAZIONALI, A COLONNE E NOSQL Università degli Studi di Modena e Reggio Emilia Dipartimento di Ingegneria Enzo Ferrari di Modena Corso di Laurea in Ingegneria Informatica (L.270/04)

Dettagli

CORSO I.F.T.S TECNICHE PER LA PROGETTAZIONE E LA GESTIONE DI DATABASE

CORSO I.F.T.S TECNICHE PER LA PROGETTAZIONE E LA GESTIONE DI DATABASE CORSO I.F.T.S TECNICHE PER LA PROGETTAZIONE E LA GESTIONE DI DATABASE Ing. Mariano Di Claudio Lezione del 24/09/2014 Indice 1. Aspetti di Data Management CouchBase 2. Aspetti Architetturali Infrastruttura

Dettagli

Basi di Dati. prof. Letizia Tanca. Le transazioni e il database server, cenni sui nuovi sistemi per Big Data

Basi di Dati. prof. Letizia Tanca. Le transazioni e il database server, cenni sui nuovi sistemi per Big Data Basi di Dati prof. Letizia Tanca Le transazioni e il database server, cenni sui nuovi sistemi per Big Data (lucidi parzialmente tratti dal libro: Atzeni, Ceri, Paraboschi, Torlone Introduzione alle Basi

Dettagli

Tecnologia di un Database Server (centralizzato) Introduzione generale

Tecnologia di un Database Server (centralizzato) Introduzione generale Introduzione Basi di Dati / Complementi di Basi di Dati 1 Tecnologia di un Database Server (centralizzato) Introduzione generale Angelo Montanari Dipartimento di Matematica e Informatica Università di

Dettagli

Informatica Generale Andrea Corradini. 19 - Sistemi di Gestione delle Basi di Dati

Informatica Generale Andrea Corradini. 19 - Sistemi di Gestione delle Basi di Dati Informatica Generale Andrea Corradini 19 - Sistemi di Gestione delle Basi di Dati Sommario Concetti base di Basi di Dati Il modello relazionale Relazioni e operazioni su relazioni Il linguaggio SQL Integrità

Dettagli

Database NoSQL: i GraphDB

Database NoSQL: i GraphDB Scuola Politecnica e delle Scienze di Base Corso di Laurea in Ingegneria Informatica Elaborato finale in Basi di Dati Database NoSQL: i GraphDB Anno Accademico 2013/2014 Candidato: Daniele Passaretti matr.n46/001340

Dettagli

Corso di Informatica Generale 1 IN1. Linguaggio SQL

Corso di Informatica Generale 1 IN1. Linguaggio SQL Università Roma Tre Facoltà di Scienze M.F.N. di Laurea in Matematica di Informatica Generale 1 Linguaggio SQL Marco (liverani@mat.uniroma3.it) Sommario Prima parte: le basi dati relazionali Basi di dati:

Dettagli

Istituto Angioy Informatica BASI DI DATI. Prof. Ciaschetti

Istituto Angioy Informatica BASI DI DATI. Prof. Ciaschetti Istituto Angioy Informatica BASI DI DATI Prof. Ciaschetti Introduzione e prime definizioni Una Base di dati o Database è un archivio elettronico opportunamente organizzato per reperire in modo efficiente

Dettagli

DATABASE. www.andreavai.it

DATABASE. www.andreavai.it Cos'è un database? Quando si usa? Differenze con i fogli elettronici Le tabelle: record, campi, tipi di dati Chiavi e indici Database relazionali (R-DBMS) Relazioni uno-a-uno Relazioni uno-a-molti Relazioni

Dettagli

LABORATORIO di INFORMATICA

LABORATORIO di INFORMATICA Università degli Studi di Cagliari Corso di Laurea Magistrale in Ingegneria per l Ambiente ed il Territorio LABORATORIO di INFORMATICA A.A. 2010/2011 Prof. Giorgio Giacinto INTRODUZIONE AI SISTEMI DI BASI

Dettagli

Facoltà di Ingegneria Corso di Studi in Ingegneria Informatica Basi di Dati Graph Database MARCO DE MASI matr. N46000365

Facoltà di Ingegneria Corso di Studi in Ingegneria Informatica  Basi di Dati Graph Database MARCO DE MASI matr. N46000365 Facoltà di Ingegneria Corso di Studi in Ingegneria Informatica Elaborato finale in Basi di Dati Graph Database Anno Accademico 2012/2013 Candidato: MARCO DE MASI matr. N46000365 Indice Introduzione 4

Dettagli

NoSQL Databases. Massimo Carro

NoSQL Databases. Massimo Carro NoSQL Databases Massimo Carro Politecnico di Milano Piazza Leonardo da Vinci 32 20133 Milano massimo.carro@mail.polimi.it 1. Introduzione L arrivo di internet negli anni 90 ha permesso a molte aziende

Dettagli

NoSQL: concetti generali

NoSQL: concetti generali NoSQL: concetti generali Paolo Atzeni 30/05/2011 Il solito primo lucido DataBase Management System (DBMS) Sistema che gestisce collezioni di dati: grandi persistenti condivise garantendo privatezza affidabilità

Dettagli

Indice Prefazione... 1 1 SQL Procedurale/SQL-PSM (Persistent Stored Modules)... 3 Vincoli e Trigger... 9

Indice Prefazione... 1 1 SQL Procedurale/SQL-PSM (Persistent Stored Modules)... 3 Vincoli e Trigger... 9 Prefazione... 1 Contenuti... 1 Ringraziamenti... 2 1 SQL Procedurale/SQL-PSM (Persistent Stored Modules)... 3 1.1 Dichiarazione di funzioni e procedure... 3 1.2 Istruzioni PSM... 4 2 Vincoli e Trigger...

Dettagli

TEORIA sulle BASI DI DATI

TEORIA sulle BASI DI DATI TEORIA sulle BASI DI DATI A cura del Prof. Enea Ferri Cos è un DATA BASE E un insieme di archivi legati tra loro da relazioni. Vengono memorizzati su memorie di massa come un unico insieme, e possono essere

Dettagli

Esercitazione query in SQL L esercitazione viene effettuata sul database viaggi e vacanze che prevede il seguente modello E/R:

Esercitazione query in SQL L esercitazione viene effettuata sul database viaggi e vacanze che prevede il seguente modello E/R: Esercitazione query in SQL L esercitazione viene effettuata sul database viaggi e vacanze che prevede il seguente modello E/R: Si consiglia di creare il data base, inserire i dati nelle tabelle, provare

Dettagli

Cluster per architetture a componenti

Cluster per architetture a componenti Luca Cabibbo Architetture Software Cluster per architetture a componenti Dispensa ASW 442 ottobre 2014 Un buon progetto produce benefici in più aree. Trudy Benjamin 1 -Fonti [IBM] Clustering Solutions

Dettagli

Operazioni sui database

Operazioni sui database Operazioni sui database Le operazioni nel modello relazionale sono essenzialmente di due tipi: Operazioni di modifica della base di dati (update) Interrogazioni della base di dati per il recupero delle

Dettagli

ANALISI DELLE PERFORMANCE DEI DATABASE NON RELAZIONALI IL CASO DI STUDIO DI MONGODB

ANALISI DELLE PERFORMANCE DEI DATABASE NON RELAZIONALI IL CASO DI STUDIO DI MONGODB UNIVERSITÀ DEGLI STUDI DI PADOVA DIPARTIMENTO DI INGEGNERIA DELL INFORMAZIONE TESI DI LAUREA ANALISI DELLE PERFORMANCE DEI DATABASE NON RELAZIONALI IL CASO DI STUDIO DI MONGODB RELATORE: Ch.mo Prof. Giorgio

Dettagli

Introduzione alle Basi di Dati

Introduzione alle Basi di Dati 1 Introduzione alle Basi di Dati Massimo Paolucci (paolucci@dist.unige.it) DIST Università di Genova Sistema Azienda 2 Sistema organizzativo è costituito da una serie di risorse e di regole necessarie

Dettagli

Big Query, nosql e Big Data

Big Query, nosql e Big Data Big Query, nosql e Big Data Ma c'è veramente bisogno di gestire tutti questi dati? Immaginiamo che.. L'attuale tecnologia Database e Web Services fosse disponibile già DA ANNI Cosa cambierebbe nella Vita

Dettagli

Analisi e sperimentazione del DBMS NoSQL MongoDB: il caso di studio della Social Business Intelligence

Analisi e sperimentazione del DBMS NoSQL MongoDB: il caso di studio della Social Business Intelligence ALMA MATER STUDIORUM - UNIVERSITA' DI BOLOGNA CAMPUS DI CESENA SCUOLA DI SCIENZE CORSO DI LAUREA IN SCIENZE E TECNOLOGIE INFORMATICHE TITOLO DELLA RELAZIONE FINALE Analisi e sperimentazione del DBMS NoSQL

Dettagli

Indice. Ringraziamenti dell Editore

Indice. Ringraziamenti dell Editore Prefazione Autori Ringraziamenti dell Editore XVII XXI XXIII 1 Introduzione 1 1.1 Sistemi informativi, informazioni e dati 1 1.2 Basi di dati e sistemi di gestione di basi di dati 3 1.3 Modelli dei dati

Dettagli

Il DBMS Oracle. Express Edition. Donatella Gubiani e Angelo Montanari

Il DBMS Oracle. Express Edition. Donatella Gubiani e Angelo Montanari Gubiani & Montanari Il DBMS Oracle 1 Il DBMS Oracle Express Edition Donatella Gubiani e Angelo Montanari Il DBMS Oracle Il DBMS Oracle Oracle 10g Express Edition Il DBMS Oracle (nelle sue versioni più

Dettagli

Modelli relazionali. Esistono diversi modi di modellare un database. Il modello piu' usato al momento e' il modello relazionale

Modelli relazionali. Esistono diversi modi di modellare un database. Il modello piu' usato al momento e' il modello relazionale Cenni sui DATABASE Cos'e' un database Un database puo' essere definito come una collezione strutturata di record (dati) I dati sono memorizzati su un computer in modo opportuno e possono essere recuperati

Dettagli

Organizzazione degli archivi

Organizzazione degli archivi COSA E UN DATA-BASE (DB)? è l insieme di dati relativo ad un sistema informativo COSA CARATTERIZZA UN DB? la struttura dei dati le relazioni fra i dati I REQUISITI DI UN DB SONO: la ridondanza minima i

Dettagli

Corso di Laboratorio di Basi di Dati

Corso di Laboratorio di Basi di Dati Corso di Laboratorio di Basi di Dati F1I072 - INF/01 a.a 2009/2010 Pierluigi Pierini Technolabs S.p.a. Pierluigi.Pierini@technolabs.it Università degli Studi di L Aquila Dipartimento di Informatica Technolabs

Dettagli

Studio delle principali Tecnologie No-SQL

Studio delle principali Tecnologie No-SQL Facoltà di Ingegneria Corso di Studi in Ingegneria Informatica Elaborato finale in Basi di Dati Studio delle principali Tecnologie No-SQL Anno Accademico 2010/2011 Candidato: Giovanni Trotta matr. N46/000047

Dettagli

L ARCHIVIAZIONE E LA GESTIONE DATI ATTRAVERSO L INTERAZIONE TRA MICROSOFT ACCESS ED EXCEL 1 INTRODUZIONE

L ARCHIVIAZIONE E LA GESTIONE DATI ATTRAVERSO L INTERAZIONE TRA MICROSOFT ACCESS ED EXCEL 1 INTRODUZIONE Roccatello Ing. Eduard L ARCHIVIAZIONE E LA GESTIONE DATI ATTRAVERSO L INTERAZIONE TRA MICROSOFT ACCESS ED EXCEL 1 INTRODUZIONE Agenda Presentazione docente Definizione calendario Questionario pre corso

Dettagli

ITI M. FARADAY Programmazione modulare a.s. 2014-2015

ITI M. FARADAY Programmazione modulare a.s. 2014-2015 Indirizzo: INFORMATICA E TELECOMUNICAZIONI Disciplina: Informatica Docente:Maria Teresa Niro Classe: Quinta B Ore settimanali previste: 6 (3 ore Teoria - 3 ore Laboratorio) ITI M. FARADAY Programmazione

Dettagli

Sistemi avanzati di gestione dei Sistemi Informativi

Sistemi avanzati di gestione dei Sistemi Informativi Esperti nella gestione dei sistemi informativi e tecnologie informatiche Sistemi avanzati di gestione dei Sistemi Informativi Docente: Email: Sito: Eduard Roccatello eduard@roccatello.it http://www.roccatello.it/teaching/gsi/

Dettagli

Basi di Dati prof. A. Longheu. 5 Progettazione fisica

Basi di Dati prof. A. Longheu. 5 Progettazione fisica Basi di Dati prof. A. Longheu 5 Progettazione fisica Progettazione Fisica Per effettuare la progettazione fisica, ossia l implementazione reale del modello logico creato nella fase della progettazione

Dettagli

Ministero della Pubblica Istruzione Ufficio Scolastico Regionale per la Sicilia Direzione Generale

Ministero della Pubblica Istruzione Ufficio Scolastico Regionale per la Sicilia Direzione Generale Unione Europea Regione Sicilia Ministero della Pubblica Istruzione Ufficio Scolastico Regionale per la Sicilia Direzione Generale ISTITUTO TECNICO INDUSTRIALE STATALE G. MARCONI EDILIZIA ELETTRONICA e

Dettagli

Archivi e database. Lezione n. 7

Archivi e database. Lezione n. 7 Archivi e database Lezione n. 7 Dagli archivi ai database (1) I dati non sempre sono stati considerati dall informatica oggetto separato di studio e di analisi Nei primi tempi i dati erano parte integrante

Dettagli

Indice generale. Nota dell editore...xiii. Parte I Antipattern nella progettazione logica di database 11

Indice generale. Nota dell editore...xiii. Parte I Antipattern nella progettazione logica di database 11 Indice generale Nota dell editore...xiii Capitolo 1 Introduzione...1 1.1 A chi si rivolge questo libro... 2 1.2 Contenuto del libro... 3 Struttura del libro... 3 Anatomia di un antipattern... 4 1.3 Che

Dettagli

File e indici. Tecnologia delle BD: perché studiarla? Le basi di dati sono grandi e persistenti. DataBase Management System DBMS

File e indici. Tecnologia delle BD: perché studiarla? Le basi di dati sono grandi e persistenti. DataBase Management System DBMS 1 Tecnologia delle BD: perché studiarla? File e indici I DBMS offrono i loro servizi in modo "trasparente": per questo abbiamo potuto finora ignorare molti aspetti realizzativi abbiamo considerato il DBMS

Dettagli

Archivi e Basi di Dati

Archivi e Basi di Dati Archivi e Basi di Dati A B C File Programma 1 Programma 2 A B C File modificati Programma 1 DBMS DB Programma 2 Informatica Generale (CdL in E&C), A.A. 2000-2001 55 Problemi nella gestione di archivi separati

Dettagli

Big ed Open Data, nosql e..

Big ed Open Data, nosql e.. Big ed Open Data, nosql e.. Quadro d insieme Tecnologie interconnesse ed interoperanti Big Data Software Open Open Data Mobile Internet delle Cose Dispositivi indossabili Social Network e Search Metodologie

Dettagli

CORSO I.F.T.S TECNICHE PER LA PROGETTAZIONE E LA GESTIONE DI DATABASE

CORSO I.F.T.S TECNICHE PER LA PROGETTAZIONE E LA GESTIONE DI DATABASE CORSO I.F.T.S TECNICHE PER LA PROGETTAZIONE E LA GESTIONE DI DATABASE Ing. Mariano Di Claudio Lezione del 20/10/2014 1 Indice 1. HBase e Hrider Caratteristiche chiave Modello dati Architettura Installazione

Dettagli

Cultura Tecnologica di Progetto

Cultura Tecnologica di Progetto Cultura Tecnologica di Progetto Politecnico di Milano Facoltà di Disegno Industriale - DATABASE - A.A. 2003-2004 2004 DataBase DB e DataBase Management System DBMS - I database sono archivi che costituiscono

Dettagli

DATABASE RELAZIONALI

DATABASE RELAZIONALI 1 di 54 UNIVERSITA DEGLI STUDI DI NAPOLI FEDERICO II DIPARTIMENTO DI DISCIPLINE STORICHE ETTORE LEPORE DATABASE RELAZIONALI Dott. Simone Sammartino Istituto per l Ambiente l Marino Costiero I.A.M.C. C.N.R.

Dettagli

MongoDB Analisi e prototipazione su applicazioni di Social Business Intelligence

MongoDB Analisi e prototipazione su applicazioni di Social Business Intelligence ALMA MATER STUDIORUM UNIVERSITÀ DI BOLOGNA SEDE DI CESENA FACOLTÀ DI SCIENZE MATEMATICHE, FISICHE E NATURALI Corso di Laurea Triennale in Scienze e Tecnologie Informatiche MongoDB Analisi e prototipazione

Dettagli

SQL IL LINGUAGGIO DI INTERROGAZIONE

SQL IL LINGUAGGIO DI INTERROGAZIONE SQL IL LINGUAGGIO DI INTERROGAZIONE SQL! Originato da SEQUEL-XRM e System-R (1974-1977) dell IBM! Significato originario Structured Query Language! Standard de facto! Attuale standard ANSI/ISO è SQL:1999

Dettagli

Base Dati Introduzione

Base Dati Introduzione Università di Cassino Facoltà di Ingegneria Modulo di Alfabetizzazione Informatica Base Dati Introduzione Si ringrazia l ing. Francesco Colace dell Università di Salerno Gli archivi costituiscono una memoria

Dettagli

Tecnologia di un Database Server (centralizzato) Gestione dell affidabilità

Tecnologia di un Database Server (centralizzato) Gestione dell affidabilità Affidabilità Basi di Dati / Complementi di Basi di Dati 1 Tecnologia di un Database Server (centralizzato) Gestione dell affidabilità Angelo Montanari Dipartimento di Matematica e Informatica Università

Dettagli

Data warehouse. Architettura complessiva con OLTP e OLAP OLTP. Sistemi di supporto alle decisioni

Data warehouse. Architettura complessiva con OLTP e OLAP OLTP. Sistemi di supporto alle decisioni Data warehouse Data warehouse La crescita dell importanza dell analisi dei dati ha portato ad una separazione architetturale dell ambiente transazionale (OLTP on-line transaction processing) da quello

Dettagli

TABLESAMPLE. Di Gianluca Negrelli. SELECT TOP 25 * FROM Prodotti ORDER BY NEWID() SET NOCOUNT ON;

TABLESAMPLE. Di Gianluca Negrelli. SELECT TOP 25 * FROM Prodotti ORDER BY NEWID() SET NOCOUNT ON; TABLESAMPLE Di Gianluca Negrelli La clausola TABLESAMPLE, introdotta in SQL Server 2005, permette di estrarre un campione casuale di record (sample) da una qualsiasi tabella. Prima dell'arrivo di TABLESAMPLE

Dettagli

Basi di Dati Complementi Esercitazione su Data Warehouse

Basi di Dati Complementi Esercitazione su Data Warehouse Sommario Basi di Dati Complementi Esercitazione su Data Warehouse 1. Riassunto concetti principali dalle slide della lezione di teoria 2.Studio di caso : progettazione di un Data Warehouse di una catena

Dettagli

Basi di Dati Distribuite

Basi di Dati Distribuite Basi di Dati Distribuite P. Atzeni, S. Ceri, S. Paraboschi, R. Torlone (McGraw-Hill Italia) Basi di dati: architetture linee di evoluzione - seconda edizione Capitolo 3 Appunti dalle lezioni SQL come DDL

Dettagli

Al giorno d oggi, i sistemi per la gestione di database

Al giorno d oggi, i sistemi per la gestione di database Introduzione Al giorno d oggi, i sistemi per la gestione di database implementano un linguaggio standard chiamato SQL (Structured Query Language). Fra le altre cose, il linguaggio SQL consente di prelevare,

Dettagli

DDL, VINCOLI D INTEGRITÁ, AGGIORNAMENTI E VISTE. SQL è più di un semplice linguaggio di interrogazione

DDL, VINCOLI D INTEGRITÁ, AGGIORNAMENTI E VISTE. SQL è più di un semplice linguaggio di interrogazione SQL DDL, VINCOLI D INTEGRITÁ, AGGIORNAMENTI E VISTE SQL è più di un semplice linguaggio di interrogazione! Linguaggio di definizione dati (Data-definition language, DDL):! Crea/distrugge/modifica relazioni

Dettagli

Corso di Laurea in Ingegneria Informatica Fondamenti di Informatica II Modulo Basi di dati a.a. 2013-2014

Corso di Laurea in Ingegneria Informatica Fondamenti di Informatica II Modulo Basi di dati a.a. 2013-2014 Corso di Laurea in Ingegneria Informatica Fondamenti di Informatica II Modulo Basi di dati a.a. 2013-2014 Docente: Gigliola Vaglini Docente laboratorio: Francesco Pistolesi 1 Obiettivi del corso Imparare

Dettagli

Corso di Laurea in Ingegneria Informatica Algoritmi e basi di dati Modulo Basi di dati a.a. 2010-2011

Corso di Laurea in Ingegneria Informatica Algoritmi e basi di dati Modulo Basi di dati a.a. 2010-2011 Corso di Laurea in Ingegneria Informatica Algoritmi e basi di dati Modulo Basi di dati a.a. 2010-2011 2011 Docente: Gigliola Vaglini Docente laboratorio: Alessandro Lori 1 Obiettivi del corso Imparare

Dettagli

11. Basi di dati distribuite ed architetture client-server

11. Basi di dati distribuite ed architetture client-server 11. Basi di dati distribuite ed architetture client-server In questa lezione focalizzeremo la nostra attenzione sui Database distribuiti (DDB), i sistemi per la gestione di Database Distribuiti (DDBMS),

Dettagli

Corso di Informatica

Corso di Informatica Corso di Informatica Modulo T2 A2 Introduzione ai database 1 Prerequisiti Concetto di sistema File system Archivi File e record 2 1 Introduzione Nella gestione di una attività, ad esempio un azienda, la

Dettagli

Data warehousing Mario Guarracino Data Mining a.a. 2010/2011

Data warehousing Mario Guarracino Data Mining a.a. 2010/2011 Data warehousing Introduzione A partire dagli anni novanta è risultato chiaro che i database per i DSS e le analisi di business intelligence vanno separati da quelli operazionali. In questa lezione vedremo

Dettagli

La Document Orientation. Come implementare un interfaccia

La Document Orientation. Come implementare un interfaccia La Document Orientation Come implementare un interfaccia Per eliminare l implementazione di una interfaccia da parte di una classe o documento, occorre tirarla su di esso tenendo premuto il tasto ctrl.

Dettagli

Basi di Dati Uso di informazioni statistiche e partizionamento delle tabelle per incrementare le performances in PostgreSQL

Basi di Dati Uso di informazioni statistiche e partizionamento delle tabelle per incrementare le performances in PostgreSQL Basi di Dati Uso di informazioni statistiche e partizionamento delle tabelle per incrementare le performances in PostgreSQL di Matteo Bertini Email: matteo@naufraghi.net Web: http://www.slug.it/naufraghi/

Dettagli

Azioni. Select e join non consentono di modificare il contenuto del DB. Inserzione di nuovi dati. Azioni desiderate. Aggiornamento di dati

Azioni. Select e join non consentono di modificare il contenuto del DB. Inserzione di nuovi dati. Azioni desiderate. Aggiornamento di dati Azioni Select e join non consentono di modificare il contenuto del DB Azioni desiderate Inserzione di nuovi dati Aggiornamento di dati Cancellazione di dati Aggiunta di un record insert into utenti(nome,tel,codice_u)

Dettagli

Basi di dati. Informatica. Prof. Pierpaolo Vittorini pierpaolo.vittorini@cc.univaq.it

Basi di dati. Informatica. Prof. Pierpaolo Vittorini pierpaolo.vittorini@cc.univaq.it pierpaolo.vittorini@cc.univaq.it Università degli Studi dell Aquila Facoltà di Medicina e Chirurgia 18 marzo 2010 Un esempio di (semplice) database Quando si pensa ad un database, generalmente si immagina

Dettagli

Capitolo 13. Interrogare una base di dati

Capitolo 13. Interrogare una base di dati Capitolo 13 Interrogare una base di dati Il database fisico La ridondanza è una cosa molto, molto, molto brutta Non si devono mai replicare informazioni scrivendole in più posti diversi nel database Per

Dettagli

Navigare verso il cambiamento. La St r a d a. p i ù semplice verso il ca m b i a m e n t o

Navigare verso il cambiamento. La St r a d a. p i ù semplice verso il ca m b i a m e n t o Navigare verso il cambiamento La St r a d a p i ù semplice verso il ca m b i a m e n t o Le caratteristiche tecniche del software La Tecnologia utilizzata EASY è una applicazione Open Source basata sul

Dettagli

Introduzione ad OLAP (On-Line Analytical Processing)

Introduzione ad OLAP (On-Line Analytical Processing) Introduzione ad OLAP (On-Line Analytical Processing) Metodi e Modelli per il Supporto alle Decisioni 2002 Dipartimento di Informatica Sistemistica e Telematica (Dist) Il termine OLAP e l acronimo di On-Line

Dettagli

Teoria sulle basi di dati

Teoria sulle basi di dati Teoria sulle basi di dati Introduzione alle basi di dati Una base di dati (database) può essere considerata come una raccolta di dati logicamente correlati, utilizzata per modellare una realtà. I dati

Dettagli

Transazioni - Parte 1

Transazioni - Parte 1 Basi di dati II Lezione 3 09/10/2008 Caputo Domenico Cosimo, Francesco Pichierri Transazioni - Parte 1 Le transazioni hanno a che fare con la programmabilità delle basi di dati. Prima di trattarle è necessaria

Dettagli

Sistemi Informativi Aziendali II

Sistemi Informativi Aziendali II Modulo 2 Sistemi Informativi Aziendali II 1 Corso Sistemi Informativi Aziendali II - Modulo 2 Modulo 2 La gestione delle informazioni strutturate nell impresa: La progettazione di un Data Base; Le informazioni

Dettagli

Architettura dei sistemi di database

Architettura dei sistemi di database 2 Architettura dei sistemi di database 1 Introduzione Come si potrà ben capire, l architettura perfetta non esiste, così come non è sensato credere che esista una sola architettura in grado di risolvere

Dettagli

Il modello relazionale dei dati

Il modello relazionale dei dati Il modello relazionale dei dati Master Alma Graduate School Sistemi Informativi Home Page del corso: http://www-db.deis.unibo.it/courses/alma_si1/ Versione elettronica: 04Relazionale.pdf Obiettivi della

Dettagli

Indice Introduzione Elementi di base dei database Il linguaggio SQL (Structured Query Language)

Indice Introduzione Elementi di base dei database Il linguaggio SQL (Structured Query Language) Indice Introduzione XI Capitolo 1 Elementi di base dei database 1 1.1 Che cos è un database 1 1.2 L architettura di Oracle Database 10g 3 Progetto 1.1 L architettura di Oracle Database 10g 8 1.3 I tipi

Dettagli

Informatica Documentale

Informatica Documentale Informatica Documentale Ivan Scagnetto (scagnett@dimi.uniud.it) Stanza 3, Nodo Sud Dipartimento di Matematica e Informatica Via delle Scienze, n. 206 33100 Udine Tel. 0432 558451 Ricevimento: giovedì,

Dettagli

SCHEDA DI PROGRAMMAZIONE DISCIPLINARE DA RIPORTARE SUL P.O.F. A.S. 2014-2015. Ripasso programmazione ad oggetti. Basi di dati: premesse introduttive

SCHEDA DI PROGRAMMAZIONE DISCIPLINARE DA RIPORTARE SUL P.O.F. A.S. 2014-2015. Ripasso programmazione ad oggetti. Basi di dati: premesse introduttive SCHEDA DI PROGRAMMAZIONE DISCIPLINARE DA RIPORTARE SUL P.O.F. A.S. 2014-2015 ASSE DISCIPLINA DOCENTE MATEMATICO INFORMATICA Cattani Barbara monoennio CLASSE: quinta CORSO D SEZIONE LICEO SCIENZE APPLICATE

Dettagli

RELAZIONE FINALE DEL DOCENTE

RELAZIONE FINALE DEL DOCENTE ALLEGATO A - INFORMATICA RELAZIONE FINALE DEL DOCENTE MATERIA: INFORMATICA Classe 5 sez. Bsia a.s. 2014/15 DOCENTE: prof. Domenico Francullo In relazione alla programmazione curricolare sono stati conseguiti

Dettagli

Breve introduzione ai data warehouse (per gli allievi che non hanno seguito BD2)

Breve introduzione ai data warehouse (per gli allievi che non hanno seguito BD2) Tecnologie per i sistemi informativi Breve introduzione ai data warehouse (per gli allievi che non hanno seguito BD2) Letizia Tanca lucidi tratti dal libro: Atzeni, Ceri, Paraboschi, Torlone Introduzione

Dettagli

Sistema di Gestione di Basi di Dati DataBase Management System DBMS

Sistema di Gestione di Basi di Dati DataBase Management System DBMS Base di dati (accezione generica) collezione di dati, utilizzati per rappresentare le informazioni di interesse per una o più applicazioni di una organizzazione (accezione specifica) collezione di dati

Dettagli

Il linguaggio SQL. è di fatto lo standard tra i linguaggi per la gestione di data base relazionali.

Il linguaggio SQL. è di fatto lo standard tra i linguaggi per la gestione di data base relazionali. (Structured Query Language) : Il linguaggio è di fatto lo standard tra i linguaggi per la gestione di data base relazionali. prima versione IBM alla fine degli anni '70 per un prototipo di ricerca (System

Dettagli

Algebra e calcolo relazionale. Ripasso. Le 7 Virtù del DBMS persistenza affidabilità volume condivisione riservatezza efficienza efficacia

Algebra e calcolo relazionale. Ripasso. Le 7 Virtù del DBMS persistenza affidabilità volume condivisione riservatezza efficienza efficacia Algebra e calcolo relazionale Ripasso Le 7 Virtù del DBMS persistenza affidabilità volume condivisione riservatezza efficienza efficacia I 4 Livelli di astrazione Le Tabelle Livello fisico (o interno)

Dettagli

ITI Galilei Salerno Corso Database ed SQL

ITI Galilei Salerno Corso Database ed SQL ITI Galilei Salerno Corso Database ed SQL prof Carmine Napoli Introduzione Database: Si definisce Database un insieme di dati, di solito di notevoli dimensioni, raccolti, memorizzati ed organizzai in modo

Dettagli

Introduzione Ai Data Bases. Prof. Francesco Accarino IIS Altiero Spinelli Via Leopardi 132 Sesto San giovanni

Introduzione Ai Data Bases. Prof. Francesco Accarino IIS Altiero Spinelli Via Leopardi 132 Sesto San giovanni Introduzione Ai Data Bases Prof. Francesco Accarino IIS Altiero Spinelli Via Leopardi 132 Sesto San giovanni I Limiti Degli Archivi E Il Loro Superamento Le tecniche di gestione delle basi di dati nascono

Dettagli

Sviluppo Applicazioni Mobile Lezione 12 JDBC. Dr. Paolo Casoto, Ph.D - 2012

Sviluppo Applicazioni Mobile Lezione 12 JDBC. Dr. Paolo Casoto, Ph.D - 2012 + Sviluppo Applicazioni Mobile Lezione 12 JDBC + Cosa vediamo nella lezione di oggi Oggi analizzeremo insieme una specifica tecnologia Java per l accesso e la manipolazione di basi di dati relazionali

Dettagli

Abilità Informatiche A.A. 2010/2011 Lezione 9: Query Maschere Report. Facoltà di Lingue e Letterature Straniere

Abilità Informatiche A.A. 2010/2011 Lezione 9: Query Maschere Report. Facoltà di Lingue e Letterature Straniere Abilità Informatiche A.A. 2010/2011 Lezione 9: Query Maschere Report Facoltà di Lingue e Letterature Straniere Le QUERY 2 Che cos è una Query? Una Query rappresenta uno strumento per interrogare un database.

Dettagli