Database 14. transaction isolation level

• MySQL 문법을 기준으로 서술한다.

Dirty read

• commit 되지 않은 변화를 읽음

Non-repeatable read(Fuzz read)

• 같은 데이터의 값이 달라짐

Phantom read

• 없던 데이터가 생김

성능 문제

• 위와 같은 이상한 현상들이 모두 발생하지 않게 만들 수 있지만 그러면 제약 사항이 많아져서 동시 처리 가능한 트랜잭션 수가 줄어들어 결국 DB의 전체 처리량(throughput)이 하락하게 된다.

해결책

• 일부 이상한 현상은 허용하는 몇가지 level을 만들어서 사용자가 필요에 따라서 적절하게 선택할 수 있도록 하자
• 이것이 Isolation level이다.

Overview

Isolation Level	Dirty read	Non-repeatable read	Phantom read
Read uncommitted	O	O	O
Read committed	X	O	O
Repeatable read	X	X	O
Serializable	X	X	X

• Serializable : 위 세 가지 현상 뿐만 아니라 아예 이상한 현상 자체가 발생하지 않는 Level을 의미
• 애플리케이션 설계자는 isolation level을 통해 전체 처리량(throughput)과 데이터 일관성 사이에서 어느 정도 거래(trade)를 할 수 있다.
• 단, 위의 현상들이 이상 현상의 전부가 아니다.
  • dirty write : commit 안된 데이터를 write할 때 발생함.
    • rollback 시 정상적인 recovery는 매우 중요하기 때문에 모든 isolation level에서 dirty write은 허용하면 안된다.
  • Lost update : 업데이트를 덮어쓸 때 발생
  • Read skew : inconsistent한 데이터 읽기
  • Write skew : inconsistent한 데이터 쓰기

SNAPSHOT Isolation

• Standard SQL 92를 비판한 논문에서 제안된 새로운 Isolation Level
• concurrency control이 어떻게 동작할지에 대한 구현을 바탕으로 정의된 Isolation이다.
• mvcc의 종류 중 하나이다
  • mvcc : multi version concurrency control
• transaction 시작 전에 commit된 데이터만 보인다.
• First-committer win 방식이다.

실무에서 적용되는 Isolation Level 정책

• MySQL
  • SQL 표준 문서에 정의한 Level이 그대로 존재하고 동작함.
• Oracle
  • Read uncommitted는 지원하지 않으며
  • Read Committed와 Serializable을 지원한다.(이외에 추가적인 level이 존재하긴한다.)
  • 또한 Serializable은 Snapshot Isolation과 동일하게 동작한다.
• SQL server
  • SQL 표준에서 정의된 Isolation level + Snapshot Isolation level
• postgreSQL
  • SQL 표준에서 정의된 Isolation level을 정의하지만 Serialization Anomaly 여부도 표시해준다.
  • Repeatable read가 Snapshot Isolation level에 해당한다.
• 위와 같이 각각의 RDBMS마다 Isolation Level을 잘 파악하고, 해당 수준의 동작 방식 또한 잘 읽어서 사용해야 한다.