Mik a tranzakció izolációs szintek?

Question

Accepted Answer

**Az izolációs szintek** azt szabályozzák, hogy az egyidejűleg futó tranzakciók mennyire láthatnak egymás el nem véglegesített (vagy folyamatban lévő) változásaiból — **konzisztenciát** cserélnek **teljesítményre/párhuzamosságra**. A magasabb izolációs szint több anomáliát előz meg, de nagyobb zárolást/versenyt okoz.

## A párhuzamosságból eredő anomáliák (amit az izolálás megelőz)

```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)
```

Ezek azok a problémák, amelyek akkor fordulhatnak elő, amikor tranzakciók egyidejűleg futnak — az izolációs szintek azt szabályozzák, hogy ezek közül melyeket előzzük meg.

## A négy standard izolációs szint

Minden magasabb szint több anomáliát előz meg. A **Read Committed** egy közös alapértelmezett beállítás (megelőzi a piszkos olvasásokat); a **Serializable** a legszigorúbb (a tranzakciók úgy viselkednek, mintha egymás után futottak volna) de a párhuzamosságra a legjobban korlátozó.

## Az izolációs szint beállítása

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

## Az alapvető kompromisszum

```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.).
```

## Miért fontos

A tranzakció izolációs szintek fontos haladó ismeretek az **adatbázis párhuzamosságának** megértéséhez — amikor több tranzakció fut egyidejűleg (ahogyan bármely valós, többfelhasználós alkalmazásban megtörténik), az izolációs szintek határozzák meg az adatok konzisztenciája és a teljesítmény közötti kompromisszumot, így az értelmük fontos az olyan helyes és teljesítményes egyidejű alkalmazások építéséhez.

Az alapfogalmak a **párhuzamosságból eredő anomáliák** (piszkos olvasások, nem megismételhető olvasások, fantom olvasások — azok a problémák, amelyek akkor keletkeznek, amikor a tranzakciók egymás folyamatban lévő változásait látják) és az, hogy a **négy izolációs szint** (Read Uncommitted, Read Committed, Repeatable Read, Serializable) hogyan előzik meg fokozatosan egyre több anomáliát.

A helyességhez fontos ennek az értelmezése: túl alacsony izolációs szint választása olyan anomáliákat engedhet meg, amelyek az adatokat megsértheti vagy helytelen eredményeket adhatnak (például nem véglegesített adatok olvasása, amelyek később visszagörgülnek, vagy inkonzisztens olvasások), míg túl magas szint kiválasztása csökkenti a párhuzamosságot és a teljesítményt.

A **alapvető kompromisszum** — magasabb izolálás több helyességet jelent, de több zárolást/versenyt (alacsonyabb párhuzamosság, lehetséges lelassulások és holtpontok), az alacsonyabb izolálás több teljesítményt jelent, de anomáliák kockázatát — ez a legfontosabb meglátás: az adatok konzisztencia követelményei alapján választja meg a szintet (kritikus/pénzügyi adatok Serializablet igényelhetnek; a legtöbb alkalmazás a Read Committedet használja egyensúlyként).

Az is fontos, hogy az implementációk eltérnek (MVCC vagy zárolás).

Az egyidejűség az igazi adatbázis-alkalmazások jellegzetessége, és mivel az izolációs szintek az konzisztencia és a teljesítmény közötti kritikus egyensúlyt szabályozzák (a helytelen választások vagy adatanomáliákat vagy teljesítményproblémákat okoznak), az izolációs szintek megértése — az anomáliák, a szintek és a konzisztencia-teljesítmény kompromisszum — értékes senior szintű ismerete a helyes, teljesítményes egyidejű rendszerek építésének, és egy gyakori haladó interjúkérdés, amely az adatbázis párhuzamosságáról való megértést bizonyítja.