트랜잭션 ACID
atomicity(원자성)
트랜잭션이 모두 실행하거나 모두 실행되지 않아야 함.
consistency(일관성)
트랜잭션 이전과 이후의 결과가 항상 일관되어야 함.
durability(지속성)
커밋된 트랜잭션 결과는 DB에 영구적으로 저장되어야 함.
isolation(격리성)
여러 트랜잭션이 서로 영향을 주지않고 독릭접으로 실행되는 것 처럼 보여야함.
isolation level
트랜잭션이 얼마나 서로 간섭을 얼마나 안받는지를 나타내는 수준을 의미
dirty reads
commit되지 않은 데이터를 읽는 것을 의미
non-repeatable read
다른 트랜잭션이 commit한 데이터를 읽을 수 있음.
한 트랜잭션에서 같은 쿼리를 2번 이상 조회했을 때 데이터가 없거나 변경되었을 수 있음.
다른 트랜잭션에서 데이터의 수정/삭제가 발생했을 때 결과가 달라지는 현상
Phantom Read
한 트랜잭션에서 같은 쿼리를 2번 이상 조회했을 때 없었던 데이터가 조회되는 현상
보통 다른 트랜잭션에서 데이터 insert가 발생했을 때 결과가 달라지는 현상
Serializable
phantom read도 발생하지 않음.
트랜잭션이 동시에 수행되지 않고 순차적으로 실행되는 것처럼 동작함.
동시 처리가 불가능해 거의 사용되진 않음.
| isolation level | dirty reads | non-repeatable read | phantom read | serializtion anomaly |
| read uncommited | 발생 가능 | 발생 가능 | 발생 가능 | 발생 가능 |
| read committed | 발생 불가능 | 발생 가능 | 발생 가능 | 발생 가능 |
| repeatable read | 발생 불가능 | 발생 불가능 | 발생 가능 | 발생 가능 |
| serializable | 발생 불가능 | 발생 불가능 | 발생 불가능 | 발생 불가능 |
| 참고 PostgreSQL에서 repeatable read isolation level로 설정해서 사용하더라도 phantom read가 발생하지 않음. 이유는 아래에 나와있으며 잘 이해가 안될 경우 post한 글의 07,08,09,10을 모두 보고 다시 보길 바란다. https://www.interdb.jp/pg/pgsql05/07.html#572-phantom-reads-in-postgresqls-repeatable-read-level |
concurrency control
여러 트랜잭션이 동시에 수행될 때 원자성과 격리성을 유지해야함.
즉, 트랜잭션이 모두 실행되거나 모두 실패해야하고 여러 트랜잭션이 서로 영향을 주지않고 독립적으로 수행되어야 함을 의미
동시성 제어를 위한 다양한 기술이 있으며 몇가지를 적어봄.
Two-Phase Locking(S2PL)
한 transaction이 write할 때 다른 transaction이 동시에 데이터를 읽을 수 없음.
즉 wrtie하고 있는 transaction은 exclusive lock을 획득해야 함.
SI(Snapshot Isolation)
PostgreSQL과 몇몇 RDBMS에서만 MVCC 변형으로 사용 가능.
ANSI SQL-92 standard에 정의된 Dirty Reads, Non-Repetable Reads, Phanotm Reads 문제를 모두 허용하지 않는 것을 의미함.
그러나 SI는 write skew와 read-only transaction skew 같은 serialization 이상현상을 허용하기 때문에 완벽하게 해결할 수 없음.
SSI(Serializable Snapshot Isolation)
SI문제점을 개선하기 위해 PostgreSQL 9.1 version에 도입됨.
Dirty Reads, Non-Repetable Reads, Phanotm Reads 문제 및 write skew와 read-only transaction skew를 모두 해결.
즉, PostgreSQL 9.1부터는 완벽하게 SERIALIZABLE isolation level을 구현함.
참고
ORACLE은 여전히 SI까지 지원
MS SQL SERVER는 SSI까지 지원
Multi-Version Concurrency Control
각각의 트랜잭션이 변경되기 전 데이터를 유지하면서 새로운 데이터를 만들어야하는 것을 의미
즉, A transaction이 select로 데이터를 읽을 때 B transaction에서 A에서 읽은 데이터를 변경하여도 A의 트랜잭션이 아직 끝난 상태가 아니라면 B transaction이 변경한 데이터가 아닌 변경 전 데이터를 읽어야 함.
MVCC 주요 이점
데이터를 읽는 transaction과 데이터를 쓰는 transaction이 데이터 일관성이 깨지는 것을 막기 위해 상호 간에 접근을 막을 필요가 없음.
ORACLE과 PostgreSQL의 MVCC 구현 차이
oracle의 경우 undo segments에 변경 전 데이터를 저장함.
따라서 변경 전 데이터가 필요한 transaction이 있을 때 undo segments에 데이터가 있는지 조회해봄.
그러나 undo는 영구적으로 변경전 데이터를 보관해주지 않음.
즉, long running transaction 발생으로 undo에 변경 전 데이터가 지워지게 되면 ORA-01115 snapshot too old가 발생함.

PostgreSQL의 경우 data가 저장되는 page내 변경 전/후 데이터를 모두 저장함.
따라서 long running transaction이 수행되더라도 변경 전 데이터를 읽을 수 있음.
그러나 long running transaction으로 인해 지워져야할 tuple이 지워지지 않고 계속 쌓이게 되면서 table bloating이 발생할 수 있고 transaction wraparound 이슈도 발생할 가능성이 있음.

'PostgreSQL' 카테고리의 다른 글
| 08. PostgreSQL - commit log (2) | 2024.12.18 |
|---|---|
| 07. PostgreSQL - transaction처리 이해하기 (5) | 2024.12.17 |
| 04. PostgreSQL - tuple을 읽고 쓰는 방법 (4) | 2024.12.15 |
| 3. PostgreSQL - heap table file layout (5) | 2024.12.15 |
| 0. postgreSQL internal (1) | 2024.12.15 |