[DB] 낙관적 락(Optimistic Lock), 비관적 락(Pessimistic Lock)

 

 > DB의 transaction 관련 개념을 보강하기 위해 낙관적 락과 비관적 락에 대해서 알아보고 정리해보았다.

 

학습 키워드: database, optimistic lock, pessimistic lock

 

1. Pessimistic Lock

1) What is it?:

 비관적 락은 동일한 데이터로의 동시 접근을 제한하여 비일관성(inconsistency)을 방지하는 locking 메커니즘이다. DB에서 데이터라 함은 테이블의 row를 의미하기 때문에 row의 다른 표현인 record에 대한 lock이라는 의미에서 Record Lock이라고도 불린다.

 

 

2) Why use locks?:

Figure 1. 동시에 같은 record를 수정했을 때

 

 은행원 A와 B가 있고, 두 은행원이 동일한 계좌를 동시에 업데이트 하려고 하는 상황을 상상해보자. 한 쪽에서 계좌의 정보를 불러오는 동안 다른 한 쪽 또한 계좌의 정보를 불러오게 되고, 먼저 불러온 쪽이 계좌의 정보를 수정한 뒤 저장을 마쳤다. 그런데 이후 두 번째 은행원이 정보 업데이트를 마친 뒤 해당 정보를 저장한다면 어떻게 될까? 두 번째 수정한 정보의 경우 첫 번째 은행원이 수정한 정보 이전의 데이터를 불러와서 수정했기 때문에 첫 번째 은행원의 transaction에서 수정한 정보가 덮어 쓰이면서 없던 일이 되어버린다. 이러한 상황을 막기위해 transaction이 시작될 때 데이터에 lock을 걸어(정확히는 해당 transaction이 'acquiring locks / lock을 획득한다' 고 표현한다) 접근을 제한하는 것이 바로 pessimistic lock이다.

 

 

3) How does it work?:

 비관적 락은 데이터가 접근되는 순간 데이터에 shared lock (S lock) 또는 exclusive lock (X lock)을 건다. S lock의 경우 데이터를 읽기만 할 때 사용되는데, 이름처럼 여러 transaction이 공유할 수 있지만, lock이 걸린 데이터를 수정할 수는 없다. 반면에 X lock의 경우 데이터를 첫 번째 transaction이 모든 작업을 완료하기 전까지 다른 transaction이 데이터를 읽거나 쓸 수 없는 상태로 만든다.

 

 

2. Optimistic Lock

1) What is it?:

 낙관적 락은 여러 transaction이 대체로 서로 간섭하지 않고도 작업을 잘 마칠 수 있다는 말그대로 낙관적인 가정 하에 이루어진다.

 

 

2) How does it work?:

 비관적 락과는 다르게 transaction이 lock을 획득하지 않는데, 대신에 데이터 자체에 version이나 timestamp 등 수정 시각을 체크하는 column을 가진다. 어느 transaction이 데이터를 읽어온 뒤, 수정하고 다시 저장할 때 validation 프로세스가 추가되는데, 만약 이미 다른 transaction이 데이터를 수정하여 버전이나 timestamp가 바뀌게 되면 일치하는 데이터를 찾지 못해 수정에 실패하고, 만약 다른 데이터 수정이 있었다면 rollback 하도록 하는 방식이다.

 

 

3) Optimistic lock vs Pessimistic lock:

 비관적 락의 경우 데이터 자체의 접근이 차단되기 때문에 무결성이 향상되고, 구현이 쉽다는 장점이 있지만, 데이터가 lock 되는 시간이 길어질 수록 전체적인 처리량이 저하되며, 둘 이상의 transaction이 서로 lock을 해제하기를 기다리는 deadlock(교착) 상태에 빠지게 될 수도 있다. 특히나 온라인 게임처럼 정보 교환량이 많은 시스템에서는 lock을 걸었다 해제하는 것 자체로도 엄청난 오버헤드가 된다.

 

 낙관적 락은 앞서 언급한 lock으로 인한 대기 같은것이 없이 동시 처리량이 높고, lock이 없기 때문에 deadlock 같은 상황 또한 발생하지 않는다는 장점이 있지만, 구현 단에서 신경써야할 부분들이 많아진다는 단점이 있다. 예를들어 반드시 적용해야하는 transaction이 실패하는 경우, 그냥 없던 일로 만들 수는 없기 때문에 이를 재시도하는 retry 메커니즘을 구현해야 하며, 잦은 충돌이 일어나는 환경이라면 결국 pessimistic lock과 다를바 없이 overhead가 발생하게 된다.

 

 

 

--

 

REFERENCES:

 

Record locking - Wikipedia

 > Wikipedia, "Record locking"

Optimistic concurrency control - Wikipedia

 > Wikipedia, "Optimistic concurrency control"