MVCC - 동시성 이슈에서 ACID를 지키자

개요

• 토이프로젝트를 할 때 RDB(Relational Database) 중 PostgreSQL을 선택했다
• 선택한 배경에는 오픈 소스 데이터베이스라는 점과 ACID를 지키며 동시성 이슈를 개선한 MVCC라는 점이 마음에 들었다.
• ACID와 MVCC가 무엇인지 정리해보았다.

ACID

• 개념
  - RDB(Relational Database)에서 ACID를 지키는 것을 굉장히 중요시 한다.
  • 트랜잭션, Lock 등은 ACID의 성질을 지키기 위해 등장했다.
• 원자성(Atomicity), 일관성(Consistency), 고립성(Isolation), 지속성(Durablility)

💡 트랜잭션: DB내에서 하나의 논리적 기능을 수행하기 위해 행해지는 작업의 논리적인 단위

원자성(Atomicity)

• 트랜잭션은 분해가 불가능한 최소의 단위인 원자처럼 동작함
• 트랜잭션 내 모든 연산을 반드시 완료하거나(1) 어떠한 연산도 수행되지 않아야(0) 함.
• all or nothing
• 내가 영화 리뷰 DB에 리뷰를 save 하려고 했는데, 글 내용의 절반만 저장되고 나머지는 안된다면 원자성 위반

일관성(Consistency)

• 트랜잭션 작업이 시작되기 전에 DB 상태가 일관된 상태였다면 트랜잭션 작업이 종료된 후에도 일관성 있는 DB상태를 유지해야한다
• 영화 리뷰 글자수 제한이 255자라고 하면, 트랜잭션이 일어나면 이 조건을 만족해야함. 이를 위반하는 트랜잭션은 거부해야한다.

고립성(Isolation)

• 트랜잭션 작업 수행중에는 다른 트랜잭션에 영향을 주면 안되고, 다른 트랜잭션에 의해 간섭을 받아서도 안된다.
• 다른 트랜잭션 참조, 영향 X
• 트랜잭션은 고립된 상태에서 실행되어야 함
• 리뷰어 A와 B가 동시에 글을 post 했다. 고립성을 유지하기 위해 리뷰어 A의 트랜잭션이 종료된 후에 B의 글을 저장하는 트랜잭션을 수행해야 고립성을 유지할 수 있다.

지속성(Durability)

• 트랜잭션 완료 후 그 결과가 영구적으로 유지되어야 한다.
• 시스템이 정상일 때 뿐만 아니라 데이터베이스나 OS의 이상 종료, 즉 시스템 장애도 견딜 수 있는 것
• MySQL을 포함해 많은 DB들은 트랜잭션 조작을 하드 디스크에 로그로 기록하고 시스템이 이상하면 로그를 사용해 장애 발생 전까지 복원하는 방식으로 지속성을 실현하고 있음

MVCC(다중 버전 동시성 제어) - 동시성 이슈에서 ACID를 지키자

💡 PostgreSQL 장점을 찾다가 나온 이슈여서 겸사겸사 정리

• 동시성 제어란?
  • DBMS에서 다수의 사용자가 동시에 접근하면 다중 트랜잭션 상호간섭이 일어나지 않도록 DB를 보호하는 개념
• Lock 방식의 동시성 제어의 한계
  • 읽기 작업과 쓰기 작업이 서로 방해를 일으키기 때문에 동시성 문제가 발생
  • 데이터 일관성에 문제가 생기는 경우도 있어서 Lock을 더 오래 유지하거나 Table 레벨의 Lock을 사용해야하는데, 이 때문에 동시성 저하가 발생한다
• MVCC 등장 배경
  • 동시 접근을 허용하는 데이터 베이스에서 동시성을 제어하며 ACID를 구현하기 위해 생긴 개념
• PostgreSQL이 대표적이라고 한다 (MySQL도 특정 버전 이상부터 지원한다고 하는것 같기는 한데...)
• 작동 방식
  • 데이터에 접근하는 사용하는 사용자는 접근한 시점에서의 DB의 Snapshot을 읽음
  • Snapshot 데이터에 대한 변경 작업 실행 (작업 완료될 때까지 다른 사용자가 볼 수 없음. 고립)
  • 작업 완료하면 이전 데이터를 덮어씌우지 않고, 새로운 버전의 데이터를 UNDO 영역에 생성
  • 사용자는 Read 할 때 마지막 버전의 데이터를 읽게 된다
• 장점
  • Lock을 필요로 하지 않기 때문에 일반적인 RDBMS 보다 빠르게 작동
  • 데이터를 읽기 시작할 때 다른 사람이 그 데이터를 삭제하거나 수정하더라도 영향을 받지 않고 데이터 사용 가능
• 단점
  • 사용하지 않는 데이터 (구 버전 데이터) 가 계속 쌓이게 되므로 데이터를 정리하는 시스템이 필요하다
  • 데이터 버전이 충돌할 수 있으므로 애플리케이션 영역에서 이러한 문제를 해결해야한다.
  • UNDO 블록 I/O, CR Copy 생성, CR 블록 캐싱 등의 부가적인 작업의 오버헤드가 발생한다
• 결론
  • 여러 사용자가 동시에 접근하는 경우가 많은데 ACID를 유지하는게 중요한 경우 MVCC 모델(PostgreSql등)을 사용하자
  • 속도에 민감한 경우, DB를 유지하는데 드는 리소스를 최소화 해야하는 경우는 기존 모델을 쓰자
• 참고

  • https://covenant.tistory.com/85

  • https://mangkyu.tistory.com/53

  • https://smoh.tistory.com/370