Isolation이 안 될 때 나타날 수 있는 이상 현상
- isolation : 여러 transaction들이 동시에 실행될 때도 혼자 실행되는 것처럼 동작하게 만든다.
https://velog.io/@yu_ri_son/Database-Transaction-ACID
Dirty read
- commit 되지 않은 변화를 읽음
Non-repeatable read (Fuzzy read)
- 같은 데이터의 값이 달라짐
Phantom read
- 없던 데이터가 생김
이상 현상들이 모두 발생하지 않게 만들 수 있지만, 제약 사항이 많아져서 동시 처리 가능한 트랜잭션 수가 줄어든다. => 결국 DB의 전체 처리량(throughput)이 하락하게 된다.
⬇️
일부 이상 현상은 허용하는 몇 가지 level을 만들어서 사용자가 필요에 따라 적절하게 선택할 수 있도록 하자!
⬇️
Isolation Level
- Serializable : 위 세 가지 현상 뿐만 아니라 아예 이상한 현상 자체가 발생하지 않는 level을 의미한다.
애플리케이션 설계자는 isolation level을 통해 전체 처리량(throughput)과 데이터 일관성 사이에서 어느 정도 거래(trade)를 할 수 있다.
standard SQL 92에서 정의한 isolation level의 비판 (논문: A Critique of ANSI SQL Isolation Levels)
- 세 가지 이상 현상의 정의가 모호하다.
- 이상 현상은 세 가지 외에도 더 있다.
- 상업적인 DBMS에서 사용하는 방법을 반영하여 isolation level을 구분하지 않았다.
Dirty write
- commit 안 된 데이터를 write 함
- rollback 시 정상적인 recovery는 매우 중요하기 때문에 모든 isolation level에서 dirty write를 허용하면 안 된다!
Dirty read (+)
- abort가 발생하지 않아도 dirty read가 될 수 있다.
Phantom read (+)
- 같은 조건을 두 번 읽는 경우가 아니더라도, 서로 연관된 데이터가 있는 경우에도 발생할 수 있다.
Lost update
- 업데이트를 덮어 씀
Read skew
- inconsistent한 데이터 읽기
Write skew
- inconsistent한 데이터 쓰기
Snapshot Isolation
- concurrency control이 어떻게 동작할 지, 그 구현을 바탕으로 정의됨
- Type of MVCC(Multi Version Concurrency Control)
- 트랜잭션 시작 전에 commit된 데이터만 보임
- First-committer win!
실무에서의 isolation level
- 주요 RDBMS(MySQL, ORACLE, PostgreSQL, SQL Server)는 SQL 표준에 기반해서 isolation level을 정의한다.
- RDBMS마다 제공하는 isolation level이 다르다.
- 같은 이름의 isolation level이라도 동작 방식이 다를 수 있다.
- 사용하는 RDBMS의 isolation level을 잘 파악해서 적절한 isolation level을 사용할 수 있도록 해야 한다.
