트랜잭션 격리수준 (Transaction Isolation)에 따른 데이터 불일치 현상

Trasnaction 격리수준을 왜 다르게 해야 할까?

성능 때문에

 

Transaction은 여러개의 작업을 하나의 작업으로 묶는 역할을 합니다. 흔히 ACID라고 줄여 부르는 특징을 가지고 있습니다.

애플리케이션이 복잡해 지면 Transaction이 길어지고, 자연스럽게 같은 데이터를 여러 Transaction이 써야 할 일이 생기게 됩니다. 직관적으로는 Transaction이 데이터를 사용중이면 다른 Transaction은 사용할 수 없도록 Lock을 걸면 되지만 그렇게 하면 데이터가 필요한 다른 모든 Transaction이 그 시간동안 대기해야 합니다. 

그래서 한 Transaction이 데이터를 사용중일때, 다른 Transaction이 어떻게 처리할지에 관한 전략을 격리수준 (Isolation Level)이라 합니다. 당연히 격리수준이 높을 수록 성능은 낮아지지만 데이터의 신뢰성을 올라가고, 격리수준이 낮을 때는 그 반대입니다.

---

Transaction 격리수준과 이상현상

	Dirty Read	Non-Repeatable Read	Phantom Read
Read Uncommitted	O	O	O
Read Committed		O	O
Repeatable Read			O
Serializable

보통 Transaction 격리 수준은 4가지가 있고, 밑으로 갈 수록 이상현상이 나타나지 않는 대신 속도가 떨어집니다. 

Transaction 격리 수준에 따라 나타나는 이상현상 3가지를 간단히 알아보겠습니다.

---

Dirty Read

1개의 Transaction이 데이터는 변경했는데 아직 commit을 안 해서 Rollback 될 가능성이 있는 데이터를 다른 Transaction이 읽는 현상

 

Dirty Read (더러운 읽기(?))는 Transaction이 rollback 될 수 있다는 사실에서 나옵니다. Read Uncommitted라는 격리수준 이름에서 짐작할 수 있듯, 아직 commit 되지 않은 데이터를 읽을 수 있으면 만약 Rollback 될 경우 잘못된 데이터 (더러운 데이터)를 읽어온 가능성이 존재합니다.

---

Non-Repeatable Read

1개의 Transaction이 데이터를 읽어 왔는데 그 사이에 다른 Transaction이 데이터를 변경해서 같은 곳에서 데이터를 읽어 왔는데 다른 데이터가 오는 현상

 

Non-Repeatable Read (반복될 수 없는 읽기)라는 이름에서 알 수 있듯, 똑같은 데이터를 읽었는데 다른 데이터가 오는 현상입니다. 

이를 막기 위해서는 결국 Lock을 걸 수 밖에 없습니다.

1. 비관적 락 (Pessimistic Lock)

2. 낙관적 락 (Optimistic Lock)

---

Phantom Read

특정 조건에 맞는 데이터를 가져왔는데 commit 되기 전에 다른 Transaction이 그 조건에 맞는 다른 데이터를 insert해서 처음 읽은 데이터에 조건에 맞지만 못 읽은 데이터가 있는 현상

 

Phantom Read (유령 읽기(?))는 조건에 맞는 데이터를 모두 읽지 못 해 유령같이 존재하지만 내가 (Transaction)이 가지고 있지 않은 데이터가 존재하는 현상입니다.

이를 막기 위해서는 결국 한 Transaction이 무언가를 하는 동안 다른 Transaction은 아무것도 할 수 없게 해야 합니다. 그래서 Serialization이라는, 가장 강력한 Transaction 격리수준을 설정해야 Phantom Read를 예방할 수 있습니다.

보통 데이터 정합성이 이 정도로 중요하지는 않기 때문에 Phantom Read는 감수하는 경우가 많습니다.

---