15. concurrency control - 1

transaction의 실행 순서를 간단히 나타낸 것 (r : read , w : write , c : commit)

schedule

각 transaction 내의 operations들의 순서는 바뀌지 않음.

 

Serial schedule

- transaction들이 겹치지 않고 한 번에 하나씩 실행되는 schedule

- 예시에서는 sched.1 , sched.2 가 있음

 

Nonserial schedule

- transaction들이 겹쳐서(interleaving) 실행되는 schedule

- 예시에서는 sched.3 , sched.4 가 있음

 

Serial schedule 성능

- 한 번에 하나의 transaction만 실행되기 때문에 좋은 성능을 낼 수 없고 현실적으로 사용할 수 없는 방식임

 

Nonserial schedule 성능

- transaction들이 겹쳐서 실행되기 때문에 동시성이 높아져서 같은 시간동안 더 많은 transaction들을 처리할 수 있음

 

Nonserial schedule 단점

- transaction들이 어떤 형태로 겹쳐서 실행되는지에 따라 이상한 결과가 나올 수 있음

 - 예시에는 sched.4가 있음 (lost update)

 

 

Conflict of two operations - 세가지 조건을 모두 만족하면 conflict 하다!

1. 서로 다른 transaction 소속

2. 같은 데이터에 접근

3. 최소 하나는 write operation

sched.3 에서는 총 세 개의 conflict가 존재함

 

Conflict 개념이 중요한 이유

- conflict operation은 순서가 바뀌면 결과도 바뀌기 때문

 

 

 

 

Conflict equivalent for two schedules - 두 조건 모두 만족하면 conflict equivalent 하다!

1. 두 schedule은 같은 transaction들을 가짐

2. 어떤(any) conflicting operations의 순서도 양쪽 schedule 모두 동일함

sched.2와 sched.3은 conflict equivalent 하다!

여기서 sched.2는 serial schedule인데, 이렇게 serial schedule과 conflict equivalent할 때 nonserial sched.3는

conflict serializable 하다!

 

sched.4는 그 어떤 serial schedule과도 conflict equivalent하지 않기 때문에 NOT conflict serializable 하다!

 

 

문제

- 성능 때문에 여러 transaction들을 겹쳐서 실행할 수 있으면 좋음 (nonserial schedule)

- 하지만 이상한 결과가 나오는 것은 싫음..

 

해결책

- conflict serializable한 nonserial schedule을 허용하자!

 

구현

- 여러 transaction을 동시에 실행해도 schedule이 conflict serializable하도록 보장하는 프로토콜을 적용

 

 

그 어떤 schedule도 serializable하게 만드는 역할을 수행하는 것이 concurrency control 임.

이것과 밀접하게 관련된 transaction의 속성이 바로 isolation

 

isolation을 너무 엄격하게 하면(serializablity를 너무 완벽하게 추구하면) 그만큼 제약사항이 걸리기 때문에 동시성이 떨어지게 되고 성능이 줄어들게 됨. 그래서 필요에 따라 개발자들이 유연하게 선택할 수 있도록 완화된 isolation을 제공하겠다는 개념인 isolation level 이 생김.

 

 

 

 

출처 : https://www.youtube.com/watch?v=DwRN24nWbEc&list=PLcXyemr8ZeoREWGhhZi5FZs6cvymjIBVe&index=15