트랜잭션 격리 수준(Transaction Isolation Level)

gang_shik·2022년 6월 1일
0

Database

목록 보기
9/9

트랜잭션 격리 수준

  • 동시에 여러 트랜잭션이 처리될 때, 트랜잭션끼리 얼마나 서로 고립되어 있는지를 나타내는 것임

  • 특정 트랜잭션이 다른 트랜잭션에 변경한 데이터를 볼 수 있도록 허용할지 말지를 결정함

  • 데이터베이스는 트랜잭션의 성질과 같이 트랜잭션이 독립적인 수행을 하도록 Locking을 통해, 트랜잭션이 DB를 다루는 동안 다른 트랜잭션이 관여하지 못하도록 막는 것이 필요함

  • 하지만 무조건 Locking으로 동시에 수행되는 수많은 트랜잭션들을 순서대로 처리하는 방식으로 구현하게 되면 데이터베이스의 성능은 떨어지게 됨, 하지만 성능을 높이기 위해 Locking의 범위를 줄인다면, 잘못된 값이 처리될 문제가 발생할 수 있음

  • 따라서 최대한 효율적인 Locking 방법이 필요함

Lock

  • 트랜잭션의 처리의 순차성을 보장하기 위한 방법임(동시성 제어)

공유 Lock

  • 데이터를 읽을 때 사용되어지는 Lock

  • 공유 Lock은 공유 Lock끼리 동시에 접근이 가능함

  • 하지만 공유 Lock이 설정된 데이터에 배타 Lock을 사용할 수는 없음

배타 Lock

  • 데이터를 변경하고자 할 때 사용되며, 트랜잭션이 완료될 때까지 유지됨

  • Lock이 해제될 때까지 다른 트랜잭션(읽기 포함)은 해당 리소스에 접근할 수 없음

  • 해당 Lock은 트랜잭션이 수행되고 있는 데이터에 대해서는 접근하여 함께 Lock을 설정할 수 없음

Isolation level 종류

  • 레벨이 높아질수록 트랜잭션 간 고립 정도가 높아지며, 성능이 떨어지는 것이 일반적이며, 일반적인 온라인 서비스에서는 READ COMMITTED나 REPEATABLE READ 중 하나를 사용함

Read Uncommitted(레벨 0)

  • SELECT 문장이 수행되는 동안 해당 데이터에 Shared Lock이 걸리지 않는 계층

  • 트랜잭션에 처리중이거나, 아직 Commit 되지 않은 데이터를 다른 트랜잭션이 읽는 것을 허용함

  • 데이터베이스의 일관성을 유지하는 것이 불가능함

  • Dirty Read 발생

    • A 트랜잭션에서 10번 사원의 나이를 27에서 28로 바꿈, 아직 커밋하지 않음

    • B 트랜잭션에서 10번 사원의 나이를 조회 : 결과 28 -> Dirty Read

      • 이 이후, A 트랜잭션에서 문제가 발생해 Rollback함

      • B 트랜잭션은 10번 사원이 여전히 28살이라고 생각하고 로직을 수행함

      • 데이터 정합성에 문제가 많아짐

Read Committed(레벨 1)

  • SELECT 문장이 수행되는 동안 해당 데이터에 Shared Lock이 걸리는 계층

  • 트랜잭션이 수행되는 동안 다른 트랜잭션이 접근할 수 없어 대기하게 됨

  • Commit이 이루어진 트랜잭션만 조회 가능

  • Oracle DB, SQL Server에서 기본으로 사용하는 Isolation Level임

  • Non-Repeatable Read 발생

    • B 트랜잭션에서 10번 사원의 나이를 조회 : 결과 27

    • A 트랜잭션에서 10번 사원의 나이를 27에서 28로 바꾸고 커밋

    • B 트랜잭션에서 10번 사원의 나이를 조회 : 결과 28

Repeatable Read(레벨 2)

  • 트랜잭션이 완료될 때까지 SELECT 문장이 사용되는 모든 데이터에 Shared Lock이 걸리는 계층

  • 트랜잭션이 범위 내에서 조회한 데이터 내용이 항상 동일함을 보장함

  • 다른 사용자는 트랜잭션 영역에 해당되는 데이터에 대한 수정 불가능

  • MySQL DBMS에서 기본으로 사용함

  • Non-Repeatable Read 부정합이 발생하지 않음

    • 10번 트랜잭션이 500번 사원을 조회

    • 12번 트랜잭션이 500번 사원의 이름을 변경하고 커밋

    • 10번 트랜잭션이 500번 사원을 다시 조회 : undo 영역에 백업된 데이터 반환

  • 자신의 트랜잭션 번호보다 낮은 트랜잭션 번호에서 변경된(커밋된) 것만 보게됨

    • 모든 InnoDB의 트랜잭션은 순차적으로 증가하는 고유한 트랜잭션 번호를 갖고 있으며, undo 영역에 백업된 모든 레코드는 변경을 발생시킨 트랜잭션의 번호를 포함하고 있음
  • Phantom Read 발생

Serializable(레벨 3)

  • 트랜잭션이 완료될 때까지 SELECT 문장이 사용되는 모든 데이터에 Shared Lock이 걸리는 계층

  • 가장 엄격한 격리 수준으로 완벽한 읽기 일관성 모드를 제공함

  • 다른 사용자는 트랜잭션 영역에 해당되는 데이터에 대한 수정 및 입력 불가능

선택시 고려사항

  • Isolation Level에 대한 조정은, 동시성과 데이터 무결성에 연관되어 있음

  • 동시성을 증가시키면 데이터 무결성에 문제가 발생하고, 데이터 무결성을 유지하면 동시성이 떨어지게 됨(레벨을 높게 조정할수록 발생하는 비용이 증가함)

무결성

  • 데이터의 정확성, 일관성, 유효성이 유지되는 것

  • 개체 무결성 : 모든 테이블이 기본키로 선택된 필드를 가져야함(기본키를 가져야함), 고유한 값, NULL 허용하지 않음

  • 참조 무결성 : 참조 관계에 있는 두 테이블의 데이터가 항상 일관된 값을 갖도록 유지, 참조 대상이 존재하지 않는 외래 키를 허용하지 않음

    • RESTRICTED : 레코드를 참조하고 있는 개체가 있다면, 변경 또는 삭제 연산을 취소

    • CASCADE : 레코드를 참조하고 있는 개체도 변경 또는 삭제

    • SET NULL : 레코드를 참조하고 있는 개체의 값을 NULL로 설정

  • 도메인 무결성 : 테이블에 존재하는 필드의 무결성 보장, 필드의 타입, null 값의 허용 등 사항을 정의하고 올바른 데이터가 입력되었는지 확인하는 것

  • 무결성 규칙 : 데이터의 무결성을 지키기 위한 모든 제약 사항을 말함, 데이터베이스 전체에 공통적으로 적용되는 규칙

낮은 단계 Isolation Level을 활용할 때 발생하는 현상들

Dirty Read

  • 어떤 트랜잭션에서 아직 실행이 끝나지 않은 트랜잭션에 의한 변경사항을 보게 되는 경우

  • 커밋되지 않은 수정중인 데이터를 다른 트랜잭션에서 읽을 수 있도록 허용할 때 발생하는 현상

Non-Repeatable Read

  • 한 트랜잭션에서 같은 쿼리를 두 번 수행할 때 그 사이에 다른 트랜잭션 값을 수정 또는 삭제하면서 두 쿼리의 결과가 상이하게 나타나는 일관성이 깨진 현상

  • 한 트랜잭션에서 똑같은 SELECT를 수행했을 때 항상 같은 결과를 반환해야 한다는 Repeatable Read 정합성에 어긋남

Phantom Read

  • 한 트랜잭션 안에서 일정 범위의 레코드를 두 번 이상 읽었을 때, 첫번째 쿼리에서 없던 레코드가 두번째 쿼리에서 나타나는 현상

  • 트랜잭션 도중 새로운 레코드 삽입을 허용하기 때문에 나타남

profile
측정할 수 없으면 관리할 수 없고, 관리할 수 없으면 개선시킬 수도 없다

0개의 댓글