Riassunti Basi di Dati 2 - PDF

RIASSUNTI BASI DI DATI 2: - RDBMS (DBMS RELAZIONALE): Un database relazionale è un tipo di database di archiviazione che fornisce accesso a data points correlati tra loro. I database relazionali sono basati sul modello relazionale, un modo intuitivo e diretto di rappresentare i dati nelle tabelle....

RIASSUNTI BASI DI DATI 2: - RDBMS (DBMS RELAZIONALE): Un database relazionale è un tipo di database di archiviazione che fornisce accesso a data points correlati tra loro. I database relazionali sono basati sul modello relazionale, un modo intuitivo e diretto di rappresentare i dati nelle tabelle. In un database relazionale ogni riga della tabella(tuple) è un record con un ID univoco chiamato chiave. Le colonne della tabella(campi) contengono gli attributi dei dati e ogni record di solito ha un valore per ogni attributo, rendendo facile stabilire le relazioni tra i data points. Ogni colonna ha un data type (int,float,date). Ci sono varie restrizioni sui dati, chiamati vincoli, come: Vincoli di dominio, vincoli chiave, integrità dell’entità, integrità referenziale ecc. I RDBMS utilizzano il linguaggio SQL (Structured Query language), questo linguaggio include istruzioni per la definizione dei dati, per la modifica e per interrogare il DBMS. - OODBMS (OBJECT ORIENTED DBMS): OODBMS è un sistema di gestione di database che rappresenta dati sotto forma di oggetti. Esso è integrato con le capacità di un linguaggio di programmazione orientato agli oggetti, combinandone quindi le funzionalità del database. Il programmatore può quindi utilizzare concetti orientati agli oggetti come: - Incapsulamento: Che può essere pensato come un oggetto che contiene (incapsula) al suo interno attributi (dati) e i metodi (procedure) che accedono ai dati stessi. - Ereditarietà: Permette di definire delle classi a partire da altre già definite. - Polimorfismo: Consente allo stesso codice eseguibile di essere utilizzato con istanze di classi diverse, aventi una superclasse comune. - DIFFERENZA TRA RDBMS E OODBMS: La differenza fondamentale tra RDBMS e OODBMS è che RDBMS è orientato alla tabella mentre OODBMS è orientato agli oggetti, infatti OODBMS gestisce dati più grandi e complessi rispetto a RDBMS, che è più semplice in quanto memorizza i dati nelle tabelle a differenza di OODBMS che causa del coinvolgimento di diversi tipi di dati. Inoltre in OODBMS, le relazioni possono essere rappresentate tramite Object ID (OID) mentre in RDBMS, le relazioni tra le tuple sono specificate da attributi aventi lo stesso dominio. - ORDBMS (OBJECT RELATIONAL DBMS): ORDBMS estende RDBMS con funzionalità orientate agli oggetti. Quando un'applicazione comunica con un ORDBMS, normalmente agirà come se i dati fossero archiviati come oggetti. Quindi ORDBMS convertirà le informazioni dell'oggetto in tabelle di dati con righe e colonne e gestirà i dati così come sono stati memorizzati in un RDBMS. Inoltre, quando i dati vengono recuperati, restituirà un oggetto complesso creato riassemblando i dati semplici. Il più grande vantaggio di ORDBMS è che fornisce metodi per convertire i dati tra il formato RDBMS e il formato OODBMS, in modo che il programmatore non abbia bisogno di scrivere codice per convertire tra i due formati e l'accesso al database sia semplice da un linguaggio orientato agli oggetti. - SISTEMI DISTRIBUITI: Un sistema distribuito è un insieme di computer indipendenti che appaiono agli utenti come se fossero un singolo sistema coerente. Ad esempio più computer, indipendenti tra loro che però devono essere visto a livello utente o da altri sistemi come un singolo sistema, chiamato middleware. Supponiamo di avere 4 computer, dove ogni computer è indipendente e i computer sono connessi tramite una rete. A questo punto, sopra il livello del sistema operativo dei computer, viene creato un unico livello che in pratica si poggia su tutti i computer, questo livello è il middleware. Gli obbiettivi di un sistema distribuito sono: 1) Rendere le risorse disponibili: cioè le risorse dei vari computer che compongono il nostro sistema distribuito che vengono definiti “nodi”, devono essere messi a disposizione degli utilizzatori 2) Distribuzione della trasparenza: Cioè quello che avviene dietro le quinte non deve essere nascosto. 3) Apertura: Il middleware deve essere utilizzabile. 4) Scalabilità - DISTRIBUZIONE DELLA TRASPARENZA: La trasparenza in un sistema distribuito può essere di 7 tipi: 1) Trasparenza di accesso: Si intende il nascondere i dettagli implementativi, cioè come sono rappresentati i dati dietro le quinte, cioè quella capacità di nascondere come sono rappresentati i dati e come sono implementati i servizi sottostanti. 2) Trasparenza di locazione: Capacità di nascondere dove gli oggetti effettivamente risiedono, cioè dove si trovano gli oggetti che compongono il nostro sistema distribuito. 3) Trasparenza di migrazione: Capacità di nascondere lo spostamento di un oggetto. Essendo che il sistema distribuito è composto da più oggetti, uno di questi può essere spostato da un nodo ad un altro, e questo spostamento non deve essere visibile, esempio: Se un oggetto A interagisce con un oggetto B e l’oggetto B viene migrato, l’oggetto A non deve sapere dove si è spostato l’oggetto B. 4) Trasparenza di rilocazione: Simile alla trasparenza di migrazione, ma cambia l’interlocutore cioè è il client che non ha la percezione di dove si trovino gli oggetti nel sistema distribuito, quindi un oggetto viene spostato senza che il client se ne accorga. 5) Trasparenza di replica: Capacità di nascondere la copia di oggetti e dati da un nodo ad un altro. 6) Trasparenza di concorrenza: Capacità di nascondere il fatto che vi siano più utenti e più oggetti che vanno ad utilizzare il middleware, cioè un utente ha la percezione come se fosse l’unico utilizzatore. 7) Trasparenza di tolleranza ai guasti: Capacità di nascondere ad utenti ed oggetti i possibili errori sui componenti cioè sugli oggetti stessi. Se dovesse avvenire un guasto quindi nessuno dovrebbe accorgersene. Non possono essere garantiti tutti i livelli di trasparenza, quindi vengono utilizzati i livelli di trasparenza in base ai requisiti dell’applicazione da sviluppare. - APERTURA DI UN SISTEMA DISTRIBUITO: I componenti di un sistema distribuito, per essere utilizzabile, devono avere: - Interfacce ben definite - Supportare la portabilità delle applicazioni - Devono essere facilmente interoperabili tra di loro Poiché abbiamo a che fare con computer indipendenti, che possono essere anche eterogenei non soltanto dal punto di vista del sistema operativo, ma anche dal punto di vista dell’hardware e dei linguaggi di programmazione; dobbiamo concepire il sistema distribuito in maniera tale da consentire il funzionamento e dunque l’apertura anche quando abbiamo a che fare con nodi eterogenei indipendenti fra di loro. - SCALABILITA’ DI UN SISTEMA DISTRIBUITO: Abbiamo 3 tipi di scalabilità: - Scalabilità di dimensione: Si intende la capacità di aumentare e diminuire in maniera elastica il numero di utenti e di processi all’interno del nostro sistema distribuito - Scalabilità geografica: La capacità di installare i vari componenti del nostro sistema distribuito, quindi i vari nodi, in locazioni geografiche diverse - Scalabilità amministrativa: La capacità di creare diversi domini di sicurezza amministrativa, quindi ad esempio possiamo avere un dominio “root” amministrativo, altre per il sistema distribuito ecc. - PROBLEMA DELLA SCALABILITA’: Supponiamo di avere diverse copie di dati, queste copie portano a una situazione di inconsistenza: in genere la modifica di una copia necessita anche della modifica di tutte le altre copie presenti all’interno del sistema distribuito. Questa operazione di “allineamento” delle varie copie porta a un operazione di sincronizzazione globale, che naturalmente va a limitare le performance di un sistema su larga scala. L’unica soluzione è tenere in considerazione una tolleranza massima di inconsistenza di dati. - TIPI DI SISTEMI DISTRIBUITI: Tutti i sistemi distribuiti devono seguire delle caratteristiche, ovvero le proprietà ACID: - Atomicity(Atomicità): Cioè tutte le operazioni devono essere portate a compimento, oppure nessuna. - Consistency(Consistenza): Cioè una transazione deve portare la base di dati in uno stato valido - Isolation(Isolazione): Ogni transazione deve essere eseguita in maniera isolata dalle altre - Durability(Durabilità): Cioè gli effetti della transazione devono essere permanenti Ci sono diversi tipi di sistemi distribuiti: 1)Sistemi distribuiti computazionali: Si parla di sistemi distribuiti computazionali, quando l’obbiettivo del sistema distribuito è quello di fornire un sistema che offra servizi di High Performance Computing (HPC). Quando si parla di questi, si intende il Cluster Computing, ovvero un gruppo di sistemi interconnessi tra di loro per mezzo di una rete, ad esempio rete LAN, ed i sistemi sono omogenei, cioè con hardware e sistema operativo identico. In genere questo sistema viene gestito da un nodo particolare, detto master, che si comporta come se fosse il coordinatore del sistema distribuito, quindi come singolo nodo di gestione, esso esegue al suo interno un’applicazoine di management, librerie per il calcolo parallelo ed un sistema operativo locale. Abbiamo anche però più compute node, che attraverso il master node, esegue il proprio task per mezzo di un componente dell’operazione parallela. Questi sistemi distribuiti computazionali però possono avere anche dei nodi eterogenei, in questo caso si parla di: Grid Computing: In informatica i grid computing o sistemi grid sono un'infrastruttura di calcolo distribuito, utilizzati per l'elaborazione di grandi quantità di dati, mediante l'uso di una vasta quantità di risorse. In particolare, tali sistemi permettono la condivisione coordinata di risorse all'interno di un'organizzazione virtuale. 2)Sistemi informativi distribuiti: Questo tipo di sistemi distribuiti si dice transazionale perché il suo funzionamento consiste nello svolgere operazioni di lettura e scrittura sulle basi di dati. La distribuzione del sistema può essere gestita in diversi modi, fra i quali troviamo l’utilizzo del Transaction Processing Monitor, il quale si occupa di inoltrare le richieste dai vari client ai vari server (connessi ai database), e viceversa di rispedire ai vari mittenti le risposte ricevute dai server (una sorta di gateway). 3)Sistemi distribuiti pervasivi: Sono dei sistemi i cui nodi sono piccoli, mobili, con connessioni di rete wireless. Esempi di sistemi distribuiti pervasivi sono, i sistemi domestici, i sistemi elettronici per l’assistenza sanitaria o le reti di sensori wireless. I requisiti di questo sistema sono: - Il cambio di contesto: Cioè che il sistema fa parte di un ambiente che può cambiare da un momento all’altro, e quando cambia il sistema distribuito deve riadattarsi al cambio di contesto - Composizione ad hoc: Ogni nodo verrà configurato e si comporterà diversamente in base agli utenti che utilizzano il sistema - Condivisione per default: Cioè i nodi possono entrare o uscire dal sistema, condividere informazioni in maniera semplice. - PROBLEMI DELLE BASI DI DATI DISTRIBUITE: - Autonomia e cooperazione: Cioè l’esigenza di autonomia, ovvero portare competenze e controllo dove vengono gestiti i dati e l’esigenza di cooperazione ovvero che alcune applicazoini richiedono l’accesso a più basi di dati. - Trasparenza - Efficienza - Affidabilità - STILI ARCHITETTURALI: Con i sistemi non abbiamo più un sistema client-server, ma abbiamo in realtà un sistema costituito da più oggetti che possono essere distribuiti su diversi computer fisici differenti nel quale ogni oggetto interagisce con altri oggetti per mezzo di chiamate a metodi (es. web services, chiamate a procedura remota, e così via). - MODELLO CLASSICO CLIENT-SERVER: In modello di questo tipo abbiamo dei client che effettuano richieste e dei server che rimangono in ascolto di queste richieste che le processano e trasmettono una risposta. La cosa fondamentale da capire è che la risposta non è immediata per motivi legati alle reti inaffidabili. Infatti, dobbiamo considerare oltre al tempo di processamento, anche i tempi di trasmissione. Quindi dovremo capire se i ritardi sono dovuti alla latenza di invio della richiesta, al tempo di processamento o alla latenza di invio della risposta. - APPLICATION LAYERING: In genere, un sistema “tradizionale” si basa su un’architettura a tre livelli: - Al livello più c’è il livello database; - Un livello intermedio di processamento; - Il livello di interfaccia utente; È possibile però distribuire in maniera differente questi tre livelli sulla macchina client e sulla macchine server. - ARCHITETTURE DECENTRALIZZATE: Un esempio che utilizza l’architettura decentralizzata lo vediamo nei sistemi peer-to-peer (P2P). In questi sistemi non abbiamo il concetto di nodo client o di nodo server, in quanto ogni nodo può fungere sia da client che da server. Inoltre, tra i sistemi P2P distinguiamo reti: - Structured P2P - Unstructured P2P - Hybrid P2P - FRAMMENTAZIONE DEI DATI: Per frammentazione dei dati, si intende quel meccanismo di scomposizione delle tabelle, in modo da consentire la loro distribuzione. Una volta che i dati sono distribuiti, devono garantire due proprietà: 1) Completezza 2) Ricostruibilità Questo significa che, anche se io vado a distribuire i miei dati su vari server o database distribuiti, l’insieme dei dati distribuiti deve essere completo, allo stesso modo nel quale lo sarebbe considerando tutti i dati memorizzati in un singolo server, e le informazioni devono essere ricostruibili, anche recuperando i vari frammenti dai database nel caso sia frammentata in più database. Ci sono 2 tipi di frammentazione: 1) Frammentazione orizzontale: Dove abbiamo vari frammenti rappresentati tramite insieme di tuple. Ovvero, prendiamo il database, lo dividiamo in sottoinsiemi di tuple ed assegnamo ogni tupla ad un server diverso. Ad esempio, il primo frammento è rappresentato dai primi mille record, il secondo dal milleunesimo al duemilesimo e il terzo dal duemilesimo al tremillesimo. In questo caso la completezza è data dalla presenza di tutte le tuple, mentre la ricostruzione è data dall’unione. 2) Frammentazione verticale: In questo caso abbiamo dei frammenti che sono insieme di attributi, cioè la tabella viene frammentata in sottoinsieme di colonne. Ad esempio, le colonne 1-2-3 vengono messe in un database, le 4-5-6 in un altro database e le colonne 7-8-9 in un altro database. La completezza in questo caso viene data dalla presenza di tutti gli attributi, mentre la ricostruzione viene fatta per mezzo di un operazione di join sulla chiave. - LIVELLI DI TRASPARENZA: I livelli di trasparenza riguardano, la frammentazione,l’allocazione ed il linguaggio. - Trasparenza di frammentazione: Si intende che il programmatore non si deve preoccupare del fatto che la base di dati sia o meno distribuita e frammentata. - Trasparenza di allocazione: Il programmatore conosce la struttura dei frammenti, ma non deve indicarne l’allocazione. - Trasparenza di linguaggio: Il programmatore deve indicare nalla sua interrogazione, sia la struttura dei frammenti, sia la loro allocazione. - EFFICIENZA: Una query può essere seguita all’interno di un database distribuito, seguendo 2 modalità di esecuzione: 1) Seriale: Fa sì che noi abbiamo un client che accede ad un database che chiameremo filiale, cioè se la query viene eseguita in modo seriale, accedendo ad esempio a conto1, accederà in maniera sequenziale a conto2 e conto3 2) Parallela: Consideriamo un client collegato in rete simultaneamente con 3 database, ad esempio filiale1, filiale2 e filiale3,il client in questo caso andrà ad effettuare delle query in parallelo sui 3 database distribuiti dalle 3 filiali. - TIPI DI TRANSAZIONI: - Richieste remote: Transazioni di sola lettura, indirizzate ad un solo DBMS remoto - Transazioni remote: Transazioni costituite da numero qualsiasi di comandi SQL dirette ad un solo DBMS remoto - Transazioni distribuite: Transazioni dirette ad un numero generico di DBMS, in cui ciascun comando SQL fa riferimento a dati memorizzati su un solo DBMS. - Richieste distribuite: Transazioni costituite da un numero arbitrario di comandi SQL. Ciascun comando SQL può far riferimento a dati distribuiti su qualsiasi DBMS - METODO DI LAMPORT: Per essere sicuri che una transazione distribuita, eseguita in parallelo, sia stata portata a termine in maniera corretta, si utilizza il Metodo di Lamport, che consiste nell’assegnazione dei timestamp. Essi vengono utilizzati per tracciare i cambiamenti di un record, cioè per tracciare si intende quando è avvenuto il cambiamento, quindi quando dei record subiscono frequenti variazioni. In poche parole quando i record di una determinata tabella subiscono una modifica, il campo di tipo timestamp si aggiorna in automatico. Ogni timestamp, è formato da due gruppi di cifre: 1) Le meno significative identificano un nodo 2) Le più significative identificano gli eventi su ciascun nodo Ogni volta che due nodi comunicano, scambiandosi un messaggio, i loro timestamp si sincronizzano. L’evento ricezione deve avere un timestamp successivo a quello dell’evento di invio. - RICONOSCIMENTO DISTRIBUITO DEL DEADLOCK: Con un database distribuito, non ci basta soltanto gestire il timestamp, in quanto abbiamo delle transazioni che possono generare delle situazioni di blocco. Immaginiamo di avere un modello di database distribuito in cui le transazioni vengono suddivise in sotto transazioni. Se abbiamo diverse sotto transazioni, ad esempio sottotransazione1 e sottotransazione2, se il nodo1, attende il risultato della sottotransazione1 ed il nodo2, attende il risultato della sottotransazione2 che però attende 1, si verifica una situazione di deadlock, cioè di loop ciclico, ovvero di attesa circolare tra nodi. La soluzione potrebbe essere l’utilizzo di timeout o algoritmi che interrompono il ciclo di attesa. - ALGORITMO DI OBERMARK: Uno degli algoritmi che serve per interrompere il ciclo di attesa, è l’algoritmo di obermark, esso viene eseguito da ogni nodo e prevede 4 fasi: 1) Ogni nodo riceve le condizioni di attesa dai nodi precedenti 2) Le integra con il grafo di attesa locale 3) Se rileva un ciclo, lo spezza uciddendo una sottotransazione 4) Crea le nuove condizioni di attesa e le invia al nodo successivo L’obiettivo secondario è invece quello di rilevare ogni ciclo una sola volta. Esso si ottiene definendo un ordine tra i nodi, cioè individuando nodi precedenti e successivi. - PROPRIETA’ ACIDE DELL’ESECUZIONE DISTRIBUITA: - Isolamento: Se ciascuna sottotransazione è a due fasi la transazione è globalmente serializzabile - Persistenza: Se ciascuna sottotransazione gestisce correttamente i log, i dati sono globalmente persistenti - Consistenza: Se ciascuna sottotransazione preserva l’integrità locale, i dati sono globalmente consistenti - Atomicità: E’ il principale problema delle transazioni distribuite - PROTOCOLLI DI COMMIT: Il commit è quell’operazione che ci consente di rendere effettive delle modifiche all’interno della base di dati. - PROTOCOLLO DI COMMIT A DUE FASI: Serve a convalidare una transazione. I protagonisti di questo protocollo sono: Un coordinatore (Transaction Manager, TM) e Molti partecipanti (Resource Manager, RM) Il protocollo di commit a due fasi, si svolge per mezzo di un rapido scambio di informazioni tra Transaction Manager TM e Resource Manager RM. Per rendere il protocollo resistente ai guasti, sia TM che RM arricchiscono di alcuni nuovi record i loro file di log. Per quanto riguarda il TM: Il TM scrive: - Un record di prepare con l’identità dei processi riguardanti RM, questa verrà fatta considerando gli identificativi dei vari nodi e dei processi che andranno a partecipare all’esecuzione della transazione distribuita. - Dopodiché il TM, andrà a scrivere nel proprio log un record di global commit o global abort, e facendo così determina l’esito finale della transazione. Nel momento in cui questo global viene scritto, abbiamo un altro record, chiamato record di complete, che riassume l’esito del protocollo di commit a due fasi. Per quanto riguarda l’RM, esso rappresenta una sotto-transazione e scrive i record di: begin, insert, delete, update. La partecipazione al protocollo di commit a due fasi, si caratterizza per la presenza di: - Record di ready: Cioè la disponibilità a partecipare al protocollo di commit a due fasi. In tal record, è riportato anche l’identificatore (nodo e processo) del TM. - SUPPONIAMO DI AVERE UN PROTOCOLLO IN ASSENZA DI GUASTI (COMMIT 2 FASI ASSENZA GUASTI): In questo caso il protocollo consiste in una sequenza di scritture sul log e scambi di messaggi tra TM e RM. TM può usare sia meccanismi di broadcast per comunicare con diversi RM che meccaniscmi di comunicazione seriale. Deve essere inoltre ing rado di collezionare risposte proveninenti da vari nodi. Il protocollo si articola in 2 fasi: 1) Il TM scrive il record di prepare ed invia un messaggio di prepare per informare dell’inizio del protocollo a tutti gli altri RM. Quindi in caso di ritardo, ad esempio se un RM non risponda in tempo entro un timeout, il TM abortirà la transizione. Gli RM che sono in uno stato affidabile, attendono il messaggio di prepare e non appena ricevono il messaggio, scivono il record di ready e mandano il messaggio di ready al TM. Il TM colleziona i messaggi di risposta ed andrà a scrivere nel proprio sistema di log, un record di global commit, in caso contrario un record di global abort. 2) Il TM invierà la sua decisione globale (cioè global commit o global abort) ed imposterà un timeout per la ricezione dei messaggi di riposta dagli RM. A questo punto i RM che sono pronti per eseguire la propria sotto-transazione, appena riceveranno il global commit, scrivono il record di commit o abort e mandano il messaggio di acknowledgement al TM, cioè che la propria transazione è stata eseguita localmente. Il TM colleziona i messaggi di acknowledgement, se tutti i messaggi arrivano allora sarà sicuro che la transazione è stata eseguita correttamente e lo scriverà nel suo sistema di log per mezzo di un record di complete. - PROTOCOLLO DI COMMIT A TRE FASI: Viene introdotta una terza fase, nella quale ogni partecipante RM può diventare un TM. Il partecipante che verrà eletto come TM, guarderà il suo log: - Se l’ultimo record è ready, può imporre un global abort - Se l’ultimo record è pre-commit può imporre un global commit Il difetto di questo protocollo è che può essere scorretto in partizioni di rete. Dopo che l’RM registra sul log uno stato di ready, il TM che dispone di una risposta positiva da tutti gli RM, registra uno stato di pre-commit. Quindi possiamo dire che questa terza fase, consiste in una scrittura di un pre-commit sia da parte dell’RM che del TM. - PROTOCOLLO DI COMMIT A QUATTRO FASI: L’idea di base è che il processo TM, viene replicato tramite un processo di backup collocato su un nodo differente. Il TM informa il backup delle sue decisioni prima di comunicarle agli RM. Se il TM ha un guasto, il backup può intervenire: - Come prima cosa andrà ad attivare un altro backup, per una condizione di continuità - Successivamente continua l’esecuzione del protocollo di commit - BASI DI DATI REPLICATE – REPLICAZIONE DEI DATI: La replicazione è un aspetto fondamentale nei sistemi informativi, in quando consente di poter risolvere delle problematiche legate ad eventuali guasti, ma anche per ovviare a delle problematiche dovute a degli attacchi in rete. Le motivazioni riguardano: - L’efficienza - L’affidabilità - L’autonomia Se un nodo dovesse cadere, in maniera autonoma, grazie ai meccanismi di replicazione, si può essere in grado di andare a ripristinare la base di dati in uno stato consistente. Le modalità di replicazione possono essere: - Simmetriche: Consideriamo una copia primaria ed una copia secondaria del nostro database. Una volta che le modifiche avvengono sulla copia primaria, queste vengono propagate verso una copia secondaria - Asimmetriche: Consideriamo sempre una copa primaria ed una copia secondaria del nostro database. Le modifiche nella copia primaria vengono propagate nella copia secondaria e quelle che vengono effettuate nella copia secondaria vengono propagate nella copia primaria. - MODALITA’ DI TRASMISSIONE DELLE VARIAZIONI: - Trasmissione asincrona: Consideriamo una transazione master (principale) effettuata sulla copia principale, a questo punto abbiamo una transazione di allineamento, che consente una propagazione delle modifiche effettuate sulla copia principale all’interno della copia secondaria. - Trasmissione sincrona: Una volta che andiamo ad effettuare una scrittura direttamente sulla copia principale, quest’operazione verrà automaticamente anche scritta nella copia secondaria, quindi la transazione master è unica. - MODALITA’ DI ALLINEAMENTO: L’allineamento detto anche refresh, esso può definire l’intero contenuto della copia principale, oppure può essere fatto in altre modalità che consentono di risparmiare tempo e dati. L’allineamento può essere: - Periodico: Cioè svolto ad intervalli di tempo prestabiliti - A comando: Cioè impostato in modalità manuale da un processo o amministratore - Ad accumulo di variazione: Che è la tecnica più efficiente, e serve a propagare nell’altra copia solo le modifiche sono state fatte su una copia e non tutto il database. - MECCANISMI DI REPLICAZIONE: Si può avere a che fare con un sistema intermedio che si occupa di gestire le repliche. Questo viene implementato da varie soluzioni software come dal Replication manager. Esso è un componente software che si trova tra le sue copie e che comprende il mondo software di capture che catturerà le modifiche che vengono effettuate sulla copia principale, verranno scritte su un database che prende il nome di delta-plus, ed una volta che queste vengono inserite, verranno propagate per mezzo di un secondo nodo che prende il nome di apply che andrà ad eseguire le transazioni di sincronizzazione ed allineamento sulla copia secondaria. - CLOUD COMPUTING: Il Cloud Computing è una tecnologia informatica che consente di sfruttare la rete internet per distribuire risorse software e hardware da remoto. Il servizio di Cloud Computing viene offerto da apposite aziende definite Cloud provider. I servizi di Cloud Computing si distinguno in tre principali modelli: - Infrastructure as a Service (IAAS): Dove abbiamo diversi server fisici, interconnessi in rete tra di loro, ed all’interno di ognuno di loro, noi andiamo ad installare un software per la virtualizzazione. Per gestire un’intera infrastruttura cloud di tipo IAAS, abbiamo il VIM (virtual machine monitor), che è in grado di gestire svariati server, e grazie a questo software, noi riusciamo a creare il primo strato di gestione del cloud. Un IAAS si sviluppa quindi per mezzo di un VIM e fornisce macchine virtuali sfruttando la virtualizzazione che può essere basata su hypervisor o container. In poche parole è una macchina virtuale con infrastruttura che va gestita dal client. Esempio di provider: Amazon e Rockspace. - Platform as a Service (PAAS): E’ un servizio di cloud computing in cui l’hardware e la piattaforma software vengono forniti da terze parti. Esso offre una piattaforma su cui l’utente può sviluppare, eseguire e gestire applicazioni in modo semplice, cioè tramite una serie di software pre-installati. Fornisce i meccanismi che consentono di gestire il ciclo di vita, lo sviluppo e l’installazione di applicazioni web e servizi disponibili attraverso internet. Esempio: Microsoft Azure, Facebook. - Software as a Service (SAAS): E’ un servizio di cloud computing in cui un produttore di software sviluppa, opera e gestisce un’applicazione web, mettendola a disposizione dei propri clienti. Cioè consente agli utenti di connettersi ad app basate su cloud tramite internet ed usare tali app. Un SaaS dovrebbe essere usato solo per mezzo di un browser web, cioè non è richiesto alcun software aggiuntivo sul PC utilizzato per eseguire l'accesso. Un SaaS può essere installato in un particolare ambiente (ad esempio, le applicazioni di Facebook possono essere installate sulla piattaforma facebook, google l'applicazione può essere installata nella piattaforma google). Esempio: Office 365 che sarebbe office ma online, oppure Google Doc. Il cloud ci consente di creare servizi di: - Hosting - Storage - Platform - Development (Servizi per lo sviluppo di app) - Application (Applicazioni SaaS) - Services Tramite il cloud, possiamo creare quindi i nostri servizi in maniera veloce ed abbattendo i costi. Ognuno di noi ad esempio può creare il backend di un’app per smartphone su una o più macchine virtuali sul cloud, può gestire gli utenti tramite interfaccia web installata su macchina virtuale e può monitorare le attività del client. Le caratteristiche base del cloud sono: - No need to know: Cioè che gli sviluppatori non hanno bisogno di sapere cosa sta dietro ai servizi cloud, a loro basta conoscere l’API per poter accedere a questi servizi - Flessibilità ed elasticità: Cioè la possibilità di poter ridimensionare il carico computazionale, quindi la CPU, lo storage, la capacità del server in generale, il bilanciamento del carico ed il database - Pay as you go – Paga in base a ciò che utilizzi o che hai bisogno - Trasparenza - MODELLI DI DEPLOYMENT CLOUD: Abbiamo 4 modelli fondamentali che sono: - Cloud pubblica: Noi andiamo a fornire dei servizi liberamente accessibili da qualsiasi utente connesso attraverso internet. - Cloud privata: Cloud con accesso ristretto ad un determinato numero di utenti. In genere si sviluppano a livello aziendale. - Cloud ibrida: Abbiamo una cloud privata aziendale che sviluppa servizi per i propri utenti ma è integrata anche con servizi di cloud pubblici. - Cloud federata: In cui cloud pubblico o privato, stabiliscono un accordo di cooperazione, al fine di poter condividere un determinato pool delle loro risorse, in modo che ogni cloud può contare sulle risorse della federazione in base all’esigenza. BENEFICI DEL CLOUD E CLIENT: Consente alle aziende di poter creare i propri servizi senza l’utilizzo di infrastrutture fisiche, a basso costo ed in poco tempo. Si paga in base ai servizi che si utilizzano, senza dover spendere capitali per investire. SVANTAGGI DEL CLOUD: Sicurezza dei dati dovuta alla rete non affidabile. - BASI DI DATI PARALLELE: Consideriamo 3 concetti fondamentali: 1) Carico: Insieme di tutte le applicazioni (query). Esso può essere: - Transazionale: In cui il carico viene rappresentato da transazioni brevi (tps – transazioni per secondo) ed il tempo di risposta è di pochi secondi - Analisi dei dati: In cui il carico è una query SQL complessa ed il tempo di risposta: variabile 2) Scalabilità: Abilità di garantire le stesse prestazioni elevate al crescere del carico 3) Dimensioni di crescita: Che possono riguardare il numero delle query o la complessità delle query - PARALLELISMO: Nel parallelismo andiamo a sfruttare più processori che cooperano tra di loro in un’unica architettura informatica. Esso nei database è di 2 tipi: - Inter-query: Ciascuna query affidata ad un solo processore - Intra-query: Ciascuna query è affidata a molti processori - BENCHMARK: Comprende dei metodi per confrontare le prestazioni di sistemi diversi in competizione tra di loro. Quindi va a considerare una fase di standardizzazione, all’interno della quale si definiscono quali sono le regole e le procedure da seguire per la nostra analisi di confronto prestazionale. Questa fase riguarda: - I database che vogliamo confrontare - Il carico(transazioni, modalità di invio e/o la frequenza d’arrivo delle query) - La modalità di misurazione. - CURVE DA PRENDERE IN CONSIDERAZIONE DURANTE UN ANALISI DI BENCHMARK: CURVA DI SPEED-UP: Serve per misurare il crescere dell’efficienza al crescere del numero di processori di un sistema basato su database. Andremo a considerare come unità di misura il Tps = Transaction Processing per Second. Con questa curva misuriamo come migliorano il numero delle transazioni che si possono eseguire per ogni secondo, all’aumentare del numero dei processori. CURVA DI SCALE-UP: Misura il crescere di costo unitario complessivo per transazione al crescere del numero di processori. - APACHE HADOOP: E’ una delle prime architetture distribuite diffuse su cloud. E’ un framework che supporta applicazioni distribuite con elevato accesso ai dati, permettendo alle applicazioni di lavorare con migliaia di nodi. Esso realizza un ambiente che consente di sfruttare architetture cloud. Comprende: - Hadoop Distributed File System (HDFS) - File Syste distribuito in Java: con un nodo principale chiamato NameNode che controlla lo stato dei nodi e la ridondanza dei dati. - Hadoop MapReduce: Dove i lavori sono gestiti da un processo detto job tracker allocato sul nodo principale. Il job tracker assegna unitò di lavoro (task) a diversi processi (task tracker). L’ambiente schedula i task, alloca i task ai nodi, controlla laterminazione e rischedula in caso di guasto.- Job MapReduce: Un job Mapreduce divide i dati in ingresso in pacchetti indipendenti, gestiti da task di tipo Map. L’output dei task Map viene fornito come input a task di tipo Reduce. Il formato dei dati è costituito da coppie chiave-valore. - BIG DATA: I Big Data sono descritti come delle grosse mole di dati che si differenziano per tipo e per finalità, essi sono in continuo cambiamento, infatti non possono essere più processati usando le tradizionali tecniche di analisi come ad esempio i database strutturati, così da necessitare di strumenti adeguati e diversi dai traduzionali. Diciamo che la “sfida” dei Big Data è quella di poter convertire la maggior parte dei dati in informazioni usabili. Essi sono eterogenei e possono venire da diverse fonti come: cloud,social network ecc. Le caratteristiche che devono avere i Big Data sono 3: - Volume: Si intende una grossa mole di dati generabili da record, transazioni, tabelle, file, ecc. - Velocità: Cioè dati generati costantemente con una frequenza abbastanza elevata. Questi possono essere generati ad esempio da sistemi di streaming (stream-data), oppure dati che necessitano di essere processati considerando anche dei dati near-time (quasi in tempo reale), o grossi dati che vengono generati che però deve essere gestita con processi Batch, cioè che questi dati possono essere accumulati, immagazzinati e processati continuamente in modo da effettuare operazioni di predizione o operazioni che ci permettono di capire l’andamento di quel tipo di dato. - Varietà: Cioè dati che possono essere di varia natura. E’ stata considerata però un’altra caratteristica dai parte degli “addetti ai lavori”, ovvero la: - Veridicità: Che misura il potenziale informativo del dato e la sua integrità, cioè la sua qualità al fine di essere analizzato. - DIFFERENZA TRA SMALL DATA E BIG DATA: - Small Data: Sono dei dati che hanno un basso volume, che hanno velocità a livello batch e sono di tipo strutturato. Non sono capaci di gestire degli streaming data, cioè dati in real time. - Big Data: Riguardano l’ordine di volume di terabyte e petabyte, hanno una velocità in tempo reale e possono essere di tipo multistrutturato, nel senso che possono comprendere sia tipi di dati strutturati, semistrutturati e non strutturati. - TECNOLOGIE BASATE SUI BIG DATA: Gli ambiti di utilizzo dei Big Data sono diversi: 1) Crowd sourcing: Cioè dati provenienti da diverse sorgenti che vanno a ridondare di dati il nostro DBMS 2) Data fusion: Cioè applicazioni che vanno a fondere i dati per poter estrarre conoscenza 3) Data integration: Cioè dati che mantengono le loro strutture originali ma vengono correlati tra di loro 4) Machine learning: Intelligenza artificiale 5) Simulation: Simulazione 6) Natural language processing: Processamento del linguaggio naturale, ad esempio i sistemi basati su machine learning che vanno ad analizzare i post di un social network, ad esempio su facebook. - FASI FONDAMENTALI DEI BIG DATA: Abbiamo 4 fasi fondamentali: 1) Deposito dei dati: Si intende l’operazione di memorizzazione dei Big Data. Essi devono essere memorizzati sfruttando le soluzioni di dbms paralleli distribuite, in genere NoSQL 2) Scoperta: Una volta che i dati sono stati archiviati, un’applicazione che deve andare ad analizzare questi Big Data, li deve andare a cercare, facendo appunto un opearzione di scoperta del dato che gli interessa. 3) Design: Una volta che il dato va scoperto, si passa ad una fase di design, cioè di progettazione, che ci consente di integrare questi dati, al fine di uniformare il nostro Data Model (Data Set) 4) Decisione: Dall’analisi fatta ai Big Data, si va a definire quale sarà l’azione da intraprendere in seguito all’analisi dei dati. - TIPI DI BIG DATA: I Big Data possono essere formati da dati: - Strutturati: Cioè dati con campi fissi che vengono progettati per mezzo di sistemi di tipo SQL. - Semistrutturati: Derivano da sistemi basati ad esempio su XML, quindi database XML perché esso ci consente di andare a definire una porzione del data model che deve rispettare determinate regole. - Non strutturati: Cioè i tipi di dati che non devono rispettare nessuna regola, quindi possono essere memorizzati come arrivano. - ARCHITETTURA A 3 LIVELLI - NETFLIX: E’ un’architettura che utilizza diversi DBMS in base alle funzionalità, quindi si va a sviluppare il sistema, seguendo alcune linee guida architetturali e si vanno a considerare le soluzioni DBMS che meglio vanno a risolvere una determinata funzionalità. In poche parole vengono assegnati carichi di lavoro e tasks a sistemi che lavorano ed emettono risultati a latenze diverse. In questa architettura a 3 livelli, abbiamo: - Livello Online (Online Processing): Gestisce tutti quei dati che devono essere elaborati in breve tempo, quindi si occupa della ricezione dei dati in real time. La caratteristica fondamentale di questo livello è quella della velocità di elaborazione ed emissione, infatti gestisce dati non molto grandi. - Livello Nearline (Nearline Processing): Gestisce delle informazioni in un tempo non proprio immediato ma con una certa urgenza. - Livello Offline (Offline Processing): Gestisce i batch data, cioè delle grosse moli di dati che vengono processati per mezzo di alcuni processi che necessitano di ore e di giorni, e consentono di estrapolare conoscenza dal dato. - ARCHITETTURA LAMBDA: Questo tipo di architettura è stata pensata soprattutto per poter gestire i livelli real-time e offline. Questa architettura si compone di 3 livelli/componenti che sono: - Speed Layer: Che equivale al livello online dell’architettura a 3 livelli. Qui abbiamo uno stream processing, dove arrivano i dati, che vengono poi elaborati dal RealTime view. Qui le liste real-time vengono create internamente. - Batch Layer: Che equivale al livello offline dell’architettura a 3 livelli. Qui si va a memorizzare lo storico di tutti i dati che possono arrivare dai nostri canali di stream-data. All’interno di questo livello abbiamo un componente che ci pre-processa le liste, cioè il Precompute views che estrapola i dati, composto da più batch view che creano queste liste (si trovano le serving layer perché abbiamo a che fare con i big data). - Serving Layer: Che ha funzionalità di poter rappresentare i dati all’utente finale o ci consente di creare delle liste sui nostri dati, attraverso le batch view. Esso mira a soddisfare le esigenze di un sistema robusto che sia fault-tolerant (è la capacità di un sistema di non subire interruzioni di servizio anche in presenza di guasti) e che sia in grado di gestire una vasta gamma di carichi di lavoro. I principi alla base dell’Architettura Lambda sono 3: 1) Human fault-tolerance: Cioè il sistema non deve essere soggetto a perdite o corruzione di dati dovuti a errori umani o a guasti hardware. 2) Data immutability: Cioè i dati vengono immagazzinati nella loro totalità ma soprattutto nella loro forma iniziale e grezza, e conservati indefinitamente. 3) Recomputation: Cioè a causa al sistema fault-tolerance e all’immutabilità dei dati, deve essere sempre possibile rielaborare i risultati di un precedente calcolo eseguendo delle query sui dati raw salvati nello storage. - NOSQL: Con il termine NoSQL si intende Not Only SQL, cioè “Non solo SQL”, quindi si intende l’insieme di tutte le soluzioni SQL ma anche non SQL, che possono essere utilizzate all’interno di un sistema, o in maniera integrata o in maniera indipendente. L’obbiettivo dei database NoSQL è quello di andare a gestire i BigData. I database NoSQL sono appositamente realizzati per modelli di dati specifici e hanno schemi flessibili per creare applicazioni moderne. I database NoSQL sono una soluzione ideale per molte applicazioni moderne, quali dispositivi mobili, Web e videogiochi che richiedono database con: - Flessibilità: I database NoSQL offrono generalmente schemi flessibili che consentono uno sviluppo più veloce e iterativo. Il modello di dati flessibile fa dei database NoSQL la soluzione ideale per i dati semi- strutturati e non strutturati. - Scalabilità: I database NoSQL possono offrire vantaggi operativi e risparmi straordinari grazie alla possibilità di aumentare le prestazioni o di aggiungere server meno costosi senza richiedere l'aggiornamento. - Elevate prestazioni: I database NoSQL sono ottimizzati per modelli di dati specifici e schemi di accesso che consentono prestazioni più elevate rispetto ai risultati che si ottengono cercando di raggiungere una funzionalità simile con i database relazionali. - Altamente funzionali: I database NoSQL offrono API altamente funzionali e tipi di dati che sono dedicati a ciascuno dei rispettivi modelli di dati. - TEOREMA CAP: Il Teorema CAP, sta per Consitenza, Availabilty(Disponibilità) e Partizionamento dei dati, cioè totale consistenza, continua disponibilità e tolleranza alle partizioni. Esso afferma che è impossibile per un sistema informatico distribuito, fornire simultaneamente tutte e 3 le garanzie, ovvero completa coerenza dei dati, continua disponibilità e tolleranza alle partizioni, quindi è necessario stabilire, di volta in volta, in funzione ai requisiti, quali di queste 3 garanzie sacrificare. - CATEGORIE DI DATABASE NOSQL: - Key-Value Stores: Sono database che memorizzano i dati sottoforma di coppia chiave-valore e di conseguenza può memorizzare una grande mole di dati, che tuttavia non sono complessi poiché non contengono relazioni - Column NoSQL databases: Riesce a gestire un numero elevato di dati. Sono presenti strutture più complesse poiché abbiamo delle famiglie di coppie chiave-valore che possono essere articolate per creare data model semi-strutturati o non strutturati - Document-based: Anche loro utilizzano coppie chiave-valore, però il valore è rappresentato da un vero e proprio documento. E’ possibile annidare documenti all’interno di altri documenti - Graph database (neo4j, infogrid): Riescono a gestire delle basi di dati con relazioni molto complesse. I dati che riesce a gestire sono più bassi rispetto agli altri tipi di database, tuttavia vi sono dei vantaggi nella gestione di dati complessi. Questi tipi di database riescono a gestire i grafi e in generale si prestano molto per le applicazioni di machine learning per via dell’analisi dei dati che avviene direttamente a livello di DBMS. - SQL VS NOSQL: - Caratteristiche di SQL: Il linguaggio fondamentale usato per impartire comandi ad un DBMS relazionale è SQL ed una delle operazioni più comuni nonché più onerose in termini di risorse è il cosiddetto JOIN, un incrocio di tabelle in relazione tra loro che permette di offrire un set di dati unico con le informazioni complete. Alla base di un database relazionale, c’è la progettazione della struttura interna, fatta di tabelle e relazioni. Questo lavoro concettuale iniziale condizionerà lo svolgimento di ogni operazione sui DB, dall’inserimento dei dati all’interrogazione, alla definizione dei JOIN. - Caratteristiche di NoSQL: La strutturazione rigida dei contenuti, tipica dei database relazionali fin qui descritti, è un elemento assente nei database NoSQL, e proprio tale assenza è uno degli aspetti che maggiormente ne hanno permesso il successo. Le informazioni non troveranno più posto in righe elencate in tabelle, ma in oggetti completamente diversi e non necessariamente strutturati, come ad esempio documenti archiviati in collezioni. Su MongoDB, un database NoSQL basato sui documenti, il formato del documento è una delle caratteristiche più rilevanti. Si tratta di BSON (Binary JSON), una variante di JSON che include diversi tipi di dati. - BASI DI DATI PER XML: E’ un formato utile per distribuire documenti elettronici su Web, ad esempio: libri, manuali, cataloghi di prodotti ecc. Esso è un meta-linguaggio(cioè un linguaggio per descrivere altri linguaggi, ovvero una serie di regole sintattiche che consentono di descrivere le regole sintattiche di una certa categoria di linguaggi) per la specifica di linguaggi di markup. Come in HTML, i dati in XML, sono dei documenti dove le proprietà dei dati sono espresse mediante marcatura del contenuto. Come nelle basi di dati, anche in XML esiste un modello di dati, definito per mezzo di DTD e XSD ed esistono linguaggi di query e trasformazione. Perciò possiamo dire che XML è un linguaggio flessibile che può essere utilizzato sia per scopi applicativi sul web, ma anche per poter gestire i database. XML lo utilizziamo per separare la descrizione dei dati, per scambiare dati tra sistemi eterogenei e per condividere e memorizzare dati. - SINTASSI XML: La prima istruzione identifica il tipo di documento e serve ai programmi per poter capire come interpretare il documento stesso. Ogni dato all’interno di un documento XML, viene definito elemento. Un elemento è delimitato da un tag di apertura ed uno di chiusura. I nomi dei tag sono case sensitive, con in più il prefisso / prima del nome del tag stesso. In XML possiamo anche avere degli elementi che hanno un solo tag (ad esempio ). Ogni elemento deve avere un elemento radice che racchiude l’intero contenuto. Esempio di elementi e attributi: Prova 500  valuta = “USD” rappresenta l’attributo Gli attributi sono delle proprietà con valori di tipo stringa che devono essere racchiusi tra apici, e differiscono dagli elementi perché non possono contenere elementi figli. - XML NAMESPACE: E’ una collezione di nomi (attributi, elementi) identificata da un URI (Uniform Resource Identifier). Essi servono per evitare i conflitti di nomi, ovvero si aggiunge un prefisso, ad esempio, per distinguere due attributi , utilizziamo: e - DOCUMENT TYPE DEFINITION (DTD): Esso detta il tipo di un documento, cioè definisce quali devono essere i tag ammessi e le regole di collocamento dei tag. L’obbiettivo è quello di definire una regola per quanto riguarda il formato e la struttura dei documenti. Esempio di file.dtd: Questo esempio ci dice che abbiamo una lista di siti che devono contenere al suo interno il nome e l’url. Adesso nel file.xml dobbiamo inserire il documento.dtd: provacreate or replace TYPE ADDRESS AS OBJECT(STREET VARCHAR2(40), CITY VARCHAR2(40), STATE VARCHAR2(40), ZIP NUMBER); - TRIGGER: Un trigger è una procedura, cioè un sottoprogramma che viene richiamato al verificarsi di un evento associato ad una tabella. Possiamo avere ad esempio un evento di inserimento, o cancellazione. Questi sono utilizzati per: - Motivi di sicurezza - Per imporre una integrità referenziale complessa - Per prevenire/bloccare transazioni non valide - Per gestire il log degli eventi Ad esempio, non appena viene scritto un record nella tabella EMP, scrivi su un’altra tabella, ad esempio la tabella LOG, le informazioni relative a quale utente ha effettuato l’inserimento e quando. Esempio: CREATE OR REPLACE TRIGGER del_emp(p_empno emp.empno%TYPE) BEFORE DELETE ON emp FOR EACH ROW BEGIN INSERT INTO emp_audit VALUES(p_empno, USER, sysdate); END; / - Esercizio 1 – Archiviazione Barche: Trigger che va in esecuzione quando va cancellata una tupla dalla tabella barche e aggiunge la tupla eliminata alla tabella ex_barche. Innanzitutto è necessario creare la tabella ex_barche con lo stesso schema della relazione della tabella barche. Definiamo la funzione che il trigger richiamerà durante la sua esecuzione: CREATE OR REPLACE FUNCTION archivia_barca() RETURNS trigger AS $archivia_barca$ BEGIN --Aggiorna la tabella delle barche non più in uso-- INSERT INTO ex_barche SELECT OLD.bid, OLD.bnome, OLD.colore; RETURN OLD; END $archivia_barca$ LANGUAGE plpgsql; Una volta creata la funzione, possiamo definire il trigger come riportato di seguito: CREATE TRIGGER archivia_barca AFTER INSERT OR UPDATE OR DELETE ON barche FOR EACH ROW EXECUTE PROCEDURE archivia_barca(); - CURSORI: I cursori sono dei puntatori ad una riga, cioè una struttura dati che ci consente di racchiudere al suo interno, un insieme di righe, cioè una sottotabella. Un cursore si usa solitamente quando abbiamo a che fare con tabelle che restituiscono più di una riga, cioè si utilizza alternativamente al comando INTO. - CASSANDRA: Cassandra è un DBMS distribuito, column-oriented e open source. Esso, deve essere in grado di fornire alle applicazioni che lo utilizzano, dati in maniera veloce e senza perdita. E’ stato pensato per avere ottime prestazioni dal punto di vista delle scritture, e per poter gestire delle situazioni di Fail Tolerance. Cassandra è caratterizzato da: - Cluster: Che è l’insieme dei server che costituiscono l’istanza di Cassandra. Il cluster può contenere una o più unità di livello inferiore, i cosiddetti keyspace. - Keyspace: E’ un namespace per le column family. Esso può essere assimilato allo schema oppure al database di un RDBMS. - Column Family: E’ un contenitore di colonne o supercolonne. E’ l’equivalente della tabella in un RDBMS. Ogni column family è salvata in un file separato e i valori sono ordinati per chiave della riga (row key). Le column family possono essere statiche, cioè i metadati delle colonne sono definiti a priori, oppure possono essere dinamiche, cioè definiti al momento dell’inseramento della colonna. - Column: E’ definita attraverso un nome ed un valore. - Supercolumn: Colonna che a sua volta contiene altre colonne - Row: La riga è identificata da una chiave, cioè la row key, è costituita da valori separati. Ciascuna riga di una column family può contenere valori di tutte le colonne o solo di alcune. A differenza di molti altri database NoSQL, Cassandra dispone di un proprio linguaggio di query, chiamato CQL (Cassandra Query Language). Questo può essere utilizzato via API o attraverso una shell. DATA MODEL: In Cassandra, il datamodel è gestito da: - La tabella multidimensionale che va a mappare le varie righe per mezzo di un indice chiamato row key. - Le colonne, che sono raggruppate in famiglie di colonne. Queste famiglie possono essere di 2 tipi: 1) Semplice: Costituita da un insieme di colonne 2) Super: Contiene al suo interno altre famiglie di colonne annidate Ogni colonna è costituita da una coppia nome-valore e da un timestamp, che viene salvato automaticamente. Il keyspace, è lo spazio dei nomi che ha dei settaggi e può contenere diverse column families, che a loro volta avranno i propri settaggi, naturalmente le column families contengono diverse colonne con un nome, un valore e un timestamp di creazione. ARCHITETTURA CASSANDRA: Essendo concepito come come sistema distribuito per offrire delle prestazioni ottimali (riguardo il reperimento di dati) e per memorizzare i big data, l’architettura di Cassandra è stata pensta per gestire: - Partizionamento: Cioè come sono distribuiti e memorizzati i dati all’interno dei vari nodi che compongono il sistema distribuito di Cassandra. - Replica: I nostri dati all’interno del sistema distribuito devono essere replicati tra i vari nodi, in modo che se uno di loro si guasta, possiamo recuperare le nostre informazioni. Ogni dato è replicato su N nodi, dove N rappresenta il Fattore di replica. Cassanda offre diverse possibilità di replica: 1) Replica non controllata: Si vanno a replicare i dati dopo il nodo coordinatore 2) Replica controllata: Viene messa in atto grazie ad un framework di comunicazione aggiuntivo, chiamato Zookeper che va a scegliere un nodo coordinatore che andrà a dire a tutti gli altri nodi, il range di nodi all’interno del quale si devono andare a replicare. 3) Replica basata su DataCenter: Simile alla replica controllata, ma il leader viene scelto a livello di DataCenter anziché a livello di Rack(sottoinsieme di nodi in un determinato DataCenter) - Cluster Membership: Cioè che i vari nodi possono essere aggiunti al cluster (cioè al sistema distribuito di MongoDB) ma possono essere anche cancellati. PROTOCOLLO DI GOSSIP: Altro aspetto fondamentale di Cassandra, riguarda questo protocollo. Esso è un protocollo di comunicazione in rete, inspirato alla vita reale, cioè alla diffusione dei “rumors”, appunto “gossip” sta per le voci che passano tra la gente. Ad esempio: Un nodo comunica con un nodo vicino, inviando le informazioni sullo stato di un altro nodo, cosìcché, tutti gli altri nodi, avviando lo stesso processo, inizieranno a diffondere le informazioni sui propri vicini, fino a che ogni nodo saprà com’è organizzato il proprio cluster e come sono organizzati i vari nodi e dunque potrà creare un sistema di comunicazione. Questi messaggi di gossip, vengono scambiati in maniera periodica tra 2 nodi e rappresentano una forma di comunicazione di tipo inter-node, cioè tra vari nodi. La frequenza di comunicazione in genere è bassa, in quanto, minori sono le comunicazioni e minori sono i costi dal punto di vista del processamento, ed i nodi vengono selezionati in genere in maniera random. Abbiamo varie versioni del protocollo di gossip, tra cui: - Protocolli di divulgazione: Basati su divulgazione, scatenata da eventi, che generano messaggi di gossip, quindi avvia un processo di comunicazione. In questo caso abbiamo un’alta latenza, perché viene sovraccaricata la rete, dato che gli eventi vengono inviati in maniera multicast agli altri nodi. Abbiamo inoltre un gossip continuo, poiché la divulgazione dei dati avviene anche in background. - Protocolli di anti entropy: Che viene usato per poter andare a riparare eventuali dati replicati danneggiati, effettuando un confronto tra i dati replicati tra i vari nodi. Se quindi ci sono differenze tra i dati (che devono essere gli stessi essendo replicati), questi vengono riparati. CLUSTER MANAGEMENT: L’insieme di nodi che compongono il sistema distribuito di Cassandra, viene gestito da un protocollo di Gossip, che nel caso di Cassandra, prende il nome di Scuttleback, cioè la versione del protocollo di gossip che viene implementato all’interno di Cassandra. Questo Scuttleback utilizza il protocollo di Gossip per gestire la membership dei vari nodi e per trasmettere informazioni sullo stato dei nodi ad altri nodi. Quindi se un nodo non funziona correttamente, ad esso viene assegnata una variabile phi che va a dire quanto il nostro nodo può andare a fallire. In questo caso parliamo di Livello di fallimento sospetto (Accrual Failure Detector). Nella pratica questo viene rappresentato da un valore binario che può essere up o down. Il protocollo di Gossip è fondamentale in Cassandra per 2 motivi fondamentali: 1) Ripristino o riparazione di dati in nodi replica. 2) Gestire informazioni sullo stato del cluster cioè per supportare la fase di boot del nostro sistema. FUNZIONAMENTO DEL LIVELLO DI FALLIMENTO SOSPETTO (ACCRUAL FAILURE DETECTOR): Se un nodo è in fallimento, cioè in uno stato che potrebbe far pensare ad un fallimento/caduta del nodo, il livello di sospetto, si incrementa nel tempo. ɸ(t)  k come t  k Considerando k come una variabile soglia, che dipende dal carico del sistema, ci dice se il nodo è affidabile o meno. Se il nostro nodo funziona bene, ɸ(t) = 0, se invece tende a k, dove k è la soglia, allora il nostro nodo cadrà, perciò verrà riparato o rimpiazzato. COME AGGIUNGERE NUOVI NODI(BOOTSTRAPPING): Ci sono 2 modi fondamentali per aggiungere un nodo. 1) Ad ogni nodo viene assegnato un “gettone” che indica la posizione all’interno dell’anello, quindi viene avviato un processo di gossip riguardante la propria posizione, rivolto a tutti gli altri nodi. 2) Un nodo va a leggere da un file di configurazione, come dovrà essere collegato al sistema e all’interno di questo nodo conterrà le informazioni riguardanti gli altri nodi da compattare. PERSISTENZA LOCALE: Ogni nodo al suo interno, fa affidamento su file-system locale che si trova all’interno del nodo stesso. Ogni nodo effettua delle operazioni di scrittura in 2 fasi: 1) Scrive un commit all’interno di un log che si trova nell’hard-disk locale del nodo stesso 2) Fa un update in memoria della struttura dati che si vuole modificare Se tutto va a buon fine vengon attuate le modifiche. Per quanto riguarda invece le operazioni di lettura: 1) Controlla se in memoria ci sono i dati che bisogna andare a ricercare 2) Se non ci sono in memoria, li deve recuperare all’interno dell’hard disk locale. Per farlo utilzza un filtro, che prende il nome di Bloom, che va ad effettuare dei resoconti sulle chiavi relative ai vari file, che sono memorizzate in memoria. CASSANDRA QUERY LANGUAGE (CQL): Un DB in Cassandra prende il nome di keyspace, che definisce due strategie di replica dei dati, ovvero o utilizzando un solo cluster (SimpleStrategy) o più cluster (NetworkTopologyStrategy). La sintassi per un keyspace è : CREATE KEYSPACE [keyspace_name] WITH REPLICATION = {‘class’ : ‘Strategy’,[datacenter_name]:n}; Dove keyspace_name è il nome che si vuole dare al keyspace ed n indica il numero di repliche di dati che deve essere presente nel cluster. Nel caso di un solo datacenter non è necessario assegnarli un nome e la stringa associata: CREATE KEYSPACE keyspace_name WITH REPLICATION = {‘class’: ‘SimpleStrategy’, ‘replication_factor’ : n}; Nel caso invece di più datacenter è necessario specificare il nome del datacenter ed il replica_factor per ciascuno di essi: CREATE KEYSPACE kespce_name WITH REPLICATOIN = {‘class’:’NetworkTopologyStrategy’, ‘dataprim’: 3, ’datas’: 2}; CASI D’USO Carichi di lavoro di grandi quantità di dati in tempo reale Gestione dei dati delle serie temporali Consumo e analisi dei dati del dispositivo ad alta velocità Gestione dello streaming multimediale (ad es. Musica, film) Input e analisi dei social media (cioè dati non strutturati) Vendita al dettaglio online (ad es. Carrelli acquisti, transazioni utente) Analisi dei dati in tempo reale Giochi online (ad esempio, messaggistica in tempo reale) Applicazioni software come servizio (SaaS) che utilizzano servizi Web Portali online (ad es. Interazioni tra operatori sanitari e pazienti) La maggior parte dei sistemi a scrittura intensiva - HBASE: Apache HBase è un datastore per Big Data distribuito dotato di elevata scalabilità che fa parte dell'ecosistema di Apache Hadoop. Si tratta di un database open source non relazionale con versioni multiple che viene eseguito con il file system distribuito Hadoop (HDFS) COME FUNZIONA L’ARCHITETTURA DI HADOOP/HDFS: E’ formato da un Namenode, che è il coordinatore, esso contiene al suo interno: I Metadati, cioè dati che vengono utilizzati dalle applicazioni per gestire i vari processi, quindi esso contiene delle informazioni sui dati. Esso può contenere il nome logico del file, ed informazioni che riportano in quale Datanodes si trovano i vari frammenti per ricostruire i vari file. Consideriamo un file che viene frammentato, ogni frammento viene memorizzato all’interno di vari Datanodes cosicchè, se noi abbiamo un file, ad esempio composto da 3 frammenti, questi potranno essere replicati e memorizzati sui vari Datanodes. Il Datanodes contiene i frammenti veri e propri. I Datanodes sono organizzati in gruppi, che prendono il nome di Rack. Ogni frammento può essere replicato su un altro Datanodes di un altro Rack. Il client, interroga il Namenode, ed in base al file che il client richiede, il Namenodes gli dirà dove si trovano i vari frammenti e li andrà a prelevare direttamente. Per quanto riguarda invece le operazioni di scrittura (write), sarà il client che riceverà le informazioni riguardanti su dove andare a memorizzare i vari frammenti del file e li memorizzerà. COME SI COMPONE L’ARCHITETTURA DI HBASE? Si compone di HDFS/Hadoop a basso livello, successivamente abbiamo dei vari nodi, chiamati Region Server. Successivamente abbiamo un master che terrà traccia delle varie column family ed in più abbiamo Zookeper, cioè un middleware di comunicazione necessario per far comunicare master node e region server. A questo punto il client si connetterà a Zookeeper, tramite esso raggiungerà il master ed esso comunicherà con i vari region server che risponderanno direttamente al client. I region server memorizzano i dati all’interno di HDFS. HBASE – FAULT TOLERANCE: - Se un region server si guasta, il nuovo hbase master andrà ad istanziare un nuovo region server. - Se il nostro nodo master si guasta, un master di backup, che fino a quel momento aveva funzionato in modalità passiva e quindi aveva replicato tutte le operazioni del master attivo, in background, andrà a sostituire il nodo master guasto, diventando lui il nuovo nodo master attivo. - Se il nodo master di backup si guasta, e non abbiamo altri backup, il nostro sistema si guasta, ed a questo punto bisogna gestire in maniera automatizzata questa situazione. - La replica avviene direttamente da HDFS - L’individuazione dei malfunzionamenti verrà fatta automaticamente da Zookeper, che identificherà quali region server sono non funzionanti. HBASE – DATA MODEL: - Non c’è la necessità di avere uno schema a priori - I dati vengono gestiti sottoforma di tabelle, ed ogni riga di queste tabelle ha una Row-Key che deve essere univoca. - Le righe possono essere formate da una o più colonne - Le colonne possono essere raggruppate in column family - Le column family devono essere definite al momento della creazione della tabella - Possiamo avere un numero variabile di colonne per ogni column family ed inoltre le colonne possono essere aggiunte in qualsiasi momento - Le colonne possono essere NULL anche se non sono memorizzate nel DB - Le colonne vengono inserite in ordine sparso - Una cella è una coppia chiave-valore al quale si associa un timestamp. Ogni cella (cioè ogni dato), verrà identificato da una Row Key, Column family, da un Qualificatore (che specifica il tipo del dato che stiamo memorizzando), Timestamp (Versione). - HBASE STORAGE MODEL: PARTIZIONAMENTO: - In HBASE, le tabelle sono partizionate in maniera orizzontale in svariate regioni, ed ogni regione è composta da un range sequenziale di chiavi. - Ogni regione è gestita da un RegionServer. PERSISTENZA E DISPONIBILITA’ DEI DATI: - In HBASE, vengono memorizzati i dati all’interno di HDFS e non vengono replicati, in quanto questa azione verrà fatta direttamente da HDFS. - I dati riguardanti le varie regioni, sono memorizzate in una cache di sistema (MemStore). - La MemStore viene aggiornata periodicamente su HDFS. - La permanenza dei dati in memoria dipende dai log, che vengono scritti da HDFS. HBASE SHELL: La shell di HBASE, ci consente di inserire dei comandi per: - Creazione/eliminazione di tabelle - Inserimento/aggiornamento/lettura da tabelle - Gestire le varie regioni OPERAZIONI ATOMICHE SU HBASE: Per poter eseguire le operazioni atomiche, utilizziamo: - CheckAndPut: Prima verifico se si può eseguire un operazione e poi si inserisce ad esempio un dato nel db - CheckAndDelete: Prima verifico e poi lo elimino HBASE SHELL: Nella shell di HBASE si utilizza in genere Jruby IRB (Interactive Ruby Shell). La shell di HBase, ci consente di inserire dei comandi per: - Creazione/eliminazione di tabelle - Inserimento/aggiornamento/lettura da tabelle - Gestire le varie regioni - Per eseguire la shell, andare nella nostra directory di installazione di HBASE, ed eseguirla, esempio: $ /bin/hbase shell - Ogni nome di tabella e di colonna deve essere racchiuso tra apici: ‘ ‘ Singoli nel caso di valori testuali “ “Doppi quando abbiamo a che fare con valori binari hbase > get ‘t1’, ‘myRowID’ - Per creare tabelle, utilizziamo create: hbase > create ‘Blog’, {NAME => ‘info’, VERSIONS => 5}  Il nome della colonna sarà info Oppure creare più column family direttamente: hbase > create ‘Blog’, {NAME => ‘info’}, {NAME => ‘contenuti’}  Ci sono 2 colonne: info e contenuti Oppure molto semplicemente utilizziamo: hbase > create ‘Blog’, ‘colonna1’, ‘colonna2’, ‘colonna3’ - Per popolare la nostra tabella usiamo il comando put: hbase > put ‘table’, ‘row_id’, ‘family:column’, ‘value’ Esempio: put ‘Blog’, ‘1’, ‘info:Titolo’, ‘Elefante’ Cioè inserisci nella tabella Blog, con id 1 il titolo elefante. Così facendo, però, popoliamo solo la colonna “Titolo”, quindi se la tabella ha altre colonne, tipo ‘info:autore’ e ‘info:data’, dobbiamo scrivere altri put: put ‘Blog’,’1’,’info:autore’,’Gianfranco’ put ’Blog’,’1’,’info:data’,’27/11/2020’ Get: Recupera e restituisce una singola riga: hbase > get ‘table’, ‘row_id’, esempio: get ‘Blog’, ‘1’ Scan: Recupera un range di righe: hbase > scan ‘table_name’, esempio: scan ‘Blog’, {STARTROW => ‘1’, STOPROW => ‘10’} Questa ci fa visualizzare tutte le righe che partono da 1 e finiscono a 10. Lo start è sottointeso mentre lo stop va specificato sempre. Possiamo avere anche delle operazioni logiche come AND, OR, SKIP, WHILE. - Per eliminare un record, usiamo delete: delete ‘table’,’id’,’colonna’ Esempio: delete ‘Blog’, ‘3’, ‘info:date’ - Per eliminare una tabella, usiamo drop. Prima di eliminarla dobbiamo eseguire il disable: disable ‘table_name’ dorp ‘table_name’ OPERAZIONI ATOMICHE SU HBASE: Per poter eseguire le operazioni atomiche, utilizziamo: - CheckAndPut: Prima verifico se si può eseguire un’operazione e poi si inserisce ad esempio un dato nel database; - CheckAndDelete: Prima verifico e poi lo elimino. - MONGO DB: E’ un database NoSQL per la gestione dei documenti. Esso memorizza dati in documenti formato JSON. In MONGODB la terminologia rispetto ai RDBMS cambia, infatti si utilizzano: - Database - Collection (cioè le tabelle): Cioè dati accomunati tra loro da una parentela logica, un po’come le tabelle di un database relazionale. A differenza di queste però, nelle quali i dati (le righe) hanno tutti lo stesso formato o meglio lo stesso schema, i dati contenuti in una collezione sono indipendenti l’uno dall’altro, cioè ad esempio in una tabella abbiamo “Anagrafica” che ha: nome,cognome,età,ecc.. Mentre in una collection possiamo avere un elemento con: nome,cognome,età ed un altro con: nome,cognome,data di nascita. - Document (cioè le tuple/righe/record): E’ come se fosse un record di un database relazionale, con la differenza che un documento può contenere al suo interno altri documenti. - Field, cioè “Campo” (cioè le colonne): Definiscono un singolo elemento all’interno di un documento. - Embdedd Documents: Cioè “Incapsulamento dei documenti” (cioè i join tra tabelle). Non esistono le chiavi esterne, infatti la tecnica per creare una situazione simile alle chiavi esterne è quella di incapsulare i documenti. Questo può avvenire al momento della definizione del data model o anche in un secondo momento, poiché MongoDB è un database di tipo schema free (senza schema predefinito) - Primary key: In MongoDB viene creata di default ed è chiamata ObjectID STRUTTURA MONGODB: MongoDB utilizza una struttura dati in formato BSON (simile a JSON), ogni documento è composto da varie coppie chiave-valore, dove il valore può essere un documento a sua volta, esempio: { _id: ObjectID(7df78ad8902c) titolo: “Esempio MongoDB” descrizione: “MongoDB è un database NoSQL” } VANTAGGI MONGODB: - Schema less: Cioè non ha uno schema predefinito, possiamo aggiungere field quando ne abbiamo necessità. - Struttura ad oggetti: Ci consente di avere una facilità di lettura, quindi la struttura di ogni singolo oggetto è chiara - Non ci sono join - Possibilità di svolgere query complesse - Facilmente installabile e configurabile - E’ uno strumento scalabile - Utilizza la memoria interna per memorizzare i dati nel quale lavora SHARDING MONGODB: Per sharding si intende la tecnica per la creazione di un database distribuito (anche detto sharded cluster) in cui ogni nodo contiene una porzione del database. In MongoDB per realizzare un cluster in sharding sono necessari tre componenti, almeno uno per tipo: - Router mongos: Si tratta di un nodo speciale che non contiene dati, ma funge da interfaccia alle applicazioni client. Infatti, le applicazioni esterne non devono preoccuparsi dell’architettura del sistema, ma possono solamente connettersi ad uno di questi nodi come se fosse un semplice database MongoDB. Tutte le query e le operazioni di scrittura vengono quindi inviate ai router, che le smistano al cluster. - Shard: Può essere o una istanza di MongoDB (mongod), oppure un intero Replica Set. Ovviamente, in fase di test è più semplice usare un singolo nodo, ma in fase di realizzazione di un database di produzione è raccomandato l’uso di Replica Set: così facendo, in caso di un fallimento di un nodo si evitano perdite permanenti di dati. - Config Server: Si tratta di un’istanza di mongod che contiene informazioni sull’architettura del cluster. Il config server è molto importante perché rappresenta l’entità che “sa” come i dati sono distribuiti nel cluster, e quindi come reperirli o a quale nodo inviare le operazioni da effettuare. Un cluster può includere anche diversi config server, ed infatti, per le architetture di produzione, si raccomanda di utilizzarne almeno tre. Utilizzarne uno solo è infatti un pericolo, perché in caso di guasto tutto il cluster diventa inutilizzabile. SINTASSI MONGODB: - Per creare un db: use DATABASE_NAME Se il database non esiste, MongoDB deve crearlo automaticamente. Esempio: >use mydb  Così MongoDB verificherà se esiste il database mydb altrimenti lo crea e ci da il controllo switched to db mydb  Abbiamo il controllo - Per capire qual è il database attivo sul momento, usiamo: >db  Così ci dirà quale db è attivo mydb  Questo è il db attivo - Se vogliamo visualizzare il nostro db, dobbiamo inserire almeno un documento al suo interno: >db.nometabella.insert({nome:”prova”, colore:”rosso”}); A questo punto con >show dbs ci comparirà anche mydb - Per cancellare usiamo: db.dropDatabase() - Se vogliamo visualizzare tutti i documenti nella collezione, usiamo: >db.mycol.find() - Per creare una collection: db.createCollection(nome,options) E’ possibile crearla solamente con il nome, o anche con le opzioni che sono: - Capped: Valore di tipo booleano, se è vera, abilita una collezione di dimensione fissa che automaticamente sovrascrive la entry più vecchia (che magari aveva una dimensione fissa minore) quando si raggiunge la dimensione prefissata. - autoIndexID: Valore di tipo booleano, se è vero, si crea un indice per la collection sul campo _id. - size: Valore numerico, se capped è vero, va specificata la grandezza in byte - max: Valore numerico, specifica il massimo numero di documenti - Per eliminare una collection: db.COLLECTION_NAME.drop() - NEO4J: Neo4j è un software per basi di dati a grafo open source sviluppato interamente in Java, al quale si interagisce con il linguaggio Cypher. DATABASE A GRAFO: Il grafo database di va a memorizzare i dati all’interno di un grafo con vari record che sono chiamati nodi. Oni database a grafo, memorizza qualsiasi dato utilizzando 3 concetti: 1) I nodi rappresentano i nostri record 2) Le relazioni sono archi che connettono i vari nodi 3) Le proprietà sono delle coppie chiave-valore che possono essere associate ai nodi o alle relazioni LABELS (ETICHETTE): E’ possibile anche raggruppare dei nodi in base a determinate proprietà. I nodi possono essere raggruppati in label(etichette) andando a considerarne una per ogni membro. Considerando ad esempio un social graph, possiamo andare ad etichettare ogni tipo di nodo per mezzo dell’etichetta persona. NEO4J BROWSER: E’ un applicazione che rappresenta il client per poter interagire con Neo4j, per mezzo del linguaggio di querying utilizzato da Neo4j che è Cypher. Questo browser ci permette di avere un ambiente shell interattivo, attraverso una Web Application (API). EDITOR: L’editor rappresenta la prima interfaccia che viene utilizzata per l'immissione e l'esecuzione dei comandi. STREAM: E’ l’area che si trova in basso che mostra il risultato di una query o di un comando. Esso conterrà varie finestre che possono essere allargate, chiuse, ridotte ecc. Se vogliamo pulirla basta utilizzare :clear FRAME CODE VIEW: Mostra tutto ciò che è stato inviato e/o ricevuto dal server Neo4j, tra cui: - URI delle richieste del metodo http e gli headers - Risporse http - Richieste e risposte grezze che saranno inviate per mezzo del formato json SIDEBAR: Ci consente di visualizzare in maniera rapida determinate informazioni sul nostro grafo, ad esempio: - Il numero e il tipo dei nodi - Informazione di base e i metadati - Gli script - Riferimenti a documenti esterni - Informazioni su licenza di utilizzo CYPHER: Cypher è il linguaggio di querying che viene utilizzato con Neo4j. Questo linguaggio è stato progettato per poter interagire con graph data, cioè dati strutturati sottoforma di grafo. Esso utilizza dei patterns per descrivere i dati del grafo, e ci permette di capire cosa vogliamo cercare e come vogliamo cercarlo. - Per creare un nodo, utilizziamo create: CREATE (p:Persona { nome: “Gian”, città: ”Italia” } ) E’ stata aggiunta una variabile p un label “Persona”, creato 1 nodo e settate 3 proprietà(nome,città) - Per recuperare il nodo rappresentato dalla proprietà “Gian”, utilizziamo match: MATCH (p:Persona) WHERE p.nome = “Gian” p; La variabile match serve per recuperare dei dati - Per avere delle relazioni: (js)-[:KNOW]->(ir),(js)-[:KNOWS]->(rvb) - MACHINE LEARNING: Machine Learning = Apprendimento automatico della macchina Per mezzo di svariati algoritmi, va ad analizzare dei dati in maniera tale da fare delle previsioni su un determinato comportamento di questi dati e quindi per poter estrarre conoscenza. Il calcolatore va ad estrarre direttamente dai dati di input, le caratteristiche salienti del dataset per risolvere un determinato problema, producendo l’output desiderato. E’ un’abilità delle macchine (intese come computer) di apprendere senza essere state esplicitamente e preventivamente programmate. Abbiamo diversi approcci al machine learning: - Supervisionato: Si basa sul concetto di addestramento, cioè noi forniamo al nostro algoritmo sia i dati da analizzare, sia i risultati che ci aspettiamo che l’algoritmo ci restituisca, in questo modo l’algoritmo si addestrerà automaticamente, cercando di restituire il valore di output previsto. In poche parole, in questo tipo di approccio, il lavoro di risoluzione viene lasciato al computer. Una volta compresa la funzione matematica che ha portato a risolvere uno specifico insieme di problemi, sarà possibile riutilizzare la funzione per rispondere a qualsiasi altro problema similare. Esempio: Reti Neurali - Non supervisionato: In questa seconda categoria di Machine Learning al sistema vengono forniti solo set di dati senza alcuna indicazione del risultato desiderato. Lo scopo di questo secondo metodo di apprendimento è “risalire” a “schemi e modelli nascosti”, ossia identificare, negli input, una struttura logica senza che questi siano preventivamente etichettati, in modo da fornirci informazioni che possono esserci utili, ad esempio ci può dire attraverso delle valutazioni che: Tutte le persone che acquistano un Mec Flarry acquistano un Chicken mc nuggets. - Semi-supervisionato: In questo caso si tratta di un modello “ibrido” dove al computer viene fornito un set di dati incompleti per l’allenamento/apprendimento. Alcuni di questi input sono “dotati” dei rispettivi esempi di output (come nell’apprendimento supervisionato), altri invece ne sono privi (come nell’apprendimento non supervisionato). L’obiettivo, di fondo, è sempre lo stesso: identificare regole e funzioni per la risoluzione dei problemi, nonché modelli e strutture di dati utili a raggiungere determinati obiettivi. - Con rinforzo: Il nostro algoritmo impara dai nostri errori. Non partiamo dai dati come gli altri approcci, ma lasciamo l’algoritmo libero nel suo ambiente finché non impara. Abbiamo diverse categorie di applicazione: - Classificazione: In questo caso andiamo a considerare il collocamento di un dato in una determinata categoria. - Regressione: La regressione è un processo statistico che ci permette di stimare le relazioni tra variabili. Determina il legame funzionale tra le variabili indipendenti e le variabili dipendenti. La regressione corrisponde al valore medio atteso in base ai dati di input che noi immettiamo. Grazie alla regressione si può parlare di previsione sui valori attesi. I valori di ingresso sono un vettore di dati n-dimensionale dalla quale deriva un unico valore di uscita, determinando così l'operazione di regressione. - Clustering: I dati devono essere collocati in determinate porzioni dell’area dati che consideriamo. Il machine learning si divide in diverse fasi: - Fase di training: Si va ad allenare la base di dati sui dataset di esempio - Fase di testing: Si va a valutare l’accuratezza della nostra misura - Fase operativa: Si vanno ad effettuare le valutazioni di predizione sui nostri dati - Fase di validazione: Si vanno a validare i dati I campi di applicazione del machine learning sono quelli riguardanti - Classificazione di immagini - Riconoscimento facciale e vocale - Traduzione automatica DEEP LEARNING – IMITA IL CERVELLO: L'apprendimento profondo (in inglese deep learning) è quel campo di ricerca dell'apprendimento automatico (in inglese machine learning) e dell'intelligenza artificiale che si basa su diversi livelli di rappresentazione, corrispondenti a gerarchie di caratteristiche di fattori o concetti, dove i concetti di alto livello sono definiti sulla base di quelli di basso. In altre parole, per apprendimento profondo si intende un insieme di tecniche basate su reti neurali artificiali organizzate in diversi strati, dove ogni strato calcola i valori per quello successivo affinché l'informazione venga elaborata in maniera sempre più completa. NATURAL LANGUAGE PROCESSING: Chiamato in italiano elaborazione di linguaggio naturale da parte del calcolatore, dove vengono utilizzate delle tecniche come: - Opinion mining: Cioè andare ad individuare quali sono le possibili opinioni degli utenti in un social network - Sentiment analysis: Vanno ad individuare il sentimento di chi scrive WORD EMBEDDING: Chiamato in italiano immersione di parole, permette di memorizzare le informazioni sia semantiche che sintattiche delle parole. Cioè le similitudini a livello semantico. Questo può CATEGORIZZAZIONE DEI DATI: I dati categorici sono variabili che contengono etichette sotto forma di valori tetsuali invece che valori numerici. Ogni valore rappresenta una categoria: - Il numero di possibili valori è in genere limitato - I dati categorici sono chiamati anche nominali