1. 트랜잭션

트랜잭션이란 데이터를 올바르게 보장하기 위해 고안된 방법이다.

트랜잭션 이론은 관계형 모델과는 다른 이론이다. 트랜잭션과 관계형 모델에서 정규화 이론은 각 데이터를 올바르게 보장하는 것을 목적이지만, 착안점이 다르다

실제 응용프로그램 개발에서는 양쪽 모두 필요하며 상호 보완적인 관계라고 할 수 있다. 트랜잭션과 관계형 모델 두 가지를 동시에 구현해야 비로소 데이터의 정합성을 보장할 수 있다.

트랜잭션의 기능

트랜잭션이 요구되는 배경에는 DB 서버에 여러 개의 클라이언트로부터 동시에 엑세스가 발생하는 상황이나 DB 서버 또는 응용프로그램이 갱신을 처리하는 도중에 중단되는 사태에서 데이터의 부정합을 방지하고자 하는 요구가 있다.

가장 유명한 예시는 은행의 계좌를 병렬 처리하는 예다.

병렬 처리하는 은행

트랜잭션1	트랜잭션2	계좌잔액
(시작) 잔액을 읽음: 1,000,000		1,000,000
	(시작) 잔액을 읽음: 1,000,000
(입금) +300,000
잔액 기록: 1,300,000 (커밋)		1,300,000
	(인출) -200,000
	잔액 기록: 800,000 (커밋)	800,000

동시 실행 제어

두 개의 처리가 동시에 실행되며 트랜잭션1이 잔액을 작성하기 전에 트랜잭션2가 잔액을 읽기 때문에 바뀐 잔액이 없어진다. 실 잔액은 1,100,000원 이어야 하지만 800,000원만 남는다.

동시에 엑세스를 함으로써 발생하는 데이터의 부정합을 막는 동시 실행 제한이 트랜잭션의 첫 번째 기능이다.

크래시 복구

예상하지 못한 사태가 생겼을 때 어떻게 해야 데이터를 올바르게 유지해야 할까?

만약 트랜잭션2가 잔액을 기록하기 전에 시스템이 크래시 되나면 이번에는 돈을 찾았으므로 계좌의 잔액이 증가하게 된다.

또한, 트랜잭션이 없다면 시스템이 크래시되기 직전에 어디까지 처리를 실행했는지 어떻게 추적할 수 있을까?

응용프로그램에서 처리가 어디까지 실행됐는지 감지하고 필요한 복구 작업을 처리하기 위한 기능을 구현하지 않으면 안 된다.

그러나 트랜잭션이 있다면 비정상적으로 중단된 처리는 롤백되며 시스템이나 DB 서버가 크래시돼도 재기동하면 자동으로 필요한 복구 작업을 수행한다.

트랜잭션으로 제공되는 기능은 본질적으로 동시 실행 제어와 크래시 복구 두 가지다.

트랜잭션의 키: 스케줄

처리의 병렬화는 필수불가결

부정합을 일으키지 않는 가장 쉬운 해결법은 여러 개의 클라이언트로부터 처리를 병렬로 하지 않는 것이다. 즉, 프로세스를 하나씩 차례대로 수행하면 동시 실행하는 발생하는 부정합은 일어나지 않는다.

하지만 병렬화 하지 않는 구조는 처리 효율이 낮아져 성능을 발휘하지 못하므로 현실적인 대책이라 할 수 없다.

실제 DB에서는 수백, 때에 따라서는 수천 개의 트랜잭션이 동시에 수행되는 것도 드문 일이 아니다.

동시 실행 제한의 키: 스케줄

트랜잭션은 일련의 작업을 정리한 것이다. 트랜잭션은 여러 개의 데이터 항목의 조작으로 분해할 수 있다.

→ 처리의 단위는 각 데이터 항목에 대해 읽기나 쓰기와 같은 조작이다.

트랜잭션을 병렬로 동시 실행하는 것은 개별 데이터 항목의 조작을 동시에 실행하는 것과 같다. 그러나 처리 내용에 따라서는 다른 트랜잭션에 영향을 미치는 것이 있다.

트랜잭션 사이에서 서로의 결과에 영향을 주지 않도록 스케줄링할 수 있다면 이 트랜잭션은 병렬로 실행할 수 있다

데이터의 정확성의 정의

트랜잭션은 데이터를 올바르게 유지하는 방법이다.

데이터가 올바르게 유지되는 상태란 개별 트랜잭션을 한 개씩 차례로 실행할 때와 같은 결과가 될 것이다.

한 개씩 차례대로 실행하는 스케줄을 직렬화된 스케줄이라 한다. 개별 트랜잭션을 직렬로 실행할 때와 같은 결과가 나오는 스케줄이라면 처리를 병렬로 실행해도 영향이 없다는 것이므로 트랜잭션을 실행한 후의 데이터가 올바르게 유지됐다고 할 수 있다.

→ 올바른 결과가 나오는 스케줄은 직렬화된 스케줄과 같은 결과가 나오는 스케줄을 말한다.

스케줄러의 성능

스케줄러의 성능에서 중요한 점은 두가지다.

1. 얼마나 많은 트랜잭션을 병렬화할 수 있는지다. 동시에 실행하는 트랜잭션이 많으면 많을수록 그 스케줄러의 성능은 좋다.
2. 최적의 스케줄을 찾는데 필요한 비용이다. 여러 개의 트랜잭션이 있을 때 그 중에서 동시에 실행할 수 있는 조합 중 최적의 조합을 찾게 되면 이는 조합의 최적화의 문제가 되므로 계산에 드는 비용이 막대하다.

RDB에서는 잠금 스케줄러라는 로직을 일반적으로 널리 사용한다. 잠금 스케줄러는 구현이 비교적 쉬운 편이며 일반적으로 충분한 성능을 낼 수 있다고 알려졌다.

2. 트랜잭션의 특징

ACID란?

A(Atomicity: 원자성)

트랜잭션에 포함된 모든 작업이 성공(Commit) 또는 실패(Abort)하는 성질을 원자성이라고 한다.

실패한 경우를 SQL에서는 롤백(ROLLBACK)이라고 하고 트랜잭션 이론에선 Abort라고 한다.

원자성은 다른 말로 트랜잭션이 어중간한 상태가 되지 않게 하는 성질이다.

→ 응용프로그램은 트랜잭션을 실행한 후에 두 개의 상태만 고려하면 된다.

이로 인해 에러처리가 매우 단순해진다는 장점이 있다. Abort 되면 트랜잭션을 처음으로 다시 하면 된다.

이처럼 편리한 원자성이지만 트랜잭션이 Abort 될 가능성이 0이 될 수는 없다. 트랜잭션은 다양한 이유로 실패할 가능성이 있다. 보장되는 것은 실행 후의 상태가 성공인지 실패인지 두 가지가 된다는 것뿐이다.

Abort 할 가능성이 0이 될 수 없으므로 응용프로그램은 Abort가 발생했을 때의 오류처리만은 반드시 구현해야 한다. 일반적으로 에러 처리로 실행해야 할 것은 트랜잭션의 리트라이(재실행)다.

트랜잭션은 반드시 성공한다고 보장하는 것이 아니라 실패하면 취소된다는 것을 보장하는 것에 지나지 않는다.

원자성은 트랜잭션이 실패했을 때 롤백할 수 있다는 것이다.

Abort 할 것을 예상하지 않은 응용프로그램, 즉 오류 처리(리트라이)를 구현하지 않은 응용프로그램은 근본적으로 트랜잭션의 사용법 자체가 틀렸다고 할 수 있다.

C(Consistensy: 일관성)

일관성이란 트랜잭션을 실시한 전후에는 데이터의 일관성이 손상되지 않아야 한다는 성질이다.

예를 들어 RDB에서 트랜잭션 실행 전의 DB의 상태는 일관성이 있는 것(데이터의 부정합이 없음)이며,

트랜잭션 실행 후에 데이터의 변경은 있지만, 일관성이 유지되고 있다. → 트랜잭션을 실행하면 DB는 일관성이 있는 상태에서 다른 일관성이 있는 상태로 전환한다고 할 수 있다.

어떤 상태가 일관성이 있는가를 결정하는 것은 DB가 아니며, 데이터의 의미를 이해하고 있지 않다.

데이터의 의미를 부여하는 것은 응용프로그램의 역할이며 일관성이 있는지 판단하는 것은 응용프로그램밖에 할 수 없다. → 트랜잭션의 기능만으로 일관성을 보장할 수 없다.

I(Isolation: 격리성)

격리성이란 동시에 실행하는 여러 개의 트랜잭션이 서로 영향을 주지 않는 성질이다.

격리성을 해치는 스케줄은 스케줄러가 사전에 제거하지만, 문제를 감지했을 때 롤백 될 수도 있다. 격리성은 트랜잭션의 동시 실행 제어에 관한 성질을 가장 잘 나타낸 것이라고 할 수 있다.

D(Durability: 영속성)

영속성이란 일단 커밋이 완료된 트랜잭션이 손상되지 않는 성질이다.

확정된 트랜잭션을 취소할 수 없게 로직을 구현하는 것은 물론이고, 시스템이 크래시 됐을 때도 재기동한 다음에 복구하여 데이터를 크래시 전의 상태로 복원할 수 있다는 점이 중요하다.

크래시 복구 후에는 크래시 전에 커밋한 데이터만 남게 된다. 커밋이 완료된 시점에는 DB의 일관성이 보장돼 있으므로 크래시 복구가 완료되면 일관성에 대해서 걱정할 필요 없다.

다양한 비정상 상태

ACID는 트랜잭션이 가져야 할 성질이다. 이번에는 트랜잭션에서 있어서는 안 되는 상태에 관해 설명한다.

갱신 분실

트랜잭션1	트랜잭션2	계좌잔액
(시작) 잔액을 읽음: 1,000,000		1,000,000
	(시작) 잔액을 읽음: 1,000,000
(입금) +300,000
잔액 기록: 1,300,000 (커밋)		1,300,000
	(인출) -200,000
	잔액 기록: 800,000 (커밋)	800,000

만약 트랜잭션2가 트랜잭션1이 갱신하기 전의 데이터를 기준으로 같은 데이터를 갱신한다면 트랜잭션1로 발생한 갱신은 유실될 것이다. → 갱신 분실

위 그림은 전형적인 갱신 분실의 예다.

모순적 판독

어떤 트랜잭션의 실행 결과가 다른 트랜잭션의 실행 결과에 영향을 주면 트랜잭션이 읽은 데이터의 정합성은 보장되지 않는다. → 모순적 판독(Inconsistent read)

트랜잭션1	트랜잭션2	X 계좌잔액	Y 계좌잔액
(시작) 잔액을 읽음: 1,000,000		1,000,000	1,000,000
(인출) -100,000
잔액 기록: 900,000		900,000
	(시작) 잔액 X 읽음: 900,000 // 잔액 Y 읽음: 1,000,000	1,300,000
	잔액 합계 계산: 1,900,000 (커밋)
잔액 Y 읽음: 1,000,000
(입금) +100,000
잔액 Y 기록: 1,100,000(커밋)			1,100,000

트랜잭션1에 의해 계좌 X와 계좌 Y의 잔액은 각각 감액, 증액하지만, 합계는 변하지 않는다. 그런데 트랜잭션2가 읽은 금액은 원래 있어야 할 돈보다 10만원이 적다.

더티 리드(Dirty Read)

더티 리드는 아직 커밋되지 않은 데이터를 읽음으로써 발생하는 비정상 상태다.

트랜잭션1	트랜잭션2	계좌잔액
(시작) 잔액을 읽음: 1,000,000		1,000,000
(입금) +300,000
잔액 기록: 1,300,000 (커밋)		1,300,000
	(시작) 잔액을 읽음: 1,300,000
ROLLBACK
	(인출) -200,000
	잔액 기록: 1,100,000 (커밋)	1,100,000

트랜잭션1이 어떤 이유로 Abort(ROLLBACK)할 경우 트랜잭션2가 읽은 데이터는 올바르지 않은 데이터가 된다.

트랜잭션2는 20만원을 찾는 작업이지만 트랜잭션1에 의해 더티 리드된 데이터를 읽고 있어서 계좌의 잔액이 원래 있어야할 금액보다 30만원이 늘었다.

논 리피터블 리드(Non Repeatable Read)

논 리피터블 리드란 한 개의 트랜잭션에 같은 데이터 항목을 여러 번 읽을 때 그 트랜잭션이 쓰기를 하지 않는데도 값을 바꾸어 버리는 현상이다

트랜잭션1	트랜잭션2	계좌잔액
(시작) 잔액을 읽음: 1,000,000		1,000,000
	(시작) 잔액을 읽음: 1,000,000
	(인출) -200,000
	잔액 기록: 800,000 (커밋)
잔액을 읽음: 800,000(커밋)

트랜잭션1은 집계처리다. 트랜잭션1이 종료되지 않은 사이에 트랜잭션1을 이미 참조한 데이터는 트랜잭션2에 의해 바뀐다. → 두 번째로 같은 계좌의 잔액을 읽을 때는 잔액이 줄게 된다.

논 리피터블 리드는 같은 데이터 항목을 여러 번 읽을 때 이전과 다른 결과가 나오는 문제다.

→ 시간 축에 따라서 정합성이 보장되지 않는 문제다.

팬텀 리드(Phantom Read)

팬텀 리드란 SQL과 같은 범위 검색이 있는 시스템에서 주로 일어나는 문제다. 기존의 데이터 항목 값에 이상을 일으키는 것이 아니라 과거에 없었던 데이터가 나오는 것이다.

트랜잭션1	트랜잭션2	계좌잔액
(준비)
CREATE TABLE t (id INT UNSIGNED NOT NULL, PRIMARY KEY(ID));
INSERT INTO t VALUES(1) COMMIT
(시작) SELECT * FROM t; (결과) 1
	(시작) INSERT INTO t VALUES(2); COMMIT
SELECT * FROM t; → (결과) 1, 2 COMMIT

트랜잭션1은 원래 1행만 읽어야 하나 트랜잭션2에 의해 새로운 행이 삽입된 다음에는 그 행도 읽어버리게 된다.

스케줄과 잠금

비정상 상태는 모두 동시성 문제다. 각 처리를 순서대로 수행하면 문제가 발생하지 않는다. 스케줄이라는 관점에서 보면 앞에서 언급한 비정상 상태가 발생하는 스케줄은 원래 실행하면 안 되는 것이다. 따라서 그런 스케줄이 발생하지 않도록 트랜잭션의 스케줄을 결정해야 한다.

RDB에서 가장 일반적인 방법은 잠금을 사용해 단독 처리하는 방법이다. 일반적으로 잠금을 이용한 스케줄을 락킹스케줄이라고 한다. 어떤 행(=데이터 항목)이 필요한지는 실제 쿼리를 실행해야 하므로 트랜잭션을 실행하기 전까지는 스케줄이 결정할 수 없다.

→ 쿼리의 실행에 따라 트랜잭션 내에 데이터의 일관성이 무너지지 않도록 작업 대상이 되는 행에 대해 그 작업이 수행되기 전에 잠금을 거는 방법을 채택하고 있다.

잠금을 사용하면 데이터의 정합성을 해치는 각종 비정상 상태가 발생하지 않는 스케줄이 되도록 경합하는 데이터 항목에 엑세스를 필요로 하는 트랜잭션을 차단하게 된다.

교착 상태(Dead Lock)

트랜잭션이 필요로 하는 데이터 항목을 순서대로 잠그는 아키텍처는 교착 상태라는 문제가 있다. RDB는 행 수주느이 잠금 혹은 페이지 수준의 잠금으로 구현돼 있으며 이러한 현상이 일어난다.

트랜잭션1	트랜잭션2
계좌 X 잠금
계좌 X 읽음: 1,000,000
(인출) -100,000
잔액 기록: 900,000
	계좌 Y를 잠금
	계좌 Y 읽음: 1,000,000
	(인출) -100,000
	잔액 기록: 900,000
계좌 Y 잠금
차단
	계좌 X 잠금
	차단

위 표처럼 양쪽의 트랜잭션이 서로 차단하는 상태가 되면 어느 쪽도 트랜잭션도 진행할 수 없는 막다른 길이 되어 버린다. → 교착 상태

교착 상태가 발생했다는 것은 만약에 잠금을 하지 않고 그대로 처리했다면 데이터의 부정합이 일어난다는 의미다. 이런 스케줄은 허용할 수 없으므로 교착 상태에 빠진 트랜잭션은 롤백해야 한다.

교착 상태를 어떻게 해소하는가는 구현하기에 따라 다르다. 예를 들어 교착상태를 감지할 수 있다면 양쪽 모두 롤백하거나, 한쪽만 롤백하거나 하나만 롤백한다면 어떤 기준으로 롤백하는 쪽을 정할 것인가 등이다.

교착 상태의 감지 기능이 없다면 잠금이 타임아웃될 때까지 기다려야 할 것이다.

교착 상태는 일반적으로 락킹스케줄러가 있는 RDB에서는 반드시 일어날 수 있는 문제다. 그 결과 트랜잭션은 Abort 하므로 일반적인 DB 응용프로그램은 오류 처리가 필요하다.

트랜잭션 격리 수준

SERIALIZABLE

가장 격리성(독립성) 높고 트랜잭션을 실행한 결과가 직렬화된 스케줄과 같은 결과가 되는 것을 보장한다. 이런 보장이 가능한 격리 수준은 SERIALIZABLE 뿐이다. 다른 격리 수준은 앞에서 열거한 이상 현상을 완전히 막을 수 없다.

SERIALIZABLE은 높은 신뢰성의 대가로 성능이 비교적 낮은 경향이 있다. 여기에서 성능이란 트랜잭션의 병렬 정도다. SERIALIZABLE은 잠금을 많이 사용하므로 교착상태(데드락)의 확률도 올라가고 잠금 경합에 따라 차단되는 경우도 많다.

SERIALIZABLE 이외에는 각종 이상 현상이 일어날 가능성이 있다. 그러나 그 대신에 병렬성 향상이라는 이점을 누릴 수 있다.

READ-UNCOMMITED

더티 리드가 발생하는 격리 수준으로 더티 리드를 허용하여 롤백이 무방비 상태가 된다.

READ-COMMITED, REPEATABLE-READ

번거로움과 리스크를 감수하더라고 성능이 필요할 때 사용한다.

READ-COMMITED: 커밋된 아이템을 읽을 수 있는 모드, 같은 트랜잭션에서는 최근의 스냅샷을 읽는다.

REPEATABLE-READ: 첫 번째 읽기에 스냅샷을 생성. 이후 동일 트랜잭션에서는 스냅샷부터 값을 읽는다.

MVCC

트랜잭션의 병렬도가 높아지면 어떤 트랜잭션이 갱신되고, 아직 커밋되지 않은 행을 다른 트랜잭션이 참조하는 경우가 발생할 수 있다. → 어떤 시점에서 참조의 일관성이 있다면 좋다.

단순한 잠금이라는 구조에 의존한다면 다른 트랜잭션은 잠금이 해제될 때까지 기다린다.

만약 잠금을 기다리고 있는 트랜잭션의 시간이 오래 걸리면 여러 개의 트랜잭션이 차단될 지도 모른다. 이와 같은 현상을 해결하고 병렬성을 높이기 위해서 고안된 구조가 MVCC(MultiVersion Concurrency Control)이다.

MVCC를 사용하면 어떤 트랜잭션이 갱신한 데이터에 대해 다른 트랜잭션은 과거의 이전 버전을 참조할 수 있다.

→ 모순적 판독을 막으면서 병렬도를 높일 수 있다.

MVCC의 예시

트랜잭션1	트랜잭션2	X 계좌잔액(최신)	X 잔액 (이전)	Y 계좌잔액
(시작) 잔액을 읽음: 1,000,000		1,000,000		1,000,000
(인출) -100,000
잔액 기록: 900,000		900,000	1,000,000
	(시작) 잔액(이전) 읽음: 1,000,000
	잔액 Y 읽음: 1,000,000
	합계: 2,000,000(커밋)
잔액 Y 읽음: 1,000,000
이체 금액 합계: 100,000 + 1,000,000
잔액 Y 기록: 1,100,000(커밋)				1,100,000

MVCC를 사용하면 이전 버전의 데이터를 참조할 수 있으므로 모순적 판독이 발생하지 않고 올바른 값이 된다.

MVCC에서 이전 버전의 값은 롤백 세그먼트라는 영역에 저장된다. MVCC를 사용하기 위해서 SELECT의 구문에 버전을 저장할 필요는 없다. 보통처럼 SELECT를 작성하면 트랜잭션이 시작된 시점에 이미 커밋된 데이터만 자동으로 롤백 세그먼트에서 참조한다.

SERIALIZABLE 이외의 격리 수준을 채용하는 이유로 MVCC의 존재는 매우 크다. 특히 갱신을 포함하지 않고 참조만 하는 트랜잭션은 MVCC를 사용해 데이터의 부정합이 발생하지 않도록 하며, 성능을 크게 향상 시킬 수 있다.

크래시 복구

DB 서버 프로세스가 버그 등에 의해 비정상적으로 종료되거나, 서버 시스템이 고장나서 크래시되는 경우가 있다. 이와 같은 상황이 발생했을 때 즉시 서비스를 다시 시작하려면 데이터가 크래시되기 직전의 상태로 신속하게 복구해야 한다. 또한, 커밋한 데이터가 크래시에 의해서 손상되는 경우도 예상할 수 있다.

→ RDB에서는 크래시 복구가 필수 기능이라고 할 수 있다.

DB 서버의 컴포넌트

크래시 복구는 스테이블 로그가 매우 중요한 역할을 한다. 스테이블 로그는 말하자면 직렬화된 트랜잭션의 스케줄이다. 스테이블 로그 기록되는 로그 항목을 재생(REDO)해 DB 캐시를 최신의 상태로 복원한다.

그다음에 크래시한 순간에 아직 완료되지 않은 트랜잭션에 의한 갱신을 취소(UNDO)한다.

REDO, UNDO 양쪽 모두를 실행해 크래시의 복구를 완료하게 된다.

• 스테이블 DB: 비휘발성 스토리지상의 DB. 페이지화 된 구조로 되어 있으며 주로 디스크에 위치한다.
• DB 캐시: 휘발성 메모리에 있는 DB의 서브셋. 각종 갱신 작업은 모두 캐시에서 수행된 다음에 스테이블 DB에 플러시하여 반영한다.
• 스테이블 로그: DB 캐시에서 수행된 작업의 내역을 기록한 것. 비휘발성 스토리지에 기록된다.
• 로그 버퍼: 스테이블 로그에 기록하기 전에 이용되는 버퍼.

3. 트랜잭션과 데이터 모델의 융합

관계형 모델과 ACID의 C

ACID의 설명에서 트랜잭션을 실행하는 DB는 어떤 일관성이 있는 상태에서 다른 일관성이 있는 상태로 전환한다. 그 DB의 일관성을 보장하는 것은 응용프로그램에 달려있다.

DB의 일관성을 생각하는데 있어 가장 중요한 것은 데이터가 어떻게 표현되고 있는지, 그리고 그 데이터에 관해 어떤 연산을 수행하는지에 대한 이해, 즉 데이터 모델에 관한 이해가 필수다.

일관성이 있는지 판단하기 위한 로직은 관계형 모델로 표현되기 때문이다.

관계형 모델과 이상 현상

관계형 모델은 데이터를 조작하는 단위가 릴레이션이다. SQL로 대체하면 테이블이 데이터를 조작하는 단위가 된다. 릴레이션을 입력하여 다른 릴레이션을 출력하는 것이 관계형 모델의 기본적인 개념이다.

트랜잭션의 부정합으로 발생하는 각종 이상 현상은 데이터에 포함된 각 행의 값이 갑자기 바뀌거나, 행 자체가 늘어나거나 줄어드는 것이다. 이와 같은 이상 현상이 있다면 원래 릴레이션 연산의 정확성이 보장할 수 없게 된다.

집합을 사용한 연산으로 바른 결과를 얻는 것은 연산의 기반이 되는 집합이 올바르지 않으면 안 된다.

→ 관계형 모델을 제대로 구축하고 집합을 기반으로 한 연산을 쿼리로 표현하려면 이상 현상 대책을 찾아야 한다.

트랜잭션에 이상이 있으면 데이터 모델이 성립되지 않는다는 점에 주의해야 한다.

정규화와 직교성

관계형 모델에서 DB의 부정합을 방지하는 수단이라면 정규화와 직교성이다. 아무리 트랜잭션을 사용해 문제가 없는 스케줄로 갱신을 수행하더라도 DB에 중복이 있고, 모순이 발생한다면 원점으로 돌아가게 된다.

먼저 릴레이션의 정규화와 직교성을 구현하자. 특히 정규화는 중장기로 체계화해 실시할 수 있다. DB 설계로 이상 상태가 발생하지 않게 보장하고, ACID의 C를 보장하기 위해서 고려해야 할 것들을 줄일 수 있다.

제약

데이터 모델만으로 충분하지 않은 이유

관계형 모델은 어디까지나 데이터 모델이며 단순한 도구다. 관계형 모델을 구현한다고 해서 올바른 로직을 항상 표현할 수 있는 것은 아니다.

아무리 선언적으로 작성했다고 해도 작성한 내용과 처리가 의도한 것 사이에 괴리가 발생하는 경우가 없지는 않을 것이다. 코드와 처리의 의도에 괴락 있다면 이 트랜잭션의 결과는 바르지 않다고 할 수 있다.

RDB를 잘 구현하려면 처리의 작성에 문제가 있을지도 모른다는 것을 전제로 데이터의 정합성을 지키기 위해 노력해야 한다.

제약을 활용해 데이터를 보호

그래서 도움이 되는 것이 제약(Constraint)다. 제약을 사용하면 올바른 데이터가 어떤식으로 존재해야 하는지 표현할 수 있다.

관계형 모델을 제대로 이해하고 DB 설계를 제대로 수행해 이상 현상이 생길 가능성을 최대한 배제한 다음에 제약을 사용해 이상 현상을 막는 것이다.

NOT NULL

NULL이 포함되지 않게 표현하려면 NOT NULL 제약을 사용한다. 정규화를 할 때는 NOT NULL을 사용하자.

고유성 제약

테이블에서 어떤 컬럼의 조합에 중복이 없음을 보장하려면 고유성 제약을 사용한다. 키는 관계형 모델에 있어 반드시 필요한 개념이다. 후보키가 될 수 있는 컬럼의 조합 모두에 기본키 또는 유니크 인덱스를 작성하자.

CREATE TYPE

SQL에서 좁은 범위의 집합을 도메인으로 정의하거나 데이터 유형을 조합한 새로운 데이터 유형을 정의하고 싶다면 CREATE TYPE을 사용하면 편리하다. CREATE TYPE은 제품마다 사용법이 다르니 주의해야 한다.

CHECK 제약

컬럼이 취하는 데이터의 범위를 더욱 세밀하게, 그리고 현시점의 테이블의 상태에 맞게 제약을 하려면 CHECK 제약을 사요하면 편리하다. 그러나 SQL 표준에서 CHECK 제약은 다양한 쿼리를 표현할 수 있다고 되어 있지만 RDB 제품마다 CHECK 제약을 지원하는 상황이 다르므로 주의해야 한다.

CHECK 제약은 매우 강력하다. 단일 컬럼이 취하는 값뿐만 아니라 여러 개의 컬럼에 포함된 데이터의 정합성을 확인하는 것이 가능하다.

(MySQL은 CREATE TYPE, CHECK 제약은 지원하지 않는다.)

외부키 제약

SQL에 있는 테이블 사이에 데이터의 정합성을 확인하는 유일한 수단이 외부키다. 외부키 제약을 사용하면 자식 테이블에 있는 키와 같은 값의 키가 부모 테이블에도 있다는 제약을 표현 할 수 있다.

정규화를 수행해 무손실 분해된 두 개의 테이블 사이에 데이터의 부정합이 발생하지 않게 외부키 제약을 걸어야 할 필요가 있다.

외부키를 사용하지 않는 것은 검사를 위한 로직을 응용프로글매에서 구현해야한다. 그리고 응용프로그램에서 구현하는 거슨 외부키보다 성능이 떨어질 것이다. 외부키와 같은지 확인하려면 원래 동일한 데이터에 엑세스 해야만 하므로 DB 서버 내부에서 끝나는 처리와는 달리 SQL의 해석이나 전송 등을 위해서 오버헤드가 발생하기 떄문이다.

외부키를 사용하지 않고 또한 외부키와 같이 데이터의 정합성을 검색하는 로직도 없다면 데이터의 정합성이 보장돼 있는지 아닌지 모르는 위험을 안게 된다.

데이터의 정합성은 약간의 성능 저하나 운영의 수고에 비하면 훨씬 중요하다.

트리거

외부키는 매우 편리하지만 제약으로서의 표현은 충분하기엔 부족하다. 특히 여러 개의 테이블 사이에 데이터의 정합성을 담보하고자 할 때의 표현 방법으로는 SQL에서는 외부키 이외에는 존재하지 않다.

외부키는 테이블 사이의 제약을 표현하는 수단 중 하나에 지나지 않는다.

외부키로 표현할 수 없는 제약으로는 다음과 같다.

• 자식 테이블에 존재하는 키와 같은 값의 키가 부모 테이블에 존재하지 않는다.(NOT)
• 자식 테이블에 존재하는 키와 같은 값의 키가 여러 개의 부모 테이블 중에 하나만 존재한다.(OR)
• 자식 테이블에 존재하는 키와 같은 값의 키가 여러 개의 부모 테이블 중에 N개 이상, 또는 N개 미만이 존재한다. (XOR)

이러한 제약이 필요한 경우는 상태의 차이에 따라 저장하는 테이블을 나눌 때다. 합집합(UNION) 되어 있는 테이블을 따로따로 나눠야 하는 선택지가 필요한 경우가 적지 않다. 이 경우 외부키 제약 조건만으로 경쟁할 수 없다.

그래서 필요한 것이 트리거다. SQL에서 테이블 사이의 복잡한 제약을 표현하려면 트리거가 가장 적합하다. 트리거는 다양한 제약을 표현할 수 있으며 CHECK 제약과는 달리 다양한 표현을 사용할 수 있다.(집계, 스토어드 프로시저를 호출 등등)

트리거 자체는 절차형의 표현이지만 집합론에서 표현할 수 없는 다양한 로직을 작성할 수 있다.

트리거는 한 행마다 데이터 조작이 실행되는 행 트리거와 SQL 문마다 실행되는 문장 트리거가 있다. 두 개의 트리거가 있는 것이 이상적이지만, 데이터의 정합성을 확인하는 데 있어서 주로 필요한 쪽은 행 트리거 쪽이다. 문장 트리거는 행 트리거처럼 NEW 또는 OLD 키워드로 컬럼을 기존 값과 새로운 값으로 갱신할 수 없어서 제약을 표현하기에는 그다지 적합하지 않다.

행 트리거는 강력하지만 단점이 있다.

한마디로 한 행씩 실행되는 것이다. 따라서 여러 행에 묶어서 값을 조사하는 것은 본질적으로 적합하지 않다. 이 경우 트리거가 아닌 응용프로그램에서 그 트랜잭션 내에 데이터 정합성을 보장하기 위한 쿼리를 실행하는 것이 좋다. 이 쿼리를 실행한 결과 이상 상태가 발견되면 DB는 트랜잭션 실행에 따라 정합성이 있는 상태로 전환되기가 불가능하므로 명시적으로 트랜잭션을 로백해야 한다.

요약

DB에서 데이터의 정합성은 매우 중요하다. DB의 정합성을 유지하는 것은 관계형 모델, 트랜잭션에 관한 이해도 필수적이다. 격리 수준, 잠금, MVCC, 제약 등을 잘 활용해 트랜잭션에 의한 데이터 정합성을 유지하면서 최상의 성능을 낼 수 있도록 정리 하자.