Utente:TarkusTheTediousTaciturn/Durabilità (basi di dati)

Da Wikipedia, l'enciclopedia libera.
Vai alla navigazione Vai alla ricerca

Nell'ambito dei database, la durabilità è la proprietà ACID che garantisce che gli effetti delle transazioni che hanno concluso con un commit sopravvivranno in modo permanente, anche in caso di anomalie e guasti[1], che possono essere causati da incidenti ed eventi catastrofici. Ad esempio, se la prenotazione di un volo riporta che un posto è stato prenotato con successo, il posto rimarrà prenotato anche se il sistema si arresta in modo anomalo.[2]

Formalmente, un sistema di gestione di basi di dati garantisce la proprietà di durabilità se tollera tre tipi di errori: errori delle transazioni, di sistema e del supporto di archiviazione[1]. In particolare, una transazione fallisce se la sua esecuzione viene interrotta prima che tutte le sue operazioni siano state processate dal sistema[3]. Questi tipi di interruzioni possono essere originati a livello di transazione da errori di immissione dei dati, annullamento dell'operatore, timeout o errori specifici dell'applicazione, come il prelievo di denaro da un conto bancario con fondi insufficienti [1]. A livello di sistema, si verifica un errore se i contenuti della memoria volatile vengono persi, a causa, ad esempio, di arresti anomali del sistema, come eventi di memoria insufficiente[3]. A livello di supporto, dove con supporto si intende una memoria stabile che non si cancelli in caso di guasti del sistema, i guasti si verificano quando la memoria stabile, o parte di essa, viene persa[3]. Questi casi sono tipicamente rappresentati da errori del disco[1].

Pertanto, per essere duraturo, il sistema di database deve implementare strategie e operazioni che garantiscano che gli effetti delle transazioni concluse con un commit sopravvivano all'evento anomalo (anche mediante ricostruzione), mentre le modifiche delle transazioni incomplete, che non hanno ancora eseguito il commit al momento dell'errore, verranno ripristinate e non influiranno sullo stato del database. Questi comportamenti si dimostrano corretti quando l'esecuzione delle transazioni possiede rispettivamente le proprietà di resilienza e di recuperabilità[3].

Meccanismi[modifica | modifica wikitesto]

Un automa a stati finiti che mostra i possibili stati dopo le anomalie (in rosso) del DBMS e le transizioni (in nero) necessarie per tornare a un sistema in esecuzione che risulti durevole.

Nei sistemi transazionali, i meccanismi che assicurano la durabilità sono storicamente associati al concetto di affidabilità dei sistemi, come proposto da Jim Gray nel 1981[1] . Questo concetto include la durabilità, ma si basa anche su aspetti delle proprietà di atomicità e consistenza [4] . Nello specifico, un meccanismo di affidabilità richiede primitive che indichino esplicitamente l'inizio, la fine e il rollback delle transazioni [1], che sono implicate anche per le altre due proprietà sopra menzionate. In questa voce sono stati considerati solo i meccanismi strettamente legati alla durabilità. Questi meccanismi si dividono in tre livelli: di transazione, di sistema e di supporto, come i possibili scenari in cui si possono verificare anomalie. Tali scenari devono essere considerati nella progettazione dei sistemi di gestione di basi di dati per rendere le transazioni durevoli[3] .

Livello di transazione[modifica | modifica wikitesto]

La durabilità contro le anomalie che si verificano a livello di transazione, come le operazioni annullate o incoerenti, bloccate da vincoli e trigger, è garantito dalla proprietà di serializzabilità dell'esecuzione delle transazioni. Lo stato generato dalle transazioni che hanno eseguito il commit è disponibile nella memoria principale e, quindi, è resiliente. Le modifiche apportate dalle transazioni che non hanno ancora eseguito il commit possono essere annullate, poiché, grazie alla serializzabilità, possono essere isolate dalle altre transazioni in fase di annullamento[3]. Inoltre, è importante considerare che le sovrascritture che non mantengono alcun tipo di cronologia sono scoraggiate[1]. Esistono più approcci che tengono traccia della cronologia delle modifiche, come ad esempio tecniche basate su timestamp[5] o logging e locking[1].

Livello di sistema[modifica | modifica wikitesto]

A livello di sistema, le anomalie si verificano, per definizione[3], quando i contenuti della memoria volatile vengono persi. Ciò può verificarsi in eventi come arresti anomali del sistema o interruzioni di corrente . I sistemi di database esistenti utilizzano lo storage volatile (ovvero la memoria principale del sistema) per diversi scopi: alcuni vi memorizzano tutto il loro stato e i dati, anche senza alcuna garanzia di durabilità; altri conservano in memoria lo stato e i dati, o parte di essi, ma utilizzano anche la memoria non volatile per i dati; altri sistemi mantengono solo lo stato in memoria principale, mantenendo tutti i dati su disco[6]. I motivi alla base della scelta di combinare uno storage volatile, soggetto a questo tipo di anomalie, con uno storage non volatile risiedono nelle differenze prestazionali delle tecnologie esistenti utilizzate per implementare questi tipi di storage, ma è probabile che la situazione evolvi con l'aumento della popolarità delle tecnologie di memorie non volatili (NVM)[7] .

Nei sistemi che includono l'archiviazione non volatile, la durabilità può essere ottenuta scrivendo e mantendendo un log sequenziale ed immutabile delle transazioni su tale supporto, prima di eseguire il commit. Grazie alla loro proprietà di atomicità, le transazioni possono essere considerate l'unità di lavoro nel processo di recupero che garantisce la durabilità attraverso il log. In particolare, il meccanismo di logging è definito come write-ahead log (WAL) e consente la durabilità bufferizzando le modifiche sul disco prima che vengano sincronizzate dalla memoria principale. In questo modo, mediante la ricostruzione dai file di log, tutte le transazioni di cui è stato eseguito il commit sono resilienti ai guasti a livello di sistema, perché possono essere rifatte. Le transazioni senza commit, invece, sono recuperabili, poiché le loro operazioni vengono registrate su memoria non volatile prima che modifichino effettivamente lo stato del database [8] . In questo modo, le operazioni parzialmente eseguite possono essere annullate senza influire sullo stato del sistema. Dopodiché, quelle transazioni che erano incomplete possono essere rifatte. Pertanto, il log esistente sul supporto di archiviazione non volatile può essere rielaborato per ricreare lo stato del sistema prima di qualsiasi altro successivo errore. Vale la pena considerare che il logging viene eseguito come una combinazione di salvataggio sia dei dati che delle transazioni, per motivi di prestazioni[9] .

Livello del supporto di archiviazione[modifica | modifica wikitesto]

A livello di supporto di archiviazione, gli scenari di guasto affliggono l'archiviazione non volatile, come le unità disco rigido, le unità a stato solido e altri tipi di componenti hardware di archiviazione [8] . Per garantire la durabilità a questo livello, il sistema di database deve fare affidamento su una memoria stabile, cioè una memoria completamente e idealmente resistente ai guasti. Questo tipo di memoria può essere ottenuto con meccanismi di replicazione e robusti protocolli di scrittura [4] .

Sono disponibili molti strumenti e tecnologie per fornire una memoria logica stabile, come il mirroring dei dischi. La loro scelta dipende dai requisiti delle specifiche applicazioni [4] . In generale, le strategie e le architetture di replica e ridondanza che si comportano come una memoria stabile sono disponibili a diversi livelli dello stack tecnologico. In questo modo, anche in caso di eventi catastrofici in cui l'hardware di archiviazione è danneggiato, è possibile prevenire la perdita di dati [10] . A questo livello esiste un forte legame tra durabilità e ripristino di sistema e dati, nel senso che l'obiettivo principale è preservare i dati, non necessariamente in repliche online, ma anche come copie offline [4] . Queste ultime tecniche rientrano nelle categorie di backup, prevenzione della perdita di dati e ripristino di emergenza [11] .

Pertanto, in caso di guasto del supporto, la durabilità delle transazioni è garantita dalla capacità di ricostruire lo stato del database a partire dai file di log immagazzinati nella memoria stabile, in qualunque modo sia stato implementato nel sistema di database [8] . Esistono diversi meccanismi per archiviare e ricostruire lo stato di un sistema di database che migliora le prestazioni, sia in termini di spazio che di tempo, rispetto alla gestione di tutti i file di log creati dall'inizio del sistema di database. Questi meccanismi spesso includono dumping incrementale, file differenziali e checkpoint [12] .

Database distribuiti[modifica | modifica wikitesto]

Nelle transazioni distribuite, garantire la durabilità richiede meccanismi aggiuntivi per preservare una sequenza di stato coerente in tutti i nodi del database. Ciò significa, ad esempio, che un singolo nodo potrebbe non essere sufficiente per decidere di concludere una transazione effettuandone il commit, poiché le risorse utilizzate in quella transazione potrebbero trovarsi su altri nodi, dove altre transazioni stanno avvenendo contemporaneamente. In caso contrario, in caso di errore, se non è possibile garantire la coerenza, sarebbe impossibile riconoscere uno stato sicuro del database per il ripristino. Per questo motivo, tutti i nodi partecipanti devono coordinarsi prima che un commit possa essere riconosciuto. Questo di solito viene fatto da un protocollo di commit in due fasi [13] .

Inoltre, nei database distribuiti, anche i protocolli per la registrazione e il ripristino devono affrontare i problemi degli ambienti distribuiti, come i deadlock, che potrebbero impedire la resilienza e la recuperabilità delle transazioni e, quindi, la durabilità [13] . Una famiglia di algoritmi ampiamente adottata che garantisce queste proprietà è Algorithms for Recovery and Isolation Exploiting Semantics (ARIES) [8] .

Voci correlate[modifica | modifica wikitesto]

Note[modifica | modifica wikitesto]

  1. ^ a b c d e f g h vol. 81. Errore nelle note: Tag <ref> non valido; il nome ":0" è stato definito più volte con contenuti diversi
  2. ^ MariaDB, https://mariadb.com/resources/blog/acid-compliance-what-it-means-and-why-you-should-care/. URL consultato il 22 September 2021.
  3. ^ a b c d e f g Vassos Hadzilacos, A theory of reliability in database systems, in Journal of the ACM, vol. 35, 1988, pp. 121–145, DOI:10.1145/42267.42272. Errore nelle note: Tag <ref> non valido; il nome ":1" è stato definito più volte con contenuti diversi
  4. ^ a b c d pp. 311-320, ISBN 978-0-07-709500-0. Errore nelle note: Tag <ref> non valido; il nome ":2" è stato definito più volte con contenuti diversi
  5. ^ L. Svobodova, MANAGEMENT OF OBJECT HISTORIES IN THE SWALLOW REPOSITORY, in MIT/LCS TR-243, 1980.
  6. ^ 1st, pp. 40-42, ISBN 978-1-4920-4034-7.
  7. ^ Joy Arulraj, How to Build a Non-Volatile Memory Database Management System, in Proceedings of the 2017 ACM International Conference on Management of Data, 9 maggio 2017, pp. 1753–1758, DOI:10.1145/3035918.3054780.
  8. ^ a b c d 1st, pp. 185-195, ISBN 978-1-4920-4034-7. Petrov, Oleksandr (2019). Database internals: a deep dive into how distributed data systems work (1st ed.). Beijing Boston Farnham Sebastopol Tokyo: O'Reilly. pp. 185–195. ISBN 978-1-4920-4034-7. Errore nelle note: Tag <ref> non valido; il nome ":3" è stato definito più volte con contenuti diversi
  9. ^ C. Mohan, ARIES: a transaction recovery method supporting fine-granularity locking and partial rollbacks using write-ahead logging, in ACM Transactions on Database Systems, vol. 17, 1º marzo 1992, pp. 94–162, DOI:10.1145/128765.128770.
  10. ^ DOI:10.1109/ICDE.1987.7272398, https://oadoi.org/10.1109/ICDE.1987.7272398.
  11. ^ vol. 43, DOI:10.1145/352515.352521, https://oadoi.org/10.1145/352515.352521.
  12. ^ vol. 10, DOI:10.1145/356725.356730, https://oadoi.org/10.1145/356725.356730.
  13. ^ a b C. Mohan, ARIES: a transaction recovery method supporting fine-granularity locking and partial rollbacks using write-ahead logging, in ACM Transactions on Database Systems, vol. 17, n. 1, 1º marzo 1992, pp. 94–162, DOI:10.1145/128765.128770.Mohan, C.; Haderle, Don; Lindsay, Bruce; Pirahesh, Hamid; Schwarz, Peter (1992-03-01). "ARIES: a transaction recovery method supporting fine-granularity locking and partial rollbacks using write-ahead logging". ACM Transactions on Database Systems. 17 (1): 94–162. doi:10.1145/128765.128770. ISSN 0362-5915. Errore nelle note: Tag <ref> non valido; il nome ":4" è stato definito più volte con contenuti diversi

Bibliografia[modifica | modifica wikitesto]

Collegamenti esterni[modifica | modifica wikitesto]

[[Categoria:Teoria delle basi di dati]]

Estratto da "https://it.wikipedia.org/w/index.php?title=Utente:TarkusTheTediousTaciturn/Durabilità_(basi_di_dati)&oldid=134360097"