{"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 in globali InterSystems IRIS","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"TransazioniIl DBMS InterSystems IRIS supporta strutture interessanti per l'archiviazione dei dati: i globali. In sostanza, si tratta di chiavi multi-livello con vari vantaggi aggiuntivi come transazioni, funzioni veloci per percorrere alberi di dati, bloccaggi e il proprio linguaggio ObjectScript.<\/p>\n

Maggiori dettagli sui globali nella serie di articoli \"Globali - spade magiche per l'archiviazione dei dati\":<\/p>\n

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

Sono curioso di sapere come sono implementate le transazioni nei globali, quali sono le loro peculiarit\u00e0. Infatti, si tratta di una struttura di archiviazione dei dati completamente diversa dalle Tabelle comunemente conosciute. \u00c8 molto pi\u00f9 a basso livello.
\n<\/a><\/noindex>
\nCome noto dalla teoria dei database relazionali, una buona implementazione delle transazioni deve soddisfare i requisiti ACID<\/a><\/noindex>:<\/p>\n

A - Atomico (atomicit\u00e0).<\/b> Vengono registrate tutte le modifiche apportate nella transazione o nessuna.<\/p>\n

C - Coerenza (consistenza).<\/b> Dopo il completamento della transazione, lo stato logico del DB deve essere internamente coerente. Molti di questi requisiti riguardano il programmatore, ma nel caso dei database SQL riguardano anche le chiavi esterne.<\/p>\n

I - Isolato (isolamento).<\/b> Le transazioni eseguite in parallelo non devono influenzarsi a vicenda.<\/p>\n

D - Durabile (durabilit\u00e0).<\/b> Dopo un completamento riuscito della transazione, problemi a livelli inferiori (come un'interruzione di corrente, per esempio) non devono influire sui dati modificati dalla transazione.<\/p>\n

I globali sono strutture dati non relazionali. Sono stati creati per un funzionamento super 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 usano i comandi: TSTART<\/a><\/noindex>, TCOMMIT<\/a><\/noindex>, TROLLBACK<\/a><\/noindex>.<\/p>\n

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

\n\u00c8 pi\u00f9 facile testare l'atomicit\u00e0. Verifichiamo 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
\nPoi facciamo un'analisi:<\/p>\n
Write ^a(1), \" \", ^a(2), \" \", ^a(3)<\/code><\/pre>\n
\nOtterremo:<\/p>\n
1 2 3<\/code><\/pre>\n
\nTutto in ordine. L'atomicit\u00e0 \u00e8 rispettata: tutte le modifiche sono state registrate.<\/p>\n
Complichiamo il compito, introduciamo un errore e vediamo come viene mantenuta la transazione, parzialmente o per niente.<\/p>\n
Controlliamo 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
\nDopodich\u00e9 fermeremo forzatamente il contenitore, lo riavvieremo e vedremo. <\/p>\n
docker kill my-iris<\/code><\/pre>\n
\nQuesto comando \u00e8 praticamente equivalente a una interruzione forzata dell'alimentazione, poich\u00e9 invia un segnale di arresto immediato del processo SIGKILL.<\/p>\n
Potrebbe essere che la transazione sia stata salvata parzialmente?<\/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
\nAnche stavolta non \u00e8 stato salvato nulla.<\/p>\n
2. Coerenza<\/h2>\n
\nPoich\u00e9 nelle basi sui globali le chiavi vengono create anch'esse sui globali (ricordo che un globale \u00e8 una struttura a livello inferiore per memorizzare dati rispetto a una tabella relazionale), per soddisfare il requisito di coerenza \u00e8 necessario includere la modifica della chiave nella stessa transazione che modifica il globale.<\/p>\n
Ad esempio, abbiamo un globale ^person, in cui memorizziamo le personalit\u00e0 e come chiave utilizziamo il codice fiscale.<\/p>\n
^person(1234567, 'firstname') = 'Sergey'\n^person(1234567, 'lastname') = 'Kamenev'\n^person(1234567, 'phone') = '+74995555555\n...<\/code><\/pre>\n
\nPer avere una ricerca veloce per cognome e nome abbiamo creato la chiave ^index.<\/p>\n
^index('Kamenev', 'Sergey', 1234567) = 1<\/code><\/pre>\n
\nAffinch\u00e9 la base sia coerente dobbiamo aggiungere le personalit\u00e0 in questo modo:<\/p>\n
TSTART\n^person(1234567, 'firstname') = 'Sergey'\n^person(1234567, 'lastname') = 'Kamenev'\n^person(1234567, 'phone') = '+74995555555\n^index('Kamenev', 'Sergey', 1234567) = 1\nTCOMMIT<\/code><\/pre>\n
\nPertanto, durante l'eliminazione dobbiamo anche utilizzare una transazione:<\/p>\n
TSTART\nKill ^person(1234567)\nZKill ^index('Kamenev', 'Sergey', 1234567)\nTCOMMIT<\/code><\/pre>\n
\nIn altre parole, il rispetto del requisito di coerenza ricade completamente sulle spalle del programmatore. Ma quando si tratta di globali, questo \u00e8 normale, a causa della loro natura a livello inferiore.<\/p>\n
3. Isolamento<\/h2>\n
\nQui iniziano le complicazioni. Molti utenti lavorano contemporaneamente sulla stessa base, modificando gli stessi dati.<\/p>\n
La situazione \u00e8 paragonabile a quando molti utenti lavorano contemporaneamente su un unico repository di codice e tentano di fare commit delle modifiche in molti file allo stesso tempo.<\/p>\n
Il database deve gestire tutto questo in tempo reale. Considerando che nelle aziende serie c'\u00e8 persino una persona dedicata al controllo delle versioni (alla fusione dei rami, alla risoluzione dei conflitti, ecc.), e il DB deve fare tutto questo in tempo reale, diventa ovvio la complessit\u00e0 del compito e la correttezza della progettazione del database e del codice che lo gestisce.<\/p>\n
Il database non pu\u00f2 comprendere il significato delle azioni effettuate dagli utenti per evitare conflitti quando lavorano sugli stessi dati. Pu\u00f2 solo annullare una transazione che contraddice un'altra o eseguirle in modo sequenziale.<\/p>\n
Un altro problema \u00e8 che durante l'esecuzione di una transazione (fino al commit), lo stato del database pu\u00f2 essere incoerente. Pertanto, \u00e8 preferibile che altre transazioni non abbiano accesso a uno stato incoerente del database, cosa che si realizza nei database relazionali in molti modi: creando snapshot, utilizzando la multiversione delle righe, ecc.<\/p>\n
Nell'esecuzione parallela delle transazioni \u00e8 importante che non si interferiscano reciprocamente. Questa \u00e8 la propriet\u00e0 di isolamento.<\/p>\n
SQL definisce 4 livelli di isolamento:<\/p>\n