Transaction은 여러 SQL 작업을 하나의 작업처럼 다루는 단위입니다. 예를 들어 계좌 이체에서는 A 계좌 차감과 B 계좌 증가가 둘 다 성공하거나 둘 다 실패해야 합니다.
ACID는 transaction의 성질을 설명합니다. Atomicity는 전부 성공하거나 전부 실패하는 원자성, Consistency는 transaction 전후 데이터 제약이 지켜지는 일관성, Isolation은 동시에 실행되는 transaction이 서로 어긋난 중간 상태를 보지 않게 하는 격리성, Durability는 commit된 결과가 장애 후에도 유지되는 지속성입니다.
꼬리질문
조금 더 깊게 물어본다면
답변 뒤에 이어질 수 있는 질문들을 하나씩 열어볼 수 있어요.
Atomicity와 Consistency는 어떻게 다른가요?
Atomicity는 transaction 내부 작업이 전부 반영되거나 전부 취소되는 성질입니다. Consistency는 transaction 전후로 database의 제약과 규칙이 깨지지 않는 성질입니다.
예를 들어 이체에서 한쪽만 반영되지 않는 것은 atomicity와 관련 있고, balance가 음수가 되면 안 된다는 규칙은 consistency와 연결됩니다.
Isolation은 왜 필요한가요?
동시에 여러 transaction이 실행될 때 서로의 중간 상태를 보거나 덮어쓰면 이상한 결과가 생길 수 있습니다. isolation은 이런 간섭을 제어합니다.
하지만 강한 isolation은 lock 증가와 성능 저하를 만들 수 있습니다.
Durability는 어떻게 보장하나요?
DB는 commit된 변경을 log에 기록하거나 storage에 안전하게 반영해 장애 이후에도 복구할 수 있게 합니다. WAL 같은 기법이 관련됩니다.
세부 구현은 DB마다 다르지만 commit 후 결과가 사라지지 않게 하는 것이 핵심입니다.
transaction을 길게 유지하면 어떤 문제가 있나요?
lock을 오래 잡거나 version을 오래 유지해 다른 transaction을 방해할 수 있습니다. connection 자원도 오래 사용합니다.
transaction 범위는 꼭 필요한 작업으로 좁히는 것이 중요합니다.
부가 설명
BEGIN;UPDATE accounts SET balance = balance - 100 WHERE id = 1;UPDATE accounts SET balance = balance + 100 WHERE id = 2;COMMIT;
중간에 실패하면 rollback되어 한쪽만 반영되는 상태를 피해야 합니다.
ACID는 결제, 예약, 재고 차감처럼 여러 변경이 하나의 의미를 가질 때 드러납니다. 일부 변경만 반영되면 데이터가 실제 업무 상태와 어긋나기 때문에 transaction이 필요합니다.
다만 isolation을 강하게 하면 동시성이 줄고 성능 비용이 생길 수 있습니다. 그래서 isolation level을 상황에 맞게 선택합니다.
한 줄 정리
transaction은 여러 DB 작업을 하나의 의미 있는 단위로 묶고, ACID는 그 단위가 안전하게 실행되기 위한 성질입니다.