Isolation level (트랜잭션 고립(격리) 수준)

Isolation Levels (트랜잭션 고립(격리) 수준)

• 우선 Transaction에서 사용 되는 개념이다.

• SQL은 4개의 Isolation level을 정의하고 있다.

  READ UNCOMMITTED,

  READ COMMITED,

  REPEATABLE READ,

  SERIALZABLE

• 각 Storage Engine 혹은 DBMS 마다 조금씩 다르게 구현 되어 있다.

  따라서, 어떤것을 사용하기 전에 메뉴얼을 읽어보자(언제 읽냐...)

 

---

 

READ UNCOMMITTED

• Transaction은 uncommitted 결과를 볼 수 있다.

• 이 단계에서 너가 정말 정말 좋은 의도로 개발을 했지만 많은 문제가 발생할 수 있다.

• 이 단계는 거의 실용적이지 않다. 왜냐하면, 성능이 다른 레벨들보다 좋지 않기 때문이다.

• uncommitted data를 읽는 것은 'dirty read' 라고도 알려져 있다.

 

Transaction 이 끝나지 않은 상황에서 각기 다른 Transaction이 변경한 내용에 대한 조회가 가능합니다. 데이터베이서의 일관성을 유지할 수 없습니다

 

Transaction1이 수행중에 Transaction2가 값을 변경할 경우 Transaction1이 다시 조회를 하는 시점에 이미 Transaction2가 값을 변경하였기 때문에 아무개에서 개발자로 값이 변경되어 조회가 됩니다.

 

---

 

READ COMMITED

• DBMS의 default isolation level 이다. (MySQL 제외하고...)

• 트랜잭션 시작하고 이미 commit 된 변화를 볼 수 있지만, commit 완료 전까지는 확인이 불가하다.

• 'nonrepeatable read' 라고 알려져 있는데, 의미는 너가 똑같은 구문을 2번 실행할 수 있고 다른 결과를 볼 수 있다.

 

조회 시 데이터에 대한 Shared lock이 됩니다. Read Uncommitted와 다르게 Commit이 이루어진 데이터가 조회됩니다. 하지만 어떠한 사용자가 A라는 데이터를 B라는 데이터르 변경하는 동안 다른 Transaction은 접근할 수 없어 대기하게 됩니다.

 

1) Transaction2가 Update를 하게됩니다. 

2) 아직 커밋하지 않아 Transaction1은 Select를 하지 못하고 대기하게 됩니다. 

3) Transaction2가 Commit명령어를 날리게됩니다. 

4) 이제 Transaction2는 조회가 가능합니다.

 

---

 

REPEATABLE READ 

• REPEATABLE READ 는 READ UNCOMMITTED 가 허락한 문제들을 해결 한다. 

• 같은 Transaction 안에서 Transaction이 읽고 있는 어느 rows은 그 다음에 읽어도 같은 것을 볼 것을 보장하지만, 이론적으로 phantom reads에 대해서 또다른 문제가 있을 수 있다. 

  (Phantom read는 너가 특정 범위에 rows를 SELECT 했을 때, 또 다른 Transaction이 그 범위에 Insert를 하였고 너가 또 같은 범위를 SELECT 했을 때 발생할 수 있고, 너는 Phantom row를 볼 수 있을 거다)

• InnoDB와 XtraDB는 multiversion concurrency control 로 phantom read를 해결한다. (멀티버전 동시진행 제어가 뭐야??)

• MySQL의 기본 Transaction 고립 레벨

 

Transaction이 범위내에서는 조회한 데이터의 내용이 항상 동일함을 보장해줍니다.

 

1) Transaction1이 Select시점에 아무개가 조회됩니다. 

2) Transaction2가 Update후 Commit을 시행하였지만 Update가 안됩니다. 그러나 Insert는 됩니다. 

3) Transaction1이 다시 조회 해봐두 Transaction2가 Commit이 되지 않았기 때문에 아무개로 조회됩니다. 하지만 Insert한 동네개발자는 조회됩니다.

4) Transaction1이 종료되면 다시 Commit이 이루어지기 때문에 개발자로 조회가 됩니다.

 

 

---

 

SERIALIZABLE 

• 최상위 고립 레벨의 SERIALIZABLE 은 phantom read를 해결하기 위해서 충돌하지 않도록 Transactio들에게 강제로 명령을 한다.

• 읽은 모든 row에 락을 걸고, 이 단계에서 많은 타임아웃과 락 논쟁이 발생할 수 있다.

• 저자는 이 고립 레벨을 사용하는 사람들을 거의 못 봤다고 한다. 하지만, 너의 프로그램이 필요하다면 데이터의 안정성을 위해서 사용을 해야할 수도 있다고 한다.(예상되는 문제들에 대해서 개발자가 처리를 많이 해줘야 하나 보네)

 

 

 

말 그대로 직렬화를 이야기합니다. 그래서 모든 동작이 직렬화 되어 작동합니다. Repeatable Read와 다르게 Insert를 하여도 작동하지 않게 됩니다.

 

 

---