13. 트랜잭션

사실 데이터를 저장하려면 파일에 그냥 저장해도 된다.

근데 DB를 굳이 쓰는 이유는?

DB는 트랜잭션이라는 개념을 지원하기 때문.

 

 

트랜잭션(Transaction)을 직역하면 거래라는 뜻인데,

트랜잭션은 하나의 안전한 거래를 보장해준다는 거다.

 

예를 들어 A와 B가 계좌이체를 한다고 했을 때,

A의 잔고에서 5천원이 감소하고, B의 잔고에서 5천원이 증가하여야 한다.

근데 만약 A의 잔고에서 5천원이 감소한 상황에서, B의 잔고에서 5천원을 증가시키려고 했을 때 오류가 발생한다면?

 

그냥 A의 돈만 날리는 거다.

 

이러 한 점을 방지하기 위해, DB가 제공하는 트랜잭션 기능이란 저 둘이 하나라도 실패하면 거래 전의 상태로 돌아가 준다.

 

모든 작업을 성공해 DB에 정상 반영하는 것을 커밋(commit), 작업 도중 실패하여 되돌아 오는 것을 rollback 이라고 한다.

 

트랜잭션은 

Atomicity 원자성 : 트랜잭션 내에서 실행한 작업은 마치 하나의 작업인 것 처럼 모두 성공하고나 모두 실패하여야 한다. (하나의 원자처럼)

Consistency 일관성 : 모든 트랜잭션은 일관성 있는 DB 상태를 유지하여야 한다. 예를 들어 DB에서 정한 무결성 제약 조건을 항상 만족해야 한다... 그냥 뭐 어떤 상황에서는 이렇고 어떤 상황에서는 저렇고 그러면 안된다는 뜻이다. 

Isolation 격리성 : 동시에 실행되는 트랜잭션들이 다른 트랜잭션에게 영향을 미치면 안되도록 격리 되어야 한다. 예를 들어 동시에 같은 데이터를 수정하지 못하도록.

Isolation 지속성 : 성공적으로 끝마쳐진 트랜잭션은 항상 그 결과가 기록되어야 한다. 서비스 도중 문제가 발생 해도 DB의 로그등을 통해서 성공한 트랜잭션의 내용을 복구하거나 그러기 위해서.

 

들을 보장 해야 한다.

근데 격리성.. 을 보장하려면 사실 트랜잭션을 완전히 순서대로 처리해야 한다. 근데 이렇게하면 사실 동시처리 성능이 매우 나빠진다. 병렬처리가 안된다.

이런 문제로 인해 ANSI표준은 트랜잭션의 격리 수준을 4단계로 나누어 정의했다.

READ UNCOMMITED 커밋되지 않은 거 읽기

READ COMMITTED 커밋된 것만 읽기

REPEATABLE READ 반복 가능한 읽기

SERIALIZABLE 직렬화 가능

 

일반적으로는 READ COMMITTED 많이 사용함.

REPEATABLE READ도 씀

 

아래로 갈수록 점점 성능이 안좋아 진다고 생각하면 됨.

 

 

커밋되지 않은 걸 보는 건 아직 트랜잭션이 다 끝마치지도 않았는데 그 데이터를 볼 수도 있음.

 

 

중요한 것은 위의 거래 예시처럼 저런 여러가지 행위들을 하나로 묶을 수 있고, (5천원 증가, 5천원 감소)

모두 커밋, 모두 롤백 이 두가지 상황만 있어야 한다는 점.