Isolation level은 transaction 간 격리 정도를 정하는 설정입니다. 동시에 여러 transaction이 같은 데이터를 읽고 쓰면 dirty read, non-repeatable read, phantom read 같은 문제가 생길 수 있습니다. 낮은 isolation은 동시성이 좋지만 이상 현상이 발생할 수 있고, 높은 isolation은 더 일관된 결과를 주지만 lock이나 version 관리 비용이 커질 수 있습니다.
예를 들어 Read Committed는 commit된 데이터만 읽게 하고, Serializable은 transaction들이 순차 실행된 것처럼 보이게 하는 가장 강한 수준으로 설명할 수 있습니다.
꼬리질문
조금 더 깊게 물어본다면
답변 뒤에 이어질 수 있는 질문들을 하나씩 열어볼 수 있어요.
Dirty read는 무엇인가요?
다른 transaction이 아직 commit하지 않은 값을 읽는 것입니다. 그 transaction이 rollback되면 내가 읽은 값은 실제로 존재하지 않았던 값이 됩니다.
그래서 대부분의 실무 DB 설정에서는 dirty read를 막는 경우가 많습니다.
Non-repeatable read와 phantom read는 어떻게 다른가요?
Non-repeatable read는 같은 row를 다시 읽었을 때 값이 달라지는 문제입니다. Phantom read는 같은 조건으로 조회했을 때 row 집합 자체가 달라지는 문제입니다.
값 변경과 row 출현/사라짐을 구분하면 이해하기 쉽습니다.
Serializable은 항상 써야 하나요?
아닙니다. 가장 강한 격리를 제공하지만 동시성이 낮아지고 충돌이나 retry 비용이 커질 수 있습니다.
정합성이 정말 중요한 구간에 선택적으로 쓰거나, application-level 제약과 함께 설계해야 합니다.
MVCC는 isolation과 어떤 관계가 있나요?
MVCC는 여러 version의 데이터를 유지해 읽기와 쓰기 충돌을 줄이는 방식입니다. reader가 writer를 덜 막고, transaction마다 일관된 snapshot을 보게 할 수 있습니다.
다만 version 관리와 cleanup 비용이 있습니다.
부가 설명
Dirty Read: commit되지 않은 값을 읽음Non-repeatable Read: 같은 row를 두 번 읽었는데 값이 달라짐Phantom Read: 같은 조건 조회에서 row 집합이 달라짐
isolation level은 이런 현상을 어디까지 허용할지와 관련됩니다.
각 DBMS는 isolation level을 구현하는 방식이 다를 수 있습니다. lock 기반일 수도 있고 MVCC를 사용할 수도 있습니다. 그래서 이름만 같아도 세부 동작이 다를 수 있습니다.
Isolation level의 핵심은 정합성과 동시성의 trade-off입니다. 격리를 강하게 하면 이상 현상은 줄어들지만 lock이나 대기 비용이 커질 수 있습니다.
한 줄 정리
Isolation level은 transaction 동시 실행에서 어떤 이상 현상을 허용할지 정하는 정합성과 성능의 trade-off입니다.