Previous chapter
Transaction Concept
Transaction은 데이터에 액세스하거나 새로운 값을 갱신할때 실행하는 프로그램 실행단위다
//transfer $50 from A to B
Ti: read(A);
A := A-50;
write(A);
read(B);
B:= B + 50;
write(B);
C
복사
가장 대표적인 예제.
A의 돈이 빠져나가는 것과 B의 돈이 추가되는 것이 반드시 같은 단계 안에서 일어나야 한다.
즉, A와 B의 sum이 같도록 만들어야 한다.
즉, Ti는 문제가 생겨서 돈이 보내지지 않거나 연산이 완료되어 송금이 완료되거나 둘 중의 하나의 상태만 가져야한다. 다른 상태는 가질 수 없다.
이때 Transaction을 사용하여 하나의 연산으로 묶어줘야한다.
Hardware Failure : 하드웨어에서 문제가 생기는 경우,
System Crashes : 시스템에서 오류가 생기는 경우
이런 에러에서 데이터를 망가뜨리지 않고 잘 보존할 수 있어야 한다.
또한 여러개의 Transaction를 동시에 실행시킬 때의 처리 순서를 어떻게 다룰지도 생각해야 한다.
DB안에서 transaction은 하나의 연산단위이다.
Example of Fund Transaction
//transfer $50 from A to B
Ti: read(A);
A := A-50;
write(A);
read(B);
B:= B + 50;
write(B);
C
복사
transaction이 아닐 경우
이때 Transaction은 Atomicity를 보장해야한다.
•
Transaction이 스텝3까지만 실행되고 연산 실패가 일어날 경우, A의 돈만 증발한다.
•
즉, A와 B가 모두 값이 변화하거나 그렇지 않은 경우만 원해야 한다.
또한 Durability를 보장해야한다.
•
Transaction 연산이 완료되었다면, 영속적인 저장장치에 반드시 저장해야한다.(하드디스크 같은 저장장치)
Transaction은 Consistency를 유지해야한다.
A에 500, B에 800이 있다고 생각하자.
•
integrity Constraints
Isolation requirement
T1와 T2 둘다 A와 B의 값을 보고 싶을 때, Isolation은 Transaction을 (Serialization)
ACID Principles
Atomicity
Transaction이 모두 정상적으로 수행되거나, 그렇지 않거나 둘 중 하나의 상태만 가
Consistency
데이터의 일관성을 보존해야한다.
Isolation
Tranasaction 중간에 수행되는 연산은 다른 Transaction이 볼 수 없어야 한다.
Durability
Transaction 후에 반드시 물리 저장장치에 저장해야한다.
Transaction State
•
Active : 최초의 상태, Transaction이 수행될 때 상태.
•
Partially Commited : 최종 연산이 끝나고 난 후의 상태
•
Failed : Transaction이 수행될 때
•
Aborted : Transaction이 롤백 된 이후의 상태
◦
Transaction 재시작
◦
Kill Transaction
•
Committed : Completion이후 ?
Concurrent Execution
복수의 Transaction이 동시에 실행될 때의 장점은 다음과 같다.
•
프로세서의 코어와 디스크의 효율이 늘어난 Transaction의 Throughput을 낫게 만들어준다.
•
응답시간이 줄어든다.
Concurrency Control Schemes : Isolation을 만족하기 위한 메커니즘
Schedules
스케쥴링은 많은 transaction을 순서를 유지하면서 동시에 실행할 수 있는지에 대한 방법이다.
가장 중요한 전제조건은 연산들끼리 반드시 수행순서를 보장해야한다.
Transaction에서 에러를 탐지할 수 있는 조건무
Serial Schedules
T1이 정상적으로 끝난 이후, T2가 뒤따라서 실행되는 직렬 구조이다.
또는 T2이후, T1이 실행된다.
이처럼 하나의 연산이 모두 끝난 이후, 다른 연산이 실행되는 구조를 직렬 스케쥴이라고 한다.(Serial Schedules)
T1와 T2모두 위 3줄은 A, 밑 3줄은 B에 대한 연산이다. 따라서 이에 대해 분리가 일부분 가능할 것이다.
즉, T1의 A연산 이후 T2의 A연산이 실행된다고 해도 이는 첫번째 직렬 연산과 Equivalent한 연산이 될 것이다.
즉 해당 연산은 직렬(하드한)은 아니나 직렬의 성질을 띄고 있다.
다음과 같은 경우는 Serializable하지 않다.
Serializability
Transaction의 순서를 바꾸더라도 기존 Serial Schedule과 결과값이 같다면 Serializable Schedule이라고 한다.
•
conflict Schedule : 엄격한 Serializable
•
View Schedule : 조금 유연한 Serializable
Simplified View of Transaction
결과적으로는 read와 write인스트럭션이 가장 중요함.
내부적으로 일어나는 Computation은 로컬 버퍼에서 cjflehlsek.
Conflicting Instruction
기본적으로 Conflict이 발생하는 조건은 write가 하나라도 들어간 경우이다.
write가 들어가는 순간 데이터의 값이 시점에 따라 달라지기 때문이다.
따라서 conflict는 Transaction간의 순서를 강제한다.
만약 두 Transaction이 conflict하지 않는다면 순서를 바꿔도 무방할 것이다.
Conflict는 Transaction간의 순서를 강제한다. 이들간의 order이 깨지는 순간 데이터의 Consistency가 보장되지 않는다.
Conflict Serializability
스케쥴 S가 S’으로 변경이 가능할 때, 이를 Conflict Serializablitiy(충돌 동등)이라고 한다.
스케쥴3과 스케쥴6은 충돌 동등(conflict Serializable)하다.
이런 경우는 Conflict Serializable 하지 않다.
conflict Serializable한지를 확인하려면?
View Serializability
아래의 세가지 조건만 만족하자.
S와 S’
•
스케쥴 S에서 Transaction Ti가 있을 때, Q의 시작값을 읽으면, S’의 Transaction Ti또한 시작값 Q를 읽어야 한다.
•
S에서 Ti가 read(Q)를 실행하고 그 값이 Transaction Tj에 의해 생성되었을 경우, S’또한 그 순서를 지켜야 한다.
•
final Write(Q)는 반드시 같은 Transaction이 수행해야한다.
Example
처음 read를 실행한 건 T27이고, 마지막 write는 T29이다
write 뒤에 read가 없으므로 2번째 조건은 자동으로 충족.
View Serializable하다. → 다만, conflict Serializable하지는 않음!!!
이처럼 view serializable하지만 conflict serializable하지 않는 경우 blind writes가 발생한 경우이다.
blind write는 쓰기 연산을 했지만 전혀 영향을 주지 않는 경우이다.
다음 예시를 보자.
Serial Schedule은 T1→T2→T3 || R(Q)W(Q)→ W(Q)R(Q) ->R(Q)W(Q)이다.
다음 대체 스케쥴은 1,3번은 만족하나 2번을 만족하지 않는다.
T1의 W(Q) 이후 R()
Testing for Serializability
정점에는 Transaction을, 엣지는 다음 순서를 향한다.
사이클을
Recoverable Schedules
Cascading Rollbacks
T10이 실패할 경우, T11와 T12가 모두 rollback해야하는 경우. 이를 cascading Rollback이라고 한다.
이는 심각한 성능저하를 일으킬 수 있음.
Cascadeless schedule
•
Tj가 Ti가 쓴 값을 읽을 때, Ti는 commit된 상태여야 한다.
Concurrency Control
DBMS가 여러개의 Transaction이 있을 때 스케쥴링을 결정해야한다.
•
conflict or view serializable
•
recoverable and preferably cascadeless
Weak Levels of Consistency
Next chapter