Kokie yra transakcijų izoliavimo lygiai?

Question

Accepted Answer

**Izoliavimo lygiai** kontroliuoja, kiek lygiagretės transakcijos gali pamatyti viena kitos nepatvirtintų (arba vykdomų) pokyčių — subalansavę **nuoseklumą** prieš **našumą/lygiagretumą**. Aukštesni izoliavimo lygiai nuo daugiau anomalijų, tačiau padidina blokavimą/konfliktus.

## Lygiagretaus vykdymo anomalijos (ką izoliavimas prevencija)

```text
DIRTY READ        → reading another transaction's UNCOMMITTED changes (which may roll back)
NON-REPEATABLE READ → re-reading a row gives different values (another txn UPDATED it)
PHANTOM READ      → re-running a query returns different ROWS (another txn INSERTED/DELETED)
```

Tai yra problemos, kurios gali įvykti, kai transakcijos vykdamos lygiagretai — izoliavimo lygiai kontroliuoja, kurios yra pencija.

## Keturi standartiniai izoliavimo lygiai

Kiekvienas aukštesnis lygis prevencija daugiau anomalijų. **Read Committed** yra dažnas numatytasis (prevencija dirty reads); **Serializable** yra griežčiausias (transakcijos veikia taip, lyg būtų vykdytos viena po kitos), tačiau labiausiai ribojantis lygiagretumui.

## Izoliavimo lygio nustatymas

```sql
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
BEGIN;
  -- ... operations run at the chosen isolation ...
COMMIT;
```

## Pagrindinė kompromisas

```text
Higher isolation → MORE correctness (fewer anomalies), but MORE locking/contention
                   → lower concurrency, potential slowdowns, more deadlocks
Lower isolation  → MORE concurrency/performance, but risk of anomalies
→ Choose based on the data's needs: financial/critical data may need Serializable;
  most apps use Read Committed (the default) as a balance.
→ Note: implementations vary (MVCC vs locking); the SQL standard defines the levels
  but databases differ in details (Postgres, MySQL/InnoDB, etc.).
```

## Kodėl tai svarbu

Transakcijų izoliavimo lygiai yra svarbus išplėstinis žinojimas, skirtas suprasti **lygiagretumą duomenų bazėse** — kai keliose transakcijos vykdamos vienu metu (kaip bet kurioje realybės daugiakorisninkėje aplikacijoje), izoliavimo lygiai nustato kompromisą tarp duomenų nuoseklumo ir našumo, todėl jų supratimas yra vertingas kuriant teisingus, efektyvius lygiagretaus vykdymo sistemos.

Pagrindinės koncepcijos yra **lygiagretaus vykdymo anomalijos** (dirty reads, non-repeatable reads, phantom reads — problemos, kurios atsiranda, kai transakcijos mato viena kitos vykdomus pokyčius) ir kaip **keturi izoliavimo lygiai** (Read Uncommitted, Read Committed, Repeatable Read, Serializable) palaipsniui prevencija jų daugiau.

Supratimas tai svarbu korektiškumui: per žemo izoliavimo lygio pasirinkimas gali leisti anomalijas, kurios gali sugadinti duomenis arba sudaryti klaidingus rezultatus (pvz., skaitymas nepatvirtintų duomenų, kurie vėliau grąžinami, arba nenuolatinį skaitymą), tuo tarpu per aukšto lygio pasirinkimas sumažina lygiagretumą ir našumą.

**Pagrindinė kompromisas** — aukštesnis izoliavimas reiškia didesnį nuoseklumą, tačiau daugiau blokavimo/konfliktų (mažesnis lygiagretumas, potencialūs sulėtimai ir deadlockai), žemesnis izoliavimas reiškia didesnį našumą, bet anomalijų riziką — yra raktinis įžvalgas: pasirenkate lygį pagal duomenų nuoseklumo reikalavimus (kritiniai/finansiniai duomenys gali reikalauti Serializable; daugelis aplikacijų naudoja Read Committed kaip balanso).

Žinoti, kad implementacijos skirasi (MVCC prieš blokavimą) taip pat aktualu.

Kadangi lygiagretumas yra neatsiejamas nuo realių duomenų bazės aplikacijų, ir kadangi izoliavimo lygiai valdo kritinį nuoseklumo ir našumo balansą (su klaidingais pasirinkimais sukeliant duomenų anomalijas arba našumo problemas), supratimas izoliavimo lygių — anomalijų, lygių ir nuoseklumo prieš lygiagretumą kompromiso — yra vertingas aukščiausio lygio žinojimas kuriant teisingus, efektyvius lygiagretaus vykdymo sistemas ir dažnas išplėstinis interviu klausimas, kuris demonstruoja duomenų bazės lygiagretomo supratimą.