db 격리 단계 설명

LJM·2023년 9월 3일
0

DB

목록 보기
2/7

UPDATE 요청이 일어났을때 DB서버의 처리 방식을 먼저 이해해 보자
1. 레코드 로딩: 요청된 레코드를 디스크에서 메모리로 불러옵니다. 이는 데이터베이스의 버퍼 캐시에서 일어날 수 있습니다.

  1. 메모리에서 수정: 불러온 레코드를 메모리 상에서 UPDATE 명령에 따라 수정합니다.

  2. 검증: 필요한 경우, 수정된 데이터에 대해 검증 또는 비즈니스 로직을 적용합니다. 이 단계는 데이터베이스나 애플리케이션의 로직에 따라 다를 수 있습니다.

  3. 커밋: 문제가 없다면, 메모리에서의 변경사항을 디스크에 반영합니다. 이 과정을 "커밋"이라고 합니다.

  4. 트랜잭션 종료: 커밋이 완료되면 트랜잭션을 종료하고, 필요한 경우 데이터베이스 연결을 닫습니다.

데이터베이스의 "격리 단계(Isolation Level)"는 여러 트랜잭션이 동시에 실행될 때 어떻게 상호 작용하는지를 정의합니다. 격리 단계에 따라 데이터의 일관성과 동시성이 달라질 수 있으며, 일반적으로 다음과 같은 네 가지 격리 단계가 있습니다.

READ UNCOMMITTED
가장 낮은 격리 단계입니다.
다른 트랜잭션에서 아직 커밋되지 않은 데이터를 읽을 수 있습니다.
이로 인해 "Dirty Read"가 발생할 수 있습니다.
성능은 빠르지만, 데이터의 일관성을 보장하지 않습니다.

READ COMMITTED
커밋된 데이터만 읽을 수 있습니다.
"Dirty Read"는 발생하지 않지만, "Non-Repeatable Read"가 발생할 수 있습니다.
즉, 하나의 트랜잭션 내에서 같은 쿼리를 두 번 실행하면 다른 결과가 나올 수 있습니다.

REPEATABLE READ
트랜잭션이 시작할 때의 데이터 상태를 유지합니다.
트랜잭션 내에서 동일한 레코드를 여러 번 읽을 때, 다른 트랜잭션에 의한 UPDATE의 영향을 받지 않고 처음 읽은 데이터와 동일한 값을 보장합니다.
"Dirty Read"와 "Non-Repeatable Read"는 발생하지 않습니다.
하지만 "Phantom Read"가 발생할 수 있습니다.
쿼리 결과의 전체 레코드 집합에 대한 일관성은 보장되지 않으며, 새로운 레코드의 INSERT나 기존 레코드의 DELETE는 반영될 수 있습니다.
결론 UPDATE에 의한 변경에 대한 일관성만 보장되며, INSERT나 DELETE에 의한 변경에 대한 일관성은 보장되지 않습니다. 이로 인해 "Phantom Read" 문제가 발생할 수 있습니다.

SERIALIZABLE
가장 높은 격리 단계입니다.
트랜잭션들이 순차적으로 실행되므로 "Dirty Read", "Non-Repeatable Read", "Phantom Read" 모두 발생하지 않습니다.
하지만 이로 인해 성능이 저하될 수 있습니다.
각 격리 단계는 성능과 데이터의 일관성 사이에 트레이드오프가 있습니다. 따라서 어플리케이션의 요구 사항에 따라 적절한 격리 단계를 선택해야 합니다.

DirtyRead 란?
한 트랜잭션이 데이터를 수정했지만 아직 커밋을 하지 않은 상태에서, 다른 트랜잭션이 그 수정된 데이터를 읽는 경우를 의미합니다.

Non-Repeatable Read 란?
트랜잭션에서 발생할 수 있는 일종의 문제 상황을 설명하는 용어입니다. 이 문제는 한 트랜잭션 내에서 같은 레코드를 두 번 이상 읽을 때, 두 번째 이후의 읽기 작업에서 첫 번째 읽기 작업과 다른 결과를 반환하는 경우를 의미합니다.

예를 들자면 트랜잭션 A가 작업 중인 동안 다른 트랜잭션 B가 해당 레코드를 수정하고 커밋함으로써 발생합니다. 이로 인해 트랜잭션 A가 처음과 두 번째로 동일한 레코드를 읽을 때 다른 결과를 얻게 됩니다.

추가 정보

REPEATABLE READ" 격리 수준에서 동일한 값을 보장하는 메커니즘
로우 레벨 락(Row-Level Lock)
트랜잭션 A가 특정 레코드를 읽을 때, 그 레코드에 대한 로우 레벨 락을 설정할 수 있습니다. 이렇게 하면 다른 트랜잭션은 그 레코드를 수정할 수 없게 됩니다.

버전 관리(MVCC, Multi-Version Concurrency Control)
트랜잭션 A가 레코드를 읽을 때의 버전을 유지합니다. 다른 트랜잭션에서 레코드를 수정하더라도, 트랜잭션 A는 처음 읽을 때의 버전을 계속 볼 수 있습니다.

스냅샷(Snapshot)
트랜잭션이 시작될 때의 데이터 상태를 스냅샷으로 찍어 둡니다. 트랜잭션 내에서는 이 스냅샷에 기반하여 데이터를 읽습니다.
이러한 메커니즘을 통해 트랜잭션 내에서는 다른 트랜잭션의 영향을 받지 않고 일관된 데이터를 읽을 수 있습니다. 하지만 이러한 방법들은 성능과 자원 사용에 영향을 미칠 수 있으므로, 적절한 격리 수준을 선택해야 합니다.

profile
게임개발자 백엔드개발자

0개의 댓글