Multiversion concurrency control

참조 : http://en.wikipedia.org/wiki/Multiversion_concurrency_control

multiversion concurrency control (abbreviated MCC or MVCC) is a concurrency control method commonly used by database management systems to provide concurrent access to the database.

MVCC는 각각의 사용자에게 각자 작업할 수 있는 스냅샷을 제공합니다. 트랜잭션이 커밋되기 전에는 각자 작업한 내용을 다른 사람들이 볼 수 없습니다.

MCC는 타임스탬프 또는 증가하는 트랜잭션 ID를 사용하여 serializability를 만족시킵니다.

많은 버젼을 관리해야 한다는 단점이 있지만 읽기 작업을 방해(block)하지 않는다는 장점이 있습니다.

MCC를 사용하는 데이타베이스들

공부해야 할 것 : snapshot isolation, serializability

Timestamp-based concurrency control

참조 : http://en.wikipedia.org/wiki/Timestamp-based_concurrency_control

또 다른 non-lock concurrency control 방법 중 하나입니다. 다음과 같이 정의하고 있습니다.

timestamp-based concurrency control is a non-lock concurrency control method, used in relational databases to safely handle transactions, using timestamps.

모든 트랜잭션이 시작할 때 timestamp를 가지게 되며 이 값은 고유하며 나중에 시작한 트랜잭션이 더 큰수의 timestamp를 자기게 됩니다.

따라서 두 개의 트랜잭션 내의 어떤 작업들이 충돌 했을 때 해당 작업이 속해있는 트랜잭션의 타임스팸프로 어떤 작업이 먼저 수행되야 하는 지 알 수 있습니다.

또 한 데이타 베이스에 있는 데이타들은 각각 Read Time Stamp와 Write Time Stamp를 가지고 있습니다. RTS는 해당 데이타를 누군가 읽을 때 마다 갱신 됩니다. WTS는 해당 데이타를 쓸 떄마다 업데이트 됩니다.

따라서 어떤 트랜잭션이 어떤 데이타를 읽고 싶을 때…

1. 읽고자 하는 데이타의 WTS 보다 해당 트랜잭션의 TS(타임스탬프)가 작다면( == 트랜잭션이 시작 된 후에 데이타가 변경되었다.) 트랜잭션은 취소되고 다시 실행 합니다.

2. 읽고자 하는 데이타의 WTS 보다 해당 트랜잭션의 TS가 크다면( == 트랜잭션이 시작하기 전에 테이타의 변경이 완료됐다.) 트랜잭션을 완료하며 이때 만약 데이타의 RTS가 해당 트랜잭션 보다 작다면( == 트랜잭션이 해당 데이타를 가장 마지막( == 최신 )에 읽고 있다. ) 해당 트랜잭션 TS로 갱신합니다.

어떤 트랜잭션이 어떤 데이타를 쓰고 싶을 때…

1. 읽고자 하는 데이타의 RTS 보다 해당 트랜잭션의 TS가 작다면( == 트랜잭션이 시작 된 후에 누군가 데이타를 읽고 있다.) 반복된 Select 문에도 같은 값을 보여 주기 위해서[footnote]엇!! 이 부분은 isolation level이랑 관련이 있어 보입니다.[/footnote] 트랜잭션을 취소하고 다시 실행합니다.

2. 읽고자 하는 데이타의 WTS 보다 해당 트랜잭션의 TS가 작다면( == 트랜잭션이 시작 된 후에 누군가 데이타를 갱신했다.) 이땐 Thomas write rule[footnote]여기서 만약 재시작하여 써버리게 되면 그 새 갱신했던 데이타를 볼 수가 없기 때문이라는 것 같습니다.[/footnote]에 따라 트랜잭션을 취소하고 재시작 할 필요가 없다고 합니다.

3. 위의 경우에 해당하지 않으면 트랜잭션을 처리하고 해당 데이타의 WTS를 갱신합니다.

단점

1. 다른 시간에 만든 트랜잭션 임에도 불구하고 같은 TImeStamp를 갖게 될 수도 있습니다.(시간을 1초 마다 찍는 기계가 있는데 1초 사이에 두 개의 작업을 시작하면 두 개의 작업은 같은 TS를 가지겠죠.)

2. 모든 데이타의 WTS와 RTS를 관리하는데 초과 비용이 발생합니다.

Optimistic concurrency control

참조 : Wikipedia-Optimistic concurrency control

optimistic concurrency control, (OCC) is a concurrency control method used in relational databases without using locking. It is commonly referred to as optimistic locking, a misnomer.Optimistic concurrency control

Non-lock concurrency control 방법들 중에 하나로 Locking을 사용하지 않고 동시성 제어를 하는 방법을 Optimistic concurrency control 또는 Optimistic locking이라고 합니다.

트랜잭션 충돌이 거의 발생하지 않는다는 가정하에 다음의 절차로 트랜잭션을 처리합니다.

읽기: 클라이언트가 데이타베이스로 부터 값을 읽어서 private sandox 나 cache에 저장하고 클라이언트는 그것을 가지고 작업을 합니다.

검증하기: 클라이언트가 샌드박스나 케쉬에서 편집을 끝내면 그것들을 데이타 베이스에 넣기 전에 검증 작업을 거칩니다.

– backward validation schemes 에 커밋된 트랜잭션이 존재하거나
– forward validation schemes 에 현재 실행중인 트랜잭션이 존재하면

출동이 발생합니다. 충돌이 발생하면 충돌을 풀기 위한 알고리즘이 사용되거나(주로 사용자에 의해 변경된 부분을 최소화 시킵니다.)[footnote]원문에는 ideally by minimizing the number of
changes made by the user 이렇게 적혀 있는데 변경 되는 사항들을 최소화 시킨다는 것이 어떤 건지 모르겠네요. queue로 변경 작업을 하는 트랜잭션을 관리하여 한번에 하나씩 처리하게 한다는 것인가;;??[/footnote] 전체 트랜잭션을 취소(이때는 사용자가 변경한 부분이 모두 날리게 되니까 그다지 좋은 방법은 아닙니다.)시킵니다.

쓰기: 만약 충돌이 발생하지 않았다면 커밋합니다.

충돌이 자주 발생하지 않으면 이 방법으로 다른 방법들(non-lock concurrency control) 보다 많은 작업을 처리할 수 있지만, 충돌이 자주 발생하면 성능이 떨어지기 때문에 충돌이 자주 발생할 때 효율이 좋은 다른 방법을 사용합니다.

사용한 곳

  • MediaWiki‘s edit pages use OCC. The conflict resolution algorithm is described here.
  • Bugzilla uses OCC; conflicts are called “mid-air collisions”. [1]
  • The Ruby on Rails framework has an API for OCC. [2]
  • Most revision control systems support the “merge” model for concurrency, which is OCC.