트랜잭션 격리 수준이랑 동시에 여러 트랜잭션이 처리될 때, 트랜잭션끼리 얼마나 고립되어 있는지를 나타내는 것이다. READ UNCOMMITTED, READ COMMITTED, REPEATABLE READ, SERIALIZABLE 크게 네 가지로 나뉘고 순서대로 뒤로 갈수록 트랜잭션 간 고립 정도가 높아진다. 고립 정도가 높아지면, 성능이 떨어지는 것이 일반적이다. 보통의 경우 READ COMMITTED(oracle), REPEATABLE READ(mysql) 중 하나를 사용한다.
READ UNCOMMITTED
READ UNCOMMITTED의 경우 라나의 트랜잭션 변경이 commit, rollback에 상관없이 다른 트랜잭션에 영향을 미친다. 위의 사진과 같이 Transaction1이 INSERT 후 commit 하지 않더라도 Transaction2는 INSERT 이후의 데이터를 조회할 수 있다. 이 경우 Dirty Read 문제가 발생할 수 있다. Dirty Read란 트랜잭션에 의해 INSERT, UPDATE 된 데이터를 commit 하기 전에 읽는 것을 말한다. 만약 트랜잭션이 rollback 되더라도 UPDATE 된 값을 가지고 로직상에서 이용할 수 있기 때문에 대부분의 RDBMS에서 사용하지 않는다.
READ COMMITTED
READ COMMITTED의 경우 위의 예시처럼 Transaction1의 UPDATE 가 commit 된 후에만 변경사항이 가른 트랜잭션에 반영된다. Transaction1이 특정 값을 UPDATE 한 후 Transaction2가 그 값을 읽을 때, commit 전에는 UPDATE 하기 전 값, commit 후에는 UPDATE 한 후의 값을 조회한다. 이 경우 Non Repeatable Read 문제가 발생할 수 있는데, 이 문제는 하나의 트랜잭션에서 같은 값을 조회할 때 다른 트랜잭션의 commit 여부에 따라 다른 값이 조회되는 현상이다.
REPEATABLE READ
REPEATABLE READ의 경우 트랜잭션이 시작되고 종료되기 전까지 한 번 조회한 값은 계속 같은 값이 조회된다.
이 경우 UPDATE에 대해서는 데이터 정합성이 보장되지만, INSERT에 대해서는 보장되지 않는다.
Phantom Read 문제가 발생할 수 있는데 위의 사진에서는 UPDATE의 경우라 문제가 직접적으로 보이지 않지만, 예를 들어 Transaction1이 실행 중에 특정 조건으로 데이터를 조회하여 얻고, 이때 Transaction2가 접근하여 해당 조건의 데이터를 일부 추가, 삭제하면 종료되지 않은 Transaction1이 다시 동일 조건으로 데이터를 조회할 때, Transaction2에서 추가, 삭제된 데이터가 함께 조회되거나 누락되는 경우가 발생하고, 이후 Transaction2가 rollback을 하게 되면 데이터가 꼬이게 된다.
SERIALIZABLE
마지막으로 SERIALIZABLE의 경우 가장 엄격한 관리 수준으로 한 트랜잭션이 테이블을 읽으면 다른 트랜잭션은 그 테이블에 대해 추가/변경/삭제를 할 수 없다. 위의 세 가지 격리 수준에서 발생하는 정합성 문제는 발생하지 않지만, 동시 처리 성능이 가장 떨어지게 된다.
'💻CS' 카테고리의 다른 글
| [CS] DeadLock과 은행원 알고리즘 (0) | 2022.07.10 |
|---|---|
| [CS] DB Index (0) | 2022.07.03 |
| [CS] Pub/Sub 모델과 MQTT(Mosquitto) (0) | 2022.06.26 |
| [CS] CORS? (0) | 2022.06.25 |
| [CS] Session vs Cookie (0) | 2022.06.22 |