이쁘게 그림도 넣고 설명하고 싶지만 지금은 공부만 하는걸로도 시간이 부족하다.. 일단 설명만,,
데이터베이스 4가지 성질
ACID
- Atomicity 원자성 : 하나의 트랜잭션은 모두 반영되거나 모두 반영되지 않아야 한다.
- Consistency 일관성 : 동일한 규칙을 가지고 처리되어야 한다.
- Isolation 격리성 : 동시에 여러 트랜잭션이 실행되어도 각각 별개로 동작해야 한다.
- Durability 영속성 : 적용된 데이터는 영구적이어야 한다.
concurrency control 동시성 제어는 다음을 제공한다
- serializabiliy 직렬화가능성
- recoverabiliy 회복가능성
스케쥴 : 각 트랜잭션 내의 오퍼레이션(연산자)들의 순서(리드, 라이트, 커밋 등)
시리얼 스케쥴과 동일하게 동작하는 논시리얼 스케쥴은 실행하자!
그래서 그 동일하게(equivalent) 동작하는 논시리얼 스케쥴이 뭐지?
충돌(conflict)
- 두개의 오퍼레이션에 대해 아래의 세가지를 모두 만족하면 두 오퍼레이션은 conflict 하다는 것 = conflict operations 이다
1. 서로다른 트랜잭션 소속
2. 같은 데이터에 접근
3. 최소 하나는 라이트(쓰기) 오퍼레이션
콘플릭트 오퍼레이션은 순서가 바뀌면 결과도 바뀐다.
conflict equivalent
두개의 스케쥴이 아래의 두 조건을 모두 만족하면 충돌 관계가 같은 conflict equivalent 한 스케쥴이다 라는 것
1. 두 스케쥴은 같은 트랜잭션을 가진다
2. 두 스케쥴에서 모든 conflict operations 는 순서가 동일하다
conflict operations 가 있는 것 ok. 그 순서가 정상동작하는 스케쥴과 같다면 이 두 스케쥴은 conflict equivalent 하다!
여기서 만약 비교로 쓰였던 정상동작 스케쥴이 시리얼 스케쥴이라면 해당 논시리얼 스케쥴은 이 시리얼 스케쥴과 conflict equivalent 인 것이기 때문에 conflict serializable 하다!
conflict serializable 할 때 해당 논시리얼 스케쥴은 실행해도 되는 스케쥴이다.
unrecoverable schedule
복구불가 스케쥴
2번 트랜잭션 종료 전에 1번 트랜잭션이 그 결과를 읽고 커밋 했다. 그런데 2번이 문제가 생겨 롤백을 했다. 그래서 1번도 롤백을 해야 맞는건대 이미 commit을 해버려서 durability 속성에 의해 롤백이 불가능하다.
-> 2번 write, 1번 read, 1번 commit, 2번 rollback
이런 스케쥴은 DBMS가 실행하면 안된다.
그렇다면 recoverable schedule 은 어떤걸까
2번 write, 1번 read 하고 2번 트랜잭션을 먼저 끝내고(커밋이든 롤백이든) 1번을 끝내야 한다.(단 똑같이)
2번이 롤백한다면 1번도 롤백해야 하는것. 이것을 cascading rollback 이라고 함. 연쇄 롤백
하지만 두 트랜잭션을 모두 이전상태로 되돌려야하기 때문에 처리비용이 많이 듬.
그래서 2번 write, 1번 read 가 아니고 2번 write 하고 2번을 먼저 끝내고(커밋이든 롤백이든) 1번 read 를 하자. 이렇게 write가 다 끝나고 진행하는 것을 cascadeless schedule 이라고 함.
하지만 이는 write 후 read 에는 유효하지만 2번 write 커밋 후 1번 write 롤백이 일어나면 유효하지 않다. 그래서 write 후 read도 write도 하지 않는 schedule만 허용하는 것을 strict schedule 이라고 한다. 엄격한 스케쥴
lock을 통한 concurrency control 동시성 제어
write lock
- write 하려는 트랜잭션이 얻게 되며, 이 상태에서 다른 트랜잭션이 write나 read 를 할 수 없고 기다려야 한다.
read lock
- read 하려는 트랜잭션이 얻게 되며, write 트랜잭션은 기다려야 하지만 read 트랜잭션은 허용한다.(그 트랜잭션도 read lock을 얻음)
2PL(phase locking) protocol
- lock를 얻는 phase, lock를 반납하는 phase
- lock를 얻을땐 중간 반납 없이 얻기만 하고, 반납할땐 반납만 하는 것.
- serializabiliy 보장
- deadlock이 발생할 수 있음
Strict 2PL, Strong Strict 2PL
- recoverabiliy 도 보장되어 DB 초창기에 많이 사용
- read read 인 경우를 제외하고는 모두 한쪽이 block이 되어 기다려야하기때문에 비효율적이었음
여기서 read write, write read를 해결한게 MVCC multiversion concurrency control
멀티버전 동시성 제어.
- commit된 데이터만 읽음
- DB가 계속 데이터 변화(write) 이력을 저장해야하기 때문에 추가적인 저장공간을 사용하게 된다.
- 스냅샷 isolation은 이 MVCC의 한 종류이다.
- RW, WR 가 가능하기 때문에 여러 트랜잭션을 좀 더 빨리 처리할 수 있으므로 성능이 좋음
오늘날 대부분의 RDBMS는 MVCC를 사용함
트랜잭션마다 isolation레벨을 다르게 줄 수 있다
read uncommitted : 다른 트랜잭션이 중간에 데이터를 바꾸고 커밋하기 전이어도 바뀐 데이터를 읽는다
read committed : 다른 트랜잭션이 중간에 데이터를 바꾸고 커밋하면 커밋한 데이터를 읽는다
repeatable read : 다른 트랜잭션이 중간에 데이터를 바꿔고 커밋해도 커밋 전 최초 데이터로 읽는다
serializable : 모든 트랜잭션을 순차적으로 실행하고, 동시에 실행되는 트랜잭션이 없도록 한다
postgreSQL은 트랜잭션 isolation 레벨이 repeatable read 이면 먼저 commit한 트랜잭션만 적용되고 그 다음 트랜잭션의 update는 rollback된다. 그래서 결론적으로 하나의 트랜잭션만 적용되고 다른 트랜잭션은 다시 시도한다.
오라클은 두번째를 롤백하는 룰이 없기때문에 locking read 사용으로 해결. read할때에도 write lock을 얻는 것. 개발자가 쿼리 마지막줄에 FOR UPDATE; 추가해야함!
locking read를 사용할때는 isolation 레벨이 repeatable read여도 최초의 데이터를 읽는게 아니라 commit된 데이터를 읽는다.
참고
https://www.youtube.com/watch?v=sLJ8ypeHGlM&list=PLcXyemr8ZeoREWGhhZi5FZs6cvymjIBVe&index=14&pp=iAQB
https://www.youtube.com/watch?v=DwRN24nWbEc&list=PLcXyemr8ZeoREWGhhZi5FZs6cvymjIBVe&index=15&pp=iAQB
https://www.youtube.com/watch?v=0PScmeO3Fig&list=PLcXyemr8ZeoREWGhhZi5FZs6cvymjIBVe&index=18&pp=iAQB
https://www.youtube.com/watch?v=wiVvVanI3p4&list=PLcXyemr8ZeoREWGhhZi5FZs6cvymjIBVe&index=19&pp=iAQB
https://www.youtube.com/watch?v=-kJ3fxqFmqA&list=PLcXyemr8ZeoREWGhhZi5FZs6cvymjIBVe&index=20&pp=iAQB
'DB' 카테고리의 다른 글
| [DB] 인덱스, unique index, multicolumn index, hash index (0) | 2024.03.19 |
|---|---|
| [DB] super key, candidate key, primary key, unique key, 1NF, 2NF, 3NF, BCNF (0) | 2024.03.18 |
| [DB] 스키마가 뭔데? (0) | 2024.02.14 |
| [postgreSQL] row_number(), rank(), dense_rank(), partition by (0) | 2024.01.17 |
| [postgreSQL] 포스트그레스 기본 명령어 실습해보기 (0) | 2024.01.09 |
댓글