Database

[Database] Transaction Isolation Level

mxruhxn 2024. 10. 6. 22:35
728x90
반응형

Transaction들이 동시 실행될 때 발생 가능한 이상 현상

  • Dirty Read
    • 커밋되지 않은 변화를 읽는 현상
  • Nonrepeatable Read(= Fuzzy Read)
    • 같은 데이터를 2번 읽었는데 값이 달라짐
    • 이는 트랜잭션의 Isolation 속성을 위반하는 현상
  • Phantom Read
    • 없던 데이터가 갑자기 생기는 현상
    • 이 역시 Isolation 속성을 위반하는 현상

이런 이상 현상들이 모두 발생하지 않도록 만들 수는 있지만, 그러면 제약사항이 많아져서 동시 처리 가능한 트랜잭션 수가 줄어들어 결국 DB의 전체 처리량(throughput)이 하락하게 된다..
⇒ 일부 이상한 현상은 허용하는 몇 가지 level을 만들어서 사용자가 필요에 따라서 적절하게 선택할 수 있도록 하자!

Isolation Level

위에서 3가지 이상 현상을 정의하고 어떤 현상까지를 허용하는지에 따라서 각각의 Isolation Level이 구분된다.
애플리케이션 설계자는 Isolation level을 통해 전체 처리량과 데이터 일관성 사이에서 어느 정도 trade를 해야 할 수 있다.

종류

  • Read Uncommitted
  • Read Committed
  • Repeatable Read
  • Serializable

..까지가 1992년 11월에 발표된 SQL 표준에서 정의된 내용이다. 하지만...


1995년에 ANSI/ISO standard SQL 92에서 정의한 Isolation Level을 비판하는 논문이 등장한다

비판 내용

  • 3가지 이상 현상의 정의가 모호하다
  • 이상 현상은 3가지 외에도 더 있다
  • 상업적인 DBMS에서 사용하는 방법을 반영해서 Isolation Level을 구분하지 않았다

기존 이상 현상의 모호함 & 추가적인 이상 현상들

  • Dirty Write
    • 2개의 트랜잭션이 커밋이 되지 않은 데이터를 write를 할 때 발생하는 이상 현상
    • 논문에서는 롤백 시 정상적인 recovery가 매우 중요하기 때문에 모든 Isolation Level에서 dirty write는 허용하면 안된다고 비판
  • Lost Update
    • 2개의 트랜잭션이 동시에 Update 작업을 할 때, 한쪽이 업데이트를 덮어쓰는 현상
  • Dirty Read 확장판
    • Dirty Read: 커밋되지 않은 데이터를 읽고 쓰는 작업을 했는데, 사용한 데이터가 rollback이 되는 경우 발생하는 이상 현상
    • 논문에서는 꼭 롤백이 도지ㅣ 않아도 Dirty Read가 발생할 수 있다고 비판한다.
    • 한 트랜잭션이 아직 값을 변화시키는 작업을 하는 중에, 다른 한 트랜잭션이 변화할 데이터들을 모두 읽는 경우, 문제가 발생한다.
  • Read Skew
    • inconsistent한 데이터를 읽는 현상
    • Non-repeatable read와 유사 (값을 2번 읽었는데 값이 다름)
  • Write Skew
    • inconsistent한 데이터 쓰기 현상
    • 서로 다른 데이터에 대해 쓰기 작업을 하는 데도, 제약사항을 위반하는 이상 현상이 발생
  • Phantom Read 확장판
    • 꼭 같은 조건을 두 번 읽는 것이 아니라 할지라도 서로 연관된 데이터를 읽는 경우에는 중간에 어떤 데이터가 추가됐을 때, 이상 현상이 발생할 수 있다.

Snapshot Isolation

기존 표준에서 정의한 isolation level은 이상 현상 3가지를 정의한 뒤에, 이상 현상들 중에서 얼마만큼 허용하는지에 따라서 level을 정의했었다.
하지만, Snapshot Isolation은 concurrency control이 어떻게 동작할지 그 구현을 바탕으로 정의된 isolation이다.

다시 말해, Snapshot isolation은 어떻게 concurrency control을 구현을 할거냐? 즉, 어떻게 isolation을 할거냐?의 구현방식에 기반해서 level이 정의됐다는 의미이다.

때문에, Snapshot Isolation Level을 이해하기 위해서는 실제 Snapshot Isolation의 동작 방식에 대한 이해가 필요하다.

  • Snapshot: 특정 시점에서의 형상으로, Snapshot Isolation에서는 트랜잭션이 시작되는 시점을 그 snapshot의 특정 시점으로 잡는다.
  • 트랜잭션이 시작되는 순간, 각 트랜잭션은 snapshot을 갖게 되고, write 작업은 모두 데이터베이스에 직접 쓰는 것이 아닌, snapshot에 써준다.
    • 데이터베이스 외부에서는 여전히 변경되지 않은 값으로 보이게된다.
  • Snapshot Isolation에서는 같은 데이터에 대해 write를 할 떄(write-write confliction), 먼저 커밋된 트랜잭션만 인정하고 뒤에 커밋을 시도한 트랜잭션은 모두 abort된다.

이렇게 동작하는 방식 Snapshot Isolation은 MVCC의 한 종류이다.

MVCC(Multi Version Concurrency Control): 각 트랜잭션마다 특정 시점에서의 스냅샷을 기준으로 각각의 버전이 존재하는 것

Snapshot Isolation의 특징

  • tx 시작 전에 commit 된 데이터만 보인다
  • First-committer win

실무에서의 Isolation Level

  • MySQL(InnoDB)
    • 표준 SQL에 정의된 Isolation Level을 정의했음.
    • 4가지 Isolation Level을 제공함
    • 3가지 이상 현상을 언급함
  • Oracle
    • 표준 SQL을 바탕으로 Isolation Level을 정의했음.
    • READ UNCOMMITTED는 지원 X
    • REPEATABLE READ나 SERIALIZABLE을 사용하려면, Isolation Level을 SERIALIZABLE로 두어야 함.
    • 사실상 주로 사용되는 Isolation Level은 READ COMMITTED, SERIALIZABLE 뿐
    • 또한, SERIALIZABLE은 사실상 Snapshot Isolation level로 동작한다고 보면 됨.
  • PostgreSQL
    • 표준 SQL에 정의된 Isolation Level을 정의했음.
    • 4가지 Isolation Level을 제공함
    • 표준에서 정의된 3가지 현상 외에도 Serialization Anomaly와 같은 그 외의 현상을 따로 표기
    • REPEATABLE READ레벨이 Snapshot Isolation level과 동일

주요 RDBMS는 SQL 표준에 기반해서 isolation level을 정의한다

RDBMS마다 제공하는 isolation level이 다르다

같은 이름의 isolation level이라도 동작 방식이 다를 수 있다.

→ 기본값을 사용하도 되겠지만, 튜닝이 필요한 경우 사용하는 RDBMS의 isolation level을 잘 파악해서 적절한 isolation level을 사용할 수 있도록 해야 한다.

728x90
반응형