트랜잭션
DB에서의 트랜잭션은 하나의 기능을 하기 위한 여러 개의 작은 작업의 집합을 말한다. 많이들 예로 드는 A에서 B로의 계좌 이체를 보면, 계좌 이체 라는 트랜잭션은 아래 작업으로 나눌 수 있다.
- A 계좌 잔액을 조회
- A 계좌의 잔액을 차감
- B 계좌의 잔액을 업데이트
그리고 트랜잭션은 ACID라는 트랜잭션이 안전하게 수행되는 것을 보장하는 성질이 있다. ACID는 Atomicity, Consistency, Isolation, Durability의 앞 글자를 따서 만든 것으로 각각 이런 의미를 가지고 있다.
ACID
Atomicity 원자성
ACID를 찾아 본 사람이라면 잊을 수 없다. 어떤 사람은 All or nothing이라는 말이 여기서 나왔다고 하는데, 그건 알 수 없고(찾아보지 않았고) 어쨌든 All or nothing이다.
그 말은 위에서 트랜잭션을 말하면서 예로 든 계좌 이체를 구성하는 세 가지 개별 작업이 모두 성공적으로 수행되거나 하나도 수행되지 않거나 둘 중 하나라는 얘기다. 다시 말하면 A 계좌의 잔액을 차감만 하고 (어떤 이유에서든) B 계좌의 잔액을 업데이트하지 않은채 트랜잭션을 끝내 commit 해 버리면 안된다는 것.
원자성은 ACID의 다른 성질에 비해 비교적 이해하기가 쉽다. 그리고 앞글자여서 외우기도 쉽다.
Consistency 일관성
일관성은 여기저기 찾아보고 사람들이 열심히 설명을 한 것을 봐도 잘 이해가 안됐다. 솔직히 일관성을 지금도 100% 이해하는지 잘 모르겠다.
보통 하는 얘기들은 트랜잭션이 시작되기 전과 끝난 후의 데이터베이스의 상태가 일관적이라는 것이다. 그리고 유효해야 한다라는 얘기도 있다. 일관적이라는 것이 제약이나 규칙을 만족하는 것이라는데 솔직히 잘 이해가 안되고요.
그냥 DB에 설정된 제약, 정확히는 Table에 설정된 제약, 예를 들면 어떤 컬럼은 숫자만 들어가야 한다거나, 공백을 허용하지 않는다는가 하는 제약을 지키지 않는 트랜잭션은 수행을 하지 않는다는 얘기같다.
또 어떤 설명에서는 일관성은 DB의 책임이 아닌 Application의 책임이라고도 한다. 이 얘기도 틀린 얘기같지는 않다, 사실 개발자의 입장에서는 DB를 Application 없이 단독으로 사용하지 않기 때문에 트랜잭션의 일관성을 Application 레벨에서 지킬 수 있게 한다면 저 얘기도 맞는 것 같다.
어쨌든 일관성의 예로 들만한 것은 이런 것이 있다.
- DB에 모든 사용자는 이름을 가지고 있어야 한다는 제약이 있다고 할 때
- 아래의 트랜잭션은 일관성을 위반해 실행하지 않는다.
- 이름이 없는 사용자를 추가
- 기존 사용자의 이름을 삭제
Isolation 격리
모든 트랜잭션은 격리된 상태에서 독립적으로 수행되어야 한다. 그래도 여러 개의 트랜잭션이 동시에 수행되더라도 연속으로 실행한 것과 동일한 결과가 나와야 한다.
보통의 상황에서 DB는 하나의 클라이언트에서 한 번에 하나씩의 요청만 처리하는 것이 아니다. 여러 클라이언트가 동시에 접속을 시도하고 이 때 동시성 문제(경쟁조건)가 발생한다.
예를 들어 위 그림과 같이 두 클라이언트가 하나의 DB에 동시에 접속해 카운트를 1만큼 증가하려고 할 때, User 1이 42에서 43으로 증가시키고 커밋하기 전에 User 2가 조회한 결과인 42를 1 증가해 커밋하면 기대한 44가 아닌 43이 최종 결과가 된다.
Durability 지속성
이것도 일관성과 비슷하게 무슨 얘기인지 정확히 잘 몰랐지만, Data가 일단 저장되면 손실될 염려가 없어야 한다는 것으로 이해했다. 더불어 AWS의 Multi AZ와 같이 여러 위치에 분산 저장하는 DB라면 다른 위치의 DB에도 동일한 변경 내용이 저장되는 것, 그리고 Master-Slave라면 M과 S 모두에 동일한 내용이 업데이트 되는 것도 지속성과 관련이 있다.
이해가 잘 안됐던 이유는 소프트웨어적인 내용이 아닌 하드웨어에 가까운 내용이라고 생각해서 였지만 그것도 결국 DB의 트랜잭션에 안전성을 제공하기 위한 요소라는 것으로 이해하기로 했다.
