{"id":36650,"date":"2019-10-31T22:12:54","date_gmt":"2019-10-31T19:12:54","guid":{"rendered":"https:\/\/prohoster.info\/blog\/tranzaktsii-v-globalah-intersystems-iris\/"},"modified":"2019-10-31T22:12:54","modified_gmt":"2019-10-31T19:12:54","slug":"tranzaktsii-v-globalah-intersystems-iris","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/tranzaktsii-v-globalah-intersystems-iris","title":{"rendered":"Transazioni nei globali di InterSystems IRIS","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"TransazioniIl DBMS InterSystems IRIS supporta strutture interessanti per la memorizzazione dei dati: i globali. Essi sono in sostanza chiavi multilivello con vari benefici, come transazioni, funzioni rapide per navigare gli alberi di dati, blocchi e il proprio linguaggio ObjectScript.<\/p>\n

Scopri di pi\u00f9 sui globali nella serie di articoli \u00abI globali: spade e tesori per la memorizzazione dei dati\u00bb:<\/p>\n

Alberi. Parte 1<\/a><\/noindex>
\nAlberi. Parte 2<\/a><\/noindex>
\nArray sparsi. Parte 3<\/a><\/noindex><\/p>\n

Sono curioso di come siano implementate le transazioni nei globali e quali caratteristiche presentino. Infatti, si tratta di una struttura di memorizzazione dei dati completamente diversa rispetto alle comunemente usate tabelle. Molto pi\u00f9 a basso livello.
\n<\/a><\/noindex>
\nCome \u00e8 noto nella teoria dei database relazionali, una buona implementazione delle transazioni deve soddisfare i requisiti ACID<\/a><\/noindex>:<\/p>\n

A \u2014 Atomicit\u00e0 (Atomic).<\/b> Tutte le modifiche apportate nella transazione vengono registrate, oppure nessuna.<\/p>\n

C \u2014 Coerenza (Consistency).<\/b> Dopo il completamento della transazione, lo stato logico del database deve essere internamente consistente. In gran parte questo requisito riguarda il programmatore, ma nel caso dei database SQL riguarda anche le chiavi esterne.<\/p>\n

I \u2014 Isolamento (Isolation).<\/b> Le transazioni che vengono eseguite in parallelo non devono influenzarsi reciprocamente.<\/p>\n

D \u2014 Durable (durata).<\/b> Dopo il completamento con successo di una transazione, problemi a livelli inferiori (come un'interruzione di corrente) non devono influenzare i dati modificati dalla transazione.<\/p>\n

I globali sono strutture di dati non relazionali. Sono stati creati per funzionare in modo estremamente veloce su hardware molto limitato. Esaminiamo l'implementazione delle transazioni nei globali utilizzando l'immagine docker ufficiale di IRIS<\/a><\/noindex>.<\/p>\n

Per supportare le transazioni in IRIS, si utilizzano i comandi: TSTART<\/a><\/noindex>, TCOMMIT<\/a><\/noindex>, TROLLBACK<\/a><\/noindex>.<\/p>\n

1. Atomicit\u00e0<\/h2>\n

\n\u00c8 pi\u00f9 facile verificare l'atomicit\u00e0. Facciamo un controllo dalla console del database.<\/p>\n

Kill ^a\nTSTART\nSet ^a(1) = 1\nSet ^a(2) = 2\nSet ^a(3) = 3\nTCOMMIT<\/code><\/pre>\n
\nDopo di che possiamo trarre la conclusione:<\/p>\n
Write ^a(1), \u201c \u201d, ^a(2), \u201c \u201d, ^a(3)<\/code><\/pre>\n
\nOtterremo:<\/p>\n
1 2 3<\/code><\/pre>\n
\nTutto a posto. L'atomicit\u00e0 \u00e8 stata rispettata: tutte le modifiche sono state salvate.<\/p>\n
Complichiamo la situazione, introduciamo un errore e vediamo come si comporta la transazione, se sar\u00e0 salvata parzialmente o per nulla.<\/p>\n
Verifichiamo di nuovo l'atomicit\u00e0:<\/p>\n
Kill ^A\nTSTART\nSet ^a(1) = 1\nSet ^a(2) = 2\nSet ^a(3) = 3<\/code><\/pre>\n
\nDopo di che fermeremo forzatamente il container, lo riavvieremo e vedremo. <\/p>\n
docker kill my-iris<\/code><\/pre>\n
\nQuesto comando \u00e8 praticamente equivalente a un'interruzione dell'alimentazione forzata, poich\u00e9 invia il segnale di arresto immediato del processo SIGKILL.<\/p>\n
Potrebbe essersi salvata parzialmente la transazione?<\/p>\n
WRITE ^a(1), ^a(2), ^a(3)\n^\n ^a(1)<\/code><\/pre>\n
\n \u2014 No, non \u00e8 stata salvata.<\/p>\n
Proviamo il comando di rollback:<\/p>\n
Kill ^A\nTSTART\nSet ^a(1) = 1\nSet ^a(2) = 2\nSet ^a(3) = 3\nTROLLBACK\n\nWRITE ^a(1), ^a(2), ^a(3)\n^\n ^a(1)<\/code><\/pre>\n
\nNiente \u00e8 stato salvato nemmeno questa volta.<\/p>\n
2. Coerenza<\/h2>\n
\nPoich\u00e9 nelle basi sui globali le chiavi vengono create anche sui globali (ricordo che un globale \u00e8 una struttura di livello inferiore per l'archiviazione dei dati rispetto a una tabella relazionale), per soddisfare i requisiti di coerenza \u00e8 necessario includere la modifica della chiave nella stessa transazione della modifica del globale.<\/p>\n
Per esempio, abbiamo il globale ^person, in cui archiviamosoggetti e utilizziamo il codice fiscale come chiave.<\/p>\n
^person(1234567, \u2018firstname\u2019) = \u2018Sergey\u2019\n^person(1234567, \u2018lastname\u2019) = \u2018Kamenev\u2019\n^person(1234567, \u2018phone\u2019) = \u2018+74995555555\n...<\/code><\/pre>\n
\nPer avere una ricerca rapida per cognome e nome abbiamo creato la chiave ^index.<\/p>\n
^index(\u2018Kamenev\u2019, \u2018Sergey\u2019, 1234567) = 1<\/code><\/pre>\n
\nPer garantire che il database sia coerente dobbiamo aggiungere la personalit\u00e0 in questo modo:<\/p>\n
TSTART\n^person(1234567, \u2018firstname\u2019) = \u2018Sergey\u2019\n^person(1234567, \u2018lastname\u2019) = \u2018Kamenev\u2019\n^person(1234567, \u2018phone\u2019) = \u2018+74995555555\n^index(\u2018Kamenev\u2019, \u2018Sergey\u2019, 1234567) = 1\nTCOMMIT<\/code><\/pre>\n
\nDi conseguenza, durante l'eliminazione dobbiamo utilizzare anche una transazione:<\/p>\n
TSTART\nKill ^person(1234567)\nZKill ^index(\u2018Kamenev\u2019, \u2018Sergey\u2019, 1234567)\nTCOMMIT<\/code><\/pre>\n
\nIn altre parole, l'esecuzione della necessit\u00e0 di coerenza ricade interamente sulle spalle del programmatore. Ma quando si tratta di variabili globali, questo \u00e8 normale a causa della loro natura a basso livello.<\/p>\n
3. Isolamento<\/h2>\n
\nQui iniziano le complicazioni. Molti utenti lavorano contemporaneamente sulla stessa base di dati, modificando gli stessi dati.<\/p>\n
La situazione \u00e8 paragonabile a quella in cui molti utenti lavorano contemporaneamente su un unico repository di codice e cercano di eseguire commit di modifiche in molti file allo stesso tempo.<\/p>\n
Il database deve gestire tutto in tempo reale. Considerando che nelle aziende importanti esiste anche una persona dedicata al controllo delle versioni (per la fusione dei rami, la risoluzione dei conflitti, ecc.), e che il database deve fare tutto questo in tempo reale, diventa evidente la complessit\u00e0 del compito e l'importanza di progettare correttamente il database e il codice che lo gestisce.<\/p>\n
Il database non pu\u00f2 comprendere il significato delle azioni degli utenti per evitare conflitti se lavorano sugli stessi dati. Pu\u00f2 solo annullare una transazione che contraddice un'altra o eseguirle in sequenza.<\/p>\n
Un ulteriore problema \u00e8 che durante l'esecuzione di una transazione (prima del commit), lo stato del database pu\u00f2 essere incoerente, quindi \u00e8 preferibile che altre transazioni non abbiano accesso a uno stato incoerente del database. Questo obiettivo viene raggiunto nei database relazionali in vari modi: creando snapshot, utilizzando la multiversione delle righe, ecc.<\/p>\n
Durante l'esecuzione parallela delle transazioni, \u00e8 importante che queste non interferiscano l'una con l'altra. Questa \u00e8 la propriet\u00e0 di isolamento.<\/p>\n
SQL definisce 4 livelli di isolamento:<\/p>\n