새로운 내용을 공부할 때
새로운 내용의 공부를 시작할 때 용어의 정의를 이해하지 못하거나 정확하게 알지 못한다면 그 용어가 포함된 문장을 이해하지 못합니다.
작은 단어 하나가 내용을 이해하지 못하게 하기 때문에 용어를 정확하게 이해하는 것이 중요합니다.
concurrency control 기초 2편
목표 D-day : 34 일
학습할 키워드Permalink
- recoverable schedule
- cascadeless schedule
- strict schedule
- durability(내구성) 속성
복습Permalink
-
schedule
여러 트랜잭션들이 동시에 실행될 때 각 트랜잭션에 속한 Operation들의 실행 순서
데이터베이스에서 실행되어야할 연산들의 실행 순서
-
serializability
트랜잭션을 순차적으로 실행하는
serial
스케줄은 예상한 결과를 만들어내지만 성능상의 한계가 있습니다.한계 이유: CPU가 트랜잭션이 완료될때까지 대기하는 상황이 발생
성능을 높이기 위해 여러 트랜잭션을 비직렬 실행하되,
serial
스케줄과 동일한 결과를 얻는 스케줄이conflict serializability
입니다.conflict serializability
를 판단하는 방식은 트랜잭션 간 충돌 연산(conflict operation
)이 모두 동일한지 비교하는 것이러한
conflict serializability
를 보장하는 것이concurrency control
의 주요 목적입니다.concurrency control의 환경을 만들어주는 방법이
isolation
이며 개발자가 성능과 동시성을 고려하여 선택하도록 만든 방법이Isolation level
입니다.
상황 1Permalink
트랜잭션 | 시간 | 연산 | 설명 |
---|---|---|---|
Transaction 1 (둘리) | 16:00 | read(둘리_balance) => 100만원 |
둘리의 잔액을 읽어 100만원을 확인 |
Transaction 1 (둘리) | 16:01 | write(둘리_balance = 80만원) |
20만원을 차감하여 80만원으로 갱신 |
Transaction 2 (희동이) | 16:02 | read(희동이_balance) => 200만원 |
희동이의 잔액을 읽어 200만원을 확인 |
Transaction 2 (희동이) | 16:03 | write(희동이_balance = 230만원) |
30만원을 추가하여 230만원으로 갱신 |
Transaction 1 (둘리) | 16:04 | read(희동이_balance) => 230만원 |
갱신된 희동이의 잔액 230만원을 확인 |
Transaction 1 (둘리) | 16:05 | write(희동이_balance = 250만원) |
20만원을 추가하여 250만원으로 갱신 |
Commit | 16:05 | commit |
트랜잭션 1을 커밋 |
Abort | 16:07 | abort |
트랜잭션 2가 롤백 |
정리
희동이가 자기 계좌에 30만원을 입금하는 트랜잭션 2가 실행됨
- 희동이는 자기 계좌의 잔액 조회 결과 200만원
- 희동이는 자기 계좌에 30만원을 입금함 결과 (200+30)만원
둘리가 희동이 계좌에 20만원을 입금하는 트랜잭션 1이 실행됨
- 희동이 계좌의 잔액을 조회 결과 230만원
- 희동이 계좌에 20만원을 입금함 결과 (230+20)만원
트랜잭션 2가 오류가 발생하여 롤백이 발생함.
- 롤백으로 트랜잭션 2가 취소되어 희동이 계좌에 입금하는 연산이 실행이 안된 상태로 돌아가야함
트랜잭션 2는 더이상 유효한 작업이 아니므로 트랜잭션 2가 작업한 결과를 읽은 트랜잭션 1도 롤백처리해야합니다.
하지만 트랜잭션 1은 이미 commit
된 상태이므로 durability
속성때문에 롤백처리를 할 수 없습니다.
durabilityPermalink
트랜잭션이 성공적으로 완료되고 커멧된 이후에는 시스템 장애나 오류가 발생해도 그 트랜잭션의 결과가 영구적으로 보존되는 것을 보장하는 특성입니다.
즉 트랜잭션이 커밋된 이후에는 데이터가 안전하게 저장되며, 시스템에 문제가 발생해도 데이터의 일관성을 보장합니다.
즉 한번 커밋된 결과는 롤백이 될 수 없습니다.
Unrecoverable schedulePermalink
되찾을 수 없는, 회복 불능의 스케줄
트랜잭션 2의 유효하지 않은 결과를 조회하여 커밋한 트랜잭션 1의 경우에는 이전 상태로 회복 불가능하기 때문에 이런 스케줄은 DBMS가 허용하면 안됩니다.
정리Permalink
unrecoverable schedule은 트랜잭션이 유효하지 않은 다른 트랜잭션의 데이터를 읽고 쓰는 작업을 커밋한 경우를 말하며, durability(내구성)
속성으로 무효화할 수 없는 상태를 말합니다.
유효하지 않은 데이터를 사용한 경우 회복 가능한 스케줄이 되도록 하면 된다.
Recoverable schedulePermalink
회복 가능한 스케줄
트랜잭션 | 시간 | 연산 | 설명 |
---|---|---|---|
Transaction 1 (둘리) | 16:00 | read(둘리_balance) => 100만원 |
둘리의 잔액을 읽어 100만원을 확인 |
Transaction 1 (둘리) | 16:01 | write(둘리_balance = 80만원) |
20만원을 차감하여 80만원으로 갱신 |
Transaction 2 (희동이) | 16:02 | read(희동이_balance) => 200만원 |
희동이의 잔액을 읽어 200만원을 확인 |
Transaction 2 (희동이) | 16:03 | write(희동이_balance = 230만원) |
30만원을 추가하여 230만원으로 갱신 |
Transaction 1 (둘리) | 16:04 | read(희동이_balance) => 230만원 |
갱신된 희동이의 잔액 230만원을 확인 |
Transaction 1 (둘리) | 16:05 | write(희동이_balance = 250만원) |
20만원을 추가하여 250만원으로 갱신 |
Abort | 16:05 | abort |
트랜잭션 2가 롤백 |
Commit | 16:07 | commit |
트랜잭션 1을 커밋 |
트랜잭션 1의 연산(갱신된 희동이의 잔액 230만원을 조회)은 트랜잭션 2의 희동이 입금 결과를 의존합니다.
트랜잭션 1의 희동이 입금 작업은 트랜잭션 2의 입금이 유효해야합니다.
따라서 트랜잭션 1은 트랜잭션 2의 결과가 Roll Back
이면 트랜잭션 1 작업도 Roll Back
처리하면 되고,
트랜잭션 2의 결과가 Commit
이면 트랜잭션 1 작업도 Commit
을 하면 회복 가능한 스케줄이 됩니다.
스케줄 내에 그 어떤 트랜잭션도 자신이 읽은 데이터(공유)를
write
한 트랜잭션이 먼저commit/rollback
전까지는commit
하지 않는 경우를 말합니다.
다시 정의Permalink
durability
속성으로 트랜잭션이 커밋이 되면 이전 상태로 되돌 수 없습니다.
- 트랜잭션 1은 트랜잭션 2의 결과를 의존합니다.
- 트랜잭션 2가 정상처리, 오류처리가 되기전에 트랜잭션 1이 커밋을 하면
unrecoverable schedule
이 됩니다.- 트랜잭션 1이 커밋이 되어 되돌릴 수 없기 때문에 회복이 불가능합니다.
- 트랜잭션 2가 처리에 따라 트랜잭션 1의 결과가 달라지면
coverable schedule
이 됩니다.- 트랜잭션 2가 롤백이되면 트랜잭션 1도 롤백이 되어 회복된 스케줄입니다.
Cascading rollbackPermalink
선행 트랜잭션이 롤백하면 후행 트랜잭션도 롤백해야하는 것을 casading rollback 이라고 합니다.
여러 트랜잭션의 롤백이 연속적으로 일어나면 처리하는 비용이 많이 듭니다.
여러가지 이유가 있지만 수 많은 작업을 이전 상태로 되돌리는 과정에 발생하는 I/O로 리소스가 발생하며,
CPU,메모리등도 한꺼번에 상당한 자원을 소비하게 됩니다. 이전 상태로 되돌리는 과정에 발생하는 락으로 인해 데드락이 발생할 수 있습니다. 롤백하는 과정에 락이 오래 시스템 성능이 떨어지게 됩니다.
Cascadeless schedulePermalink
데이터를 write 연산이 있는 트랜잭션이 commit/rollback 한 뒤에 데이터를 읽는 스케줄만 허용하는 방법이 있습니다.
트랜잭션 | 시간 | 연산 | 설명 |
---|---|---|---|
Transaction 1 (둘리) | - | read(둘리_balance) => 100만원 |
둘리의 잔액을 읽어 100만원을 확인 |
Transaction 1 (둘리) | - | write(둘리_balance = 80만원) |
20만원을 차감하여 80만원으로 갱신 |
Transaction 2 (희동이) | - | read(희동이_balance) => 200만원 |
희동이의 잔액을 읽어 200만원을 확인 |
Transaction 2 (희동이) | - | write(희동이_balance = 230만원) |
30만원을 추가하여 230만원으로 갱신 |
Commit | - | commit |
트랜잭션 2를 커밋 |
Transaction 1 (둘리) | - | read(희동이_balance) => 230만원 |
갱신된 희동이의 잔액 230만원을 확인 |
Transaction 1 (둘리) | - | write(희동이_balance = 250만원) |
20만원을 추가하여 250만원으로 갱신 |
Commit | - | commit |
트랜잭션 1를 커밋 |
스케줄 내에서 어떤 트랜잭션도 commit 되지 않은 트랜잭션들이 write
한 데이터를 읽지 않은 경우를 말합니다.
avoid cascading rollback 이라고 합니다.
비교Permalink
-
cascading schedule은 선행 트랜잭션이 write한 공유 데이터를 읽을 수 있습니다.
cascadeless schedule은 선행 트랜잭션이 write한 공유 데이터를 읽지 않습니다.
-
cascading schedule은 선행 트랜잭션 rollback 한 경우 해당 데이터를 읽은 트랜잭션은 연속된 롤백이 발생합니다.
cascadeless schedule은 선행 트랜잭션이 write한 경우 롤백이 되거나 커밋이 되기전까지 데이터를 읽지 않으므로 롤백이 발생하지 않습니다.
cascadeless의 문제Permalink
트랜잭션 | 시간 | 연산 | 설명 |
---|---|---|---|
price = 3만원 |
|||
Transaction 1 (둘리) | - | write(price = 1만원) |
가격을 1만원으로 설정 |
Transaction 2 (희동이) | - | write(price = 2만원) |
가격을 2만원으로 변경 |
Transaction 2 (희동이) | - | commit |
트랜잭션 2가 커밋되어 반영됨 |
Transaction 1 (둘리) | - | abort |
트랜잭션 1이 중단되어 트랜잭션 2의 결과 삭제 |
결과 | - | 가격 = 3만원 |
초기 가격으로 돌아감 |
cascadeless
방식은 스케줄 내에 어떤 트랜잭션도 commit
되지 않은 트랜잭션들이 write
한 데이터는 읽지 않지만 조회하지 않고 수정하는 경우에는 문제가 발생하게 됩니다.
이런 문제를 해결하기 위해서는 트랜잭션들이 write한 데이터는 쓰지도 않고 읽지도 않게 하면 됩니다.
strict schedulePermalink
트랜잭션 | 시간 | 연산 | 설명 |
---|---|---|---|
price = 3만원 |
|||
Transaction 1 (둘리) | - | write(price = 1만원) |
가격을 1만원으로 설정 |
Transaction 1 (둘리) | - | commit/abort |
트랜잭션 1이 롤백 혹은 커밋 |
Transaction 2 (희동이) | - | write(price = 2만원) |
가격을 2만원으로 변경 |
Transaction 2 (희동이) | - | commit |
트랜잭션 2가 커밋 |
strict schedule
은 스케줄 내에 어떤 트랜잭션도 커밋되지 않은 트랜잭션들이 쓰기 작업한 공유 데이터는 쓰지도 읽지도 않는 방식입니다.
장점Permalink
strict schedule
은 롤백할 때 recovery가 쉽습니다. 트랜잭션 이전 상태로 되돌리기만 하면 됩니다.
트랜잭션 1이 롤백이 되면 가격은 3만원 상태로 되돌아가고 트랜잭션 2가 실행되어 가격은 2만원이 됩니다.
트랜잭션 2가 롤백이 되어도 트랜잭션 1이 커밋이 되었다면 가격은 1만원인 상태가 됩니다.
정리Permalink
unrecoverable schedule
recoverable schedule
- sacading schedule
- cascadeless schedule
- strict schedule
어떤 스케줄이 다른 트랜잭션이 write한 데이터가 commit 되기전까지 완료하지 않는 것을 recoverable 스케줄이라고 합니다
혹은 recoverability 하다고 합니다.
concurrency control은 serializability 와 recoverability 를 제공합니다.
이와 관련된 트랜잭션 속성이 Isolation입니다.
댓글남기기