Scalabilità affidabilità, disponibilità. Centrale Limite della scalabilità verticale! Distribuzione:
- Scalabilità orizzontale
- Disponibilità in caso di guasti
- Collocazione dati più vicino all'utente
- Frag Orizzontale: Divido, subset di righe, collocate ad esempio per area geografica
- Frag Verticale: Divisione colonne, se solo l'accesso ad alcuni attributi è più frequente di altri
- Frag Mista: Applicata Orizzontale & Verticale per ottenere vantaggi di entrambe
- Replicazione: Copia intera o parziale dei dati sui nodi. + Disponibilità, ma consistenza complessa da gestire
- parziale: Solo alcuni frammenti replicati (quelli con accessi più frequenti) -Disponibilità
- Totale: Replicazione totale di tutti i dati +Disponibilità (Molto costoso gestire consistenza)
- Analisi: Quali nodi coinvolti
- Scomposizione: sottoquery da inviare ai nodi
- Raccolta risultati finali
- Shipping dati: Mando tutti i dati e delego tutte le operazioni al nodo centrale (+ trasferimento via rete)
- Semijoin: Mando solo i dati identificativi necessari per filtrare la tabella nel nodo centrale (- trasferimento via rete)
- Pushdown operazioni: maggior parte operazioni query svolte all'interno dei nodi locali, solo i risultati sono mandati al centrale eventualmente. (--trasferimento in rete)
+Difficile gestione dell'ACID (Atomicity, Consistency, Isolation, Durability)
- Atomicity: o tutto o niente
- Consistency: database resta in uno stato valido
- Isolation: transazioni concorrenti non interferiscono
- Durability: una volta committata una transazione non può essere persa (anche dopo crash) Necessario un protocollo di coordinamento (2PC [2-Phase Commit])
- Replica Sincrona: Scrittura sui nodi in realtime dopo la query, +consistenza ma -disponibilità nel caso di problemi di rete
- Replica Asincrona: Nodi copie aggiornati in tempi diversi: -consistenza, rischio di inconsistenze temporanee
Singolo nodo fisico + Motore relazionale. Unica possibilità : scalabilità verticale (+CPU +RAM, ...) Garantisce:
- Coerenza e integrità forte nei dati
- Controllo centralizzato degli accessi
- Prestazioni affidabili su carichi moderati
- Gestisce inizio e fine transazioni
- Coordina accesso concorrente ai dati
- Decide come risolvere i conflitti tra transazioni In ambiente centralizzato semplice -> Distribuito più difficile
- TM scrive le operazioni svolte su un log (Write-Ahead Logging)
- Al riavvio rilegge il log
- Transazioni committate vengono rieseguite / confermate
- Transazioni non committate vengono annullate (rollback) Sistema distribuito il TM caduto dopo aver preso la decisione globale deve aver mandato a tutti l'info, altrimenti recovery + complicata
- data catalogue: meta-informazioni relative al database (tabella di tabelle, tabella di attributi, ...)
- Query tree: Albero di una query, nodi = operatori relazionali, foglie = tabelle
Unione della gestione dei dati distribuiti con trasparenza di location fisica.
- di Frammentazione: Sistema ignora del tutto la presenza di frammenti
- di Allocazione: Sistema decide da solo quale replica utilizzare
- di Linguaggio: L'applicazione deve specificare sia i frammenti sia il nodo su cui si trovano
- Atomicità Globale: o la transazione è completa su tutti i nodi o non lo è su nessuno.
- Coordinamento: protocollo che decida se fare commit o rollback
- Gestione deadlock distribuiti: Nodi che si aspettano a vicenda
Garantisce consistenza dellle transazioni distribuite, dove partecipano più resource manager, coordinato dal Transaction Manager.
- Fase 1 (prepare): I nodi si preparano a decidere
- I nodi svolgono le operazioni ma senza renderle permanenti
- Se riesce ad eseguirle senza problemi vota commit (Deve anche scriverlo nel log perché nel caso venga chiesto di fare commit in seguito a un crash devono saperlo fare)
- altrimenti se ci sono problemi vota abort
- Fase 2 (commit/abort): Se tutti commit -> commit | altrimenti -> Abort
- transaction manger raccoglie tutti i voti, se tutti commit -> global commit
- se almeno un abort: global abort
- Questa decisione è scritta su log per poter essere recuperata in caso di crash
TM cade dopo aver preso global decision ma prima di aver notificato tutti -> Alcuni nodi rimarranno per sempre in attesa della risposta del TM; questo rende 2PC non fault-tolerant 100%
RM cade dopo aver votato ma prima di aver ricevuto la global choice del TM -> non può fare altro che leggere dal log che cosa aveva votato e rimanere in attesa della risposta.
Se TM cade prima di aver preso una decisione globale, i RM vivi possono abortire localmente però quelli che avevano già votato rimangono comunque bloccati.
3PC Risolve i problemi di 2PC introducendo una fase intermedia -rischio di blocco.
2PC garantisce consistenza forte in transazioni distribuite, ma al costo di disponibilità in caso di fault
- Blocco: single point of failure (Transaction manager), nodi in attesa bloccati
- Rallentamento: intero sistema può rallentare per colpa di un nodo più lento/che non risponde
Base: Costruzione del WFG (Wait-For Graph), nodi = transazioni, archi = relazioni di attesa risorse. Ogni nodo può costruire il WFG locale ma non è abbastanza.
Algoritmo di rilevazione centralizzato: Riceve periodicamente i WFG locali e li unisce per costruire il grafo globale, e controlla la presenza di cicli (deadlock); Svantaggi: Singolo punto di fallimento + collo di bottiglia per crescita del sistema.
Algoritmo di rilevazione completamente distribuito: Basato sullo scambio di messaggi tra i nodi. Ad esempio quando una transazione su un nodo si blocca viene mandato un messaggio di probe, contenente mittente, transazione bloccata e quella su cui è bloccata. Il messaggio viene propagato tra le dipendenze se riesce a tornare al nodo iniziale -> esiste ciclo -> deadlock, non richiede coordinatore centrale ma genera molto traffico di messaggi.
Algoritmi gerarchici: Ogni sottosistema locale rileva deadlock interni, e per quelli globali mandano info al livello superiore.
Per risolvere il deadlock si abortisce una delle transazioni (quella che ha fatto meno lavoro = meno risorse locckate => Minore impatto se abortita): Victim Selection
Per mantenere repliche sincrone, con una forte consistenza:
- Letture su un singolo nodo (veloci)
- Scritture propagate su tutti i nodi (lente)
- Failover automatico (replica sets)
- Rilevazione dei nodi caduti (heartbeat, timeout)
- Ribilanciamento dei dati (sharding dinamico)
- Gestione dati non strutturati o semi-strutturati
- Scalabilità orizzontale più semplice
- Supporto per diverse tipologie di dati anche complesse
- Elevate prestazioni con modelli + flessibili
- Documentali: Memorizzano dati JSON-like: possibile struttura variabile
- Chiave-Valore (redis): Molto semplici, associano una chiave ad un valore arbitrario (e.g. caching/sessioni)
- Wide column (cassandra): dati in colonne invece che in righe, ottimizzati per grandi volumi e scritutre rapide
- Graphi (Neo4j): specializzati nella rappresentazione di relazioni tra entità, reti sociali, ecc...
- Eventually consistent: Spesso non viene garantità la consistenza forte [CAP]
- Meno standardizzati
- Gestione transazioni complessa: e.g. multi-record, multi-collection (limitate/costose)
- Curva di apprendimento
| Modello NoSQL | Modello dei Dati | Utilizzi Tipici | Vantaggi | Svantaggi | Esempi di Sistemi | Caratteristiche Tecniche |
|---|---|---|---|---|---|---|
| Documentale | Documenti JSON, BSON, XML | CMS, e-commerce, gestione utenti, cataloghi, app mobile/web | Flessibilità dello schema, supporta dati annidati, buona leggibilità, query avanzate sui documenti | Mancanza di join veri, query meno ottimizzabili rispetto ai modelli relazionali | MongoDB, CouchDB, RavenDB | Indicizzazione sui campi dei documenti, supporto per sharding e replica, buon supporto ACID nelle transazioni recenti (es. MongoDB 4.x in poi) |
| Key-Value | Coppie chiave-valore | Cache, sessioni utente, configurazioni, contatori, leaderboard | Estrema semplicità e velocità, scalabilità orizzontale elevata | Nessun supporto nativo per query complesse, no relazioni né struttura nei dati | Redis, Riak, Amazon DynamoDB | Accesso O(1), memoria in-RAM (Redis), supporto a TTL, persistenza opzionale, supporto a clustering e alta disponibilità |
| Colonnare (wide-column) | Tabelle con righe sparse e colonne dinamiche | Analisi su grandi volumi, logging, business intelligence, IoT | Eccellente compressione e prestazioni in lettura su grandi volumi, schema flessibile | Non adatto a dati transazionali o relazioni complesse | Apache Cassandra, HBase, ScyllaDB | Partizionamento automatico, consistenza configurabile (es. quorum), ottimale per letture per colonna o scansioni a range |
| A Grafo | Nodi e archi con proprietà | Social network, raccomandazioni, knowledge graph, network topology | Query complesse sulle relazioni sono efficienti, navigazione immediata tramite pattern | Non ideale per operazioni massicce o aggregazioni su grandi dataset lineari | Neo4j, ArangoDB, JanusGraph, OrientDB | Supporto per traversing profondo, linguaggi come Cypher o Gremlin, indexing su nodi e archi, supporto a ACID (Neo4j), difficile da scalare orizzontalmente |
| Multimodello | Supporta più modelli (documenti, grafo, key-value) | Applicazioni ibride che necessitano modelli diversi contemporaneamente | Versatilità, unifica le query e riduce la complessità architetturale | Maggiore complessità interna e talvolta minori ottimizzazioni per casi specifici | ArangoDB, OrientDB, MarkLogic, Cosmos DB | Query unificata (es. AQL), API per più modelli, transazioni ACID su documenti o grafi, supporto nativo a più modelli |
Gestione di grandi volumi di dati in real-time e batch Per analisi rapide su stream di dati continui, 2 Pecorsi paralleli:
- batch layer: gestione intero dataset, rielaborato periodicamente in modo completo -> risultati accurati ma non immediati (key-value/wide-columns)
- speed layer: gestisce solo dati recenti -> risultati veloci ma approssimativi.
- serving layer: unifica risultati e li mostra per possibili interrogazioni (documentale)
- Salvataggio formato BSON: Binary JSON.
- Documenti memorizzati in collezioni
- Struttura dati variabile
- scalabilità orizzontale
- alta disponibilità e performance
- flessibilità schema: no tabelle con colonne rigide
- query potenti e intuitive: query complesse di diverso tipo senza dover eseguire join
- scalabilità orizzontale: Sharding, diviso in più nodi, garantendo alta disponibilità e performance
- replica e tolleranza a guasti: replica set per ridondanza
- Se un nodo cade un secondario prende il suo posto (no interruzione)
- Nodo primario: gestisce tutte le scritture
- Nodi secondari: mantengono copie sincronizzate, possono servire letture eventually consistent
- Arbitri, nodi senza dati che aiutano a mantenere il quorum per le elezioni del nodo primario
Replica asincrona:
- PRimario scrive localmente e propaga le modifiche agli altri.
- I secondari replicano con un possibile ritardo
- Migliore disponibilità ma consistenza eventuale.
+ no join complessi
+ gestisce dati annidati e variabili
+ adatto a modelli denormalizzati
- no ACID piena su transazioni multi-document (oggi si con limiti)
- Ridondanza dati: serve duplicare per evitare join
- Eventually consistentMeccanismi che permettono a mongo di essere fault-tolerant, anche in caso di caduta, e di reagire in modo automatico.
Periodico messaggio mandato agli altri nodi per controllare lo stato; no risposta per 10 secondi: nodo considerato irraggiungibile o guasto.
Molte comunicazioni per sapere sempre quali nodi sono vivi e se necessario un elezione
Avviene quando il primario non è più disponibile. Serve per eleggere un nuovo nodo primario.
- Avviabile da qualsiasi nodo
- Nodi si scambiano i voti: Ogni nodo a diritto ad 1 e un nodo è eletto se e solo se c'è maggioranza assoluta (> 50%)
- Nuovo nodo primario inizierà a gestire le scritture, gli altri replicano i dati sul nuovo primario
Stats utili per elezione:
- Priorità del nodo
- lag di replicazione (quanto è indietro con il lavoro di replica)
Modellare e interrogare in modo naturale dati che presentano molte relazioni tra entità, in relazionale relazioni complesse tipo amici di amici sono difficili da gestire (molte join).
- Nodi (entità)
- Archi (relazioni): legano i nodi e hanno un etichetta
Nodi e archi possono avere proprietà.
- Reti sociali
- Raccomandazione
- Gestione di gerarchie
- Knowledge Graph: sistemi AI che ragionano su reti di conoscenza
- Tracciabilità: e.g. supply chain
+ Relazioni complesse navigabili in pochi passaggi
+ niente join: relazioni parte del dato
+ Aggiunta di nodi e relazioni dinamicamente
+ Vicino al prensiero umano
- Meno efficiente di relazionale per dati "flat" (struttura semplice)
- inadatto a bulk updates
- Meno supporto <- strumento più recente
- Meno standard (no SQL)- Dati distribuiti orizzontalmente: spezzati in partizioni (shard), e collocati su più nodi
- Replica per tolleranza a guasti: ogni dato può essitere su più copie in nodi diversi
- Assenza di schema rigido: ogni documento o riga può avere attributi diversi.
Dataset suddiviso in fette indipendenti (shard) ognuna gestita da un sottoinsieme di nodi
- -carico per un nodo.
- inserimento di nuovi nodi in modo fluido (scalabilità orizzontale)
- Necessita un buon sistema di bilanciamento
Ogni shard può essere replicato su più nodi (+affidabilità)
- Replica sincrona -> massima coerenza
- Replica asincrona -> massima disponibilità (Cassandra replica peer2peer asincrona)
Utilizzato nei sistemi senza master (e.g. Cassandra)
- Conoscere nodi attivi
- Sapere dove si trovano i dati
- Sapere chi è in ritardo / ha problemi
Come?
- Ogni nodo comunica periodicamente con i suoi vicini
- scambia messaggi di gossip (stato di salute, carico, modifiche)
- informazione propagata nel cluster ^ scalabile e resiliente perfetta per cluster grandi
Compromesso fondamentale tra:
- Consistency: tutti i nodi vedono lo stesso dato sempre
- Availability: sistema risponde sempre
- Partition Tolerance: sistema funziona anche se la rete è parzialmente rotta
- Cassandra sacrifica C per garantire A+P
- MongoDB di permette di scegliere se sacrificare C o A, a seconda del tipo di replica scelta.
- Consultazione di più nodi in parallelo
- Quanti nodi devono corrispondere al quorum
- Scrivere su nodi diversi e lasciare che si sistemino tra di loro (hinted handoff)
+ Elasticità e scalabilità orizzontale: + nodi = + capacità
+ Fault-tolerance nativa
+ Performance su larga scala: grandi volumi, bassa latenza
+ Flessibilità di modellazione
- Gestione della consistenza complessa
- Modellazione non relazionale
- Rischi di dati obsoleti o parziali
- Debug distribuito: errori difficili da tracciareOrganizzazione e qualità dei dati molto importante per sistemi ML
- Raccolta e ingestione dato (necessaria architettura che permetta integrazione di dati da sorgenti diverse)
- DB relazionali
- File CSV/JSON
- Server log
- API
- Flussi
- Data exploration e processing
- Tipi e distribuzioni variabili
- Outlier, dati mancanti, anomalie
- Correlazioni, pattern nascosti
- Data cleaning e Feature Engineering
- Pulizia (aggiustati errori trovati in exploration)
- Arricchimento (nuove variabili, aggregazioni, ...)
- Codifica (test -> numeri, normalizzazione, ...)
- Addestramento del modello
- Scelta algoritmo
- Addestramento sui dati
- Validazione del modello
- Valutazione e tuning
- Deployment e monitoraggio
- Rendere il modello usabile:
- servito tramite API
- Input in tempo reale o batch
- Monitorare la qualità del dato in input e il drift (cambiamento)
- Struttura tramite
- Database di produzione
- Monitoraggio dati
- Logging e Testing
- Rendere il modello usabile:
- Retraining periodico
- MLOps
- Pipelines automatiche per il retraining
- Controlli di qualità avanzati
- Versionamento dei dati, dei modelli, dei codici
- MLOps
- Data Quality: Fondamentali accuratezza, consistenza, completezza, tempestività
- Data Governance: Chi può accedere a cosa, versionamento e auditing
- Bias e Fairness: Errori nei dati creano modelli sbilanciati
La qualità dei dati è relativa all'uso che se ne fa. Data quality: Capacità del dato di essere utile, affidabile, aggiornato e corretto rispetto al contesto applicativo.
Quanto il dato riflette la realtà. Potrebbe essere sintatticamente valido e consistente ma non rispecchiare comunque un valore vero.
Assenza di contraddizioni. All'interno di un dataset o in sorgenti diverse il dato che si riferisce ad una stessa cosa dovrebbe avere lo stesso valore.
Un dato è completo quando non manca nulla di essenziale. Un dato non è completo quando:
- Campo obbligatorio nullo
- Record troncato
- Valore derivato non calcolabile per mancanza di input
Il dato rispetta i vincoli del formato relativo al suo tipo. e.g. Email: [email protected]
Assenza di duplicati Record che rappresentano la stessa entità, ma hanno dati leggermente diversi minano l'integrità (necessario record linkage)
Dato accurato e valido può essere inutile se obsoleto. I dati devono essere freschi aggiornati e devono rispecchiare il contesto da cui sono stati catturati.
- Percentuale di null
- Tasso di errore (rispetto a fonti di riferimento, gold standards)
- Frequenza di aggiornamento
- Numero di record duplicati
- Data Profiling
- Data cleansing tools
- Vincoli di integrità (DB)
- Pipeline di monitoraggio (sistemi distribuiti)
- Standardizzazione e normalizzazione dei dati