공통 질문
데이터 불일치 문제 발생
1. Dirty read
2. Non-repeatable read || Fuzzy read
3. Phantom read
ANSI SQL에서 정의된 격리 수준 4단계
1. READ UNCOMMITTED
2. READ COMMITTED
3. REPEATABLE READ
4. SERIALIZABLE
기존 논문 비판
1. Dirty Write
2. Lost Update
3. Read skew
4. Write skew
5. dirty read 다른 예제
6. Phantom read 다른 예제
추가 격리 수준
snapshot isolation
실무에서 isolation level
1. mysql
2. oracle
3. sql server
4. postgreSQL
출처:
https://www.youtube.com/watch?v=bLLarZTrebU
데이터 불일치 문제 발생
1. Dirty read
commit하지 않은 데이터를 읽어서 데이터에 문제가 발생함
유효하지 않은 값을 읽어서 commit함
2. Non-repeatable read || Fuzzy read
x의 값이 읽을 때 마다 변경됨
3. Phantom read
없던 데이터가 생김
데이터 불일치를 해결하려면, db성능이 낮아진다.
Isolation Level (격리 수준)
- application 설계자는 isolation level을 통해, 전체 처리량, 데이터 일관성 사이에서 trade를 할 수 있다.
- 데이터베이스 트랜잭션이 다른 트랜잭션과 얼마나 격리될 것인지를 결정하는 설정.
- 읽기(Read)와 쓰기(Write)가 동시에 수행될 때 **동시성 제어(Concurrency Control)**를 위해 사용됨.
ANSI SQL에서 정의된 격리 수준 4단계:
READ UNCOMMITTED → 읽기와 쓰기가 완전히 허용됨(Dirty Read 가능).
READ COMMITTED → 쓰기 중인 데이터를 다른 트랜잭션에서 읽지 못함.
REPEATABLE READ → 읽는 동안 다른 트랜잭션이 해당 데이터를 변경할 수 없음.
SERIALIZABLE → 완전한 트랜잭션 격리(가장 높은 수준).
기존 논문 비판
1. Dirty Write
rollback 시 정상적인 recovery는 매우 중요하기 때문에, 모든 isolation level에서는 dirty write를 허용하면 안된다.
transaction2가 commit까지했어도, transaction1에 의해서 값이 변경됨.
2. Lost Update
transaction2 내용이 사라짐
3. Read skew
inconsistent한 데이터 읽기
데이터의 정합성이 깨짐
4. Write skew
제약 사항 위반함
5. dirty read 다른 예제
abort가 발생하지 않아도, dirty read가 발생할 수 있다
데이터의 정합성이 깨짐
6. Phantom read 다른 예제
팬텀 리드가 발생하는 확장적으로 바라보자
읽은 값이 달라졌던 것을 팬텀 리드라고 한다
transaction1에서 cnt 0으로 와야하는데 1로 리턴옴
isolation level 추가
+ snapshot isolation
lost update가 발생하겠지..
y값이 다르네? abort함
실무에서 isolation level
개발자는 사용하는 RDBMS의 isolation level을 잘 파악해서, 적절한 isolation level을 사용 해야 한다.
1. mysql
4개 제공
2. oracle
실제적으로 read committed, serializable 두개만 가능
serializable: snapshot 처럼 작동함
3. sql server
4. postgreSQL
repeatable read : snapshot isolation
출처: https://www.youtube.com/watch?v=DwRN24nWbEc
schedule
여러 transaction들이 동시에 실행될 때, 각 transaction에 속한 operation들의 실행 순서
- 각 transaction 내의 operation들의 순서는 바뀌지 않는다
Serial schedule
- transaction들이 겹치지 않고, 한 번에 하나씩 실행되는 schedule
성능
- 한번 수행할때 하나의 transaction만 수행한다
Non-Serial schedule
- transaction들이 겹쳐서 실행되는 schedule
성능
단점
Conflict
read-write conflict
write-write conflict
conflict equivalent
스케쥴3, 스케쥴2는 conflict equvalent 하다!
Conflict serializable
스케쥴2: serializable schedule
스케쥴3: non-serializable schedule
스케쥴4, 스케쥴2는 순서가 다름
순서의 역전
출처: https://www.youtube.com/watch?v=89TZbhmo8zk
Un-recoverable schedule
- 회복 불가능하기 때문에 애초에 허용하면 안된다
Recoverable schedule
- schedule 내에서 그 어떤 transaction도 자신이 읽은 data를 write한 transaction이
- 먼저 commit/rollback하기 전까지는 commit하지 않는다
의존성이 있을때
Cascading rollback
- 하나의 transaction이 rollback을 하면, 의존성이 있는 다른 transaction도 rollback을 한다
Cascadeless schedule
- schedule 내에서 어떤 transaction도 commit되지 않은 transaction들이 write한 data를 읽지 않는다
개선 전
개선 후
Cascadeless schedule 문제점
Strict schedule
- rollback 할때, recovery가 쉽다
- transaction 이전 상태로 돌려놓기만 하면 된다
읽기 전용(Read-Only Mode)
- 데이터베이스가 쓰기 작업을 허용하지 않고 읽기만 가능하도록 설정.
- 주로 백업용 DB, 보고서용 DB(Read Replica)에서 사용.
읽기-쓰기(Read-Write Mode)
기본적인 DB 모드로, 읽기 및 쓰기 작업이 모두 가능.
읽기/쓰기 설정을 활용한 DB 운영 방식
Primary-Replica 구조 (Master-Slave)
- Primary(또는 Master) → 읽기/쓰기 가능.
- Replica(또는 Slave) → 읽기 전용.
- 트래픽이 많은 경우 읽기 전용 Replica를 추가하여 부하를 분산.
- MySQL, PostgreSQL에서 흔히 사용됨.
Multi-Master Replication
- 여러 개의 DB 인스턴스가 모두 읽기/쓰기 가능.
- 분산 데이터베이스 환경에서 사용 (예: Galera Cluster, CockroachDB)
SQLite WAL(Write-Ahead Logging) 모드
- 기본적으로 SQLite는 읽기와 쓰기를 동시에 할 수 없지만, WAL 모드를 사용하면 읽기/쓰기 병행 가능.
'학습 기록 (Learning Logs) > CS Study' 카테고리의 다른 글
| database (0) | 2025.02.06 |
|---|---|
| transaction (0) | 2025.02.03 |
| SQLite (0) | 2025.02.03 |
| Tree (0) | 2025.02.03 |
| WAL(Write-Ahead Logging) (0) | 2025.02.03 |
