데이터베이스
트랜잭션
데이터 무결성
데이터 무결성을 유지하기 위해 해결해야 할 문제들
- Atomic operation
- Concurrency control(병행제어)
- 장애후 Recovery(회복)
consistent status - 데이터 무결성이 유지되어 데이터베이스 안의 데이터 간의 모순점이 없는 상태
- 일시적으로 inconcurrency가 발생할 수 있으나 결국은 일관된 값으로 유지되어야 함
➡️ 트랜잭션은 데이터 무결성을 지킴으로써 데이터베이스를 일관된 상태(consistent status)를 유지하기 위한 핵심 개념이다.
ACID : 트랜잭션의 특성
🔸 Atomicity : 트랜잭션안의 모든 operation이 실행되거나, 실패
중간에 있던 operation들이 성공하면 commit을 하고 commit을 하면 결과가 보여, 실패한게 있으면 rollback하여 원복됨
🔸 Consistency : 트랜잭션의 실행이 database의 무결성 유지
🔸 Isolation : 동시에 실행되는 트랜잭션은 모두 독립적인다.(또는 순차적으로 실행)
🔸 Durability : 성공적으로 수행된 Transaction은 영원히 반영되어야 함을 의미
장애나 리커버리를 해도 반영이 되어야함
Active에서 시작
트랜잭션 스케쥴
데이터베이스의 consistenet status를 유지하기 위해 동시에 실행되는 트랜잭션들의 operation을 정하는 것을 말한다
Serial or Serializable schedules
정확한 결과를 만드는 두 스케쥴은 serial schedule
- 한 트랜잭션의 모든 operation이 끝난 후에 다른 트랜잭션이 시작
- serial schedule은 항상 consistent한 결과를 생성
- 순차적 실행으로 Throughput이 좋지않음(한 트랜잭션 안에 많은 operation들이 있을텐데 이 operation들이 동시에 수행될 수 없고 한 트랜잭션이 종료되어야 다른 트랜잭션이 수행된다는 것은 concurrency 수행이 안된다는 거야 그래서 throuhgput이 떨어짐)
serializable schedule
위의 문제점을 보안하고자 serial schedule과 결과는 동일하지만 serializable하지 않는 스케쥴을 serializable schedule이라고 한다.(모든 operation을 serial하게 시행시키지 않는)
serializable을 계산하기 위한 두가지 개념
- conflict serializability
- view serializability
Conflicr Serializability
conflict Operations : 두 operation이 다음 조건을 만족할때 conflicting이라 할 수 있다.
- 두 개의 다른 트랜잭션에 속해있고
- 같은 데이터에 대한 operation이며
- 적어도 하나의 operation이 write인 경우
위 예제에서 Write가 적어도 하나가 포함되어 있고 같은 데이터(A)에 대한 operation을 가지는S1,S2,S3이Conflicting하고,S4,S5는non-conflict하다. - conflict serializable : non-conflict operation들의 순서 바꿈으로(swap)에 의해 serial schedule로 변환이 되는 스케쥴
View Serializability
View Equilvalent : 다음 조건들을 만족할 때 스케쥴 S1과 S3가 view equivalent하다고 한다.
1. 스케쥴 안의 트랜잭션들 중에 하나의 트랜잭션이 같은 초기값을 읽어야 한다.
2. 만약 S1에서 T1이 T2가 write한 값을 읽는 다면, S2에서도 T1이 T2가 write한 값을 읽어야 한다.
3. 마지막 write는 같은 transaction에서 이루어져야 한다.
View serializable
- serial 스케쥴과 view equivalent한 스케쥴
- conflict serializable인 스케쥴을 포함
Recoverability
복구 가능한 스케쥴(Recoverable Schedule)
- 스케쥴은 serializable하고 복구 가능해야 한다.
- T2가 T1에 의해 바뀐 데이터를 사용할 경우 T1이 commit되기 전에 T2는 commit하면 안된다.
➡️ 만약 T1이 abort되면 T2도 abort된다. - Cascading Schedule
T1 ➡️ T2 ➡️ T3 ➡️ T4 순서로 데이터가 사용될 때 만약 T1이 실패하면 모든 트랜잭션이 실패 - Cascading Rollback
➡️ cascading schedule은 복구 불가능한 스케쥴을 만든다.
➡️ cascade-less 스케쥴 : 다른 트랜잭션들은 commit후에 변경된 데이터 read - cascade-less 스케쥴은 recorable한 스케쥴이다.
DB쪽 강의는 오늘 처음 듣는데, 말을 좀 횡설수설하시는 듯.. 말이 잘 이해가 안되서 같은말을 여러번 돌려봤다.
https://bit.ly/3FVdhDa
본 포스팅은 패스트캠퍼스 환급 챌린지 참여를 위해 작성되었습니다.
