Asha에서 Ben으로 300루피를 이동하려면 두 가지 업데이트가 필요합니다. 한 계정에서 빼고 다른 계정에 추가하는 것입니다. 그들 사이에 시스템이 실패하면 돈은 사라진다. SQL 트랜잭션은 두 단계를 단일 단위로 처리하여 이를 불가능하게 만들기 위해 존재합니다.

이 가이드에서는 작은 계정 테이블에서 커밋, 롤백 및 실패를 실행합니다. 우리는 SQLite에서 해당 예제를 실행했으며 표시된 잔액은 해당 실행에서 나온 것입니다. 기본 명령은 데이터베이스 전체에서 유사하지만 잠금 및 격리 동작은 많이 다르므로 데이터베이스 설명서를 확인할 수 있는 위치를 알려드립니다.

거래란 무엇입니까?

트랜잭션은 데이터베이스가 단일 논리 작업으로 처리하는 하나 이상의 SQL 문의 시퀀스입니다. 우리 테이블은 다음과 같습니다.

CREATE TABLE accounts (
  id INT PRIMARY KEY,
  owner TEXT,
  balance INT CHECK (balance >= 0)
);

INSERT INTO accounts VALUES (1, 'Asha', 1000), (2, 'Ben', 200);

CHECK 제약 조건은 잔액이 0 아래로 내려갈 수 없다는 규칙이며 나중에 사용하겠습니다. 트랜잭션을 시작하는 구문은 다양합니다. SQLite와 PostgreSQL은 BEGIN를 허용하고, MySQL에도 START TRANSACTION이 있으며, SQL Server는 BEGIN TRANSACTION를 사용합니다.

명시적 트랜잭션 외부에서 대부분의 데이터베이스는 각 문이 완료되자마자 저장되는 autocommit을 사용합니다. Oracle은 커밋할 때까지 세션이 트랜잭션에 유지되므로 주목할만한 예외입니다.

COMMIT: 영구적으로 설정

BEGIN;
UPDATE accounts SET balance = balance - 300 WHERE id = 1;
UPDATE accounts SET balance = balance + 300 WHERE id = 2;
COMMIT;

-- Asha | 700
-- Ben  | 500

COMMIT이 실행될 때까지 변경 사항은 잠정적입니다. 성공적으로 반환되면 데이터베이스는 해당 내용이 저장되었음을 보장합니다. 두 계정의 합계는 1200으로 유지되었으며, 이것이 연습의 전체 요점입니다.

ROLLBACK: 모두 취소

ROLLBACK은 트랜잭션이 시작된 이후 모든 것을 취소합니다.

BEGIN;
UPDATE accounts SET balance = balance - 100 WHERE id = 1;
SELECT owner, balance FROM accounts;
-- Asha | 600   (visible inside this transaction)
-- Ben  | 500

ROLLBACK;
SELECT owner, balance FROM accounts;
-- Asha | 700   (back to where it was)
-- Ben  | 500

커밋하기 전에 연결이 끊어지거나 서버가 충돌하는 경우 롤백도 자동으로 발생하므로 반쯤 완료된 트랜잭션은 유지되지 않습니다.

명령문이 실패할 때

여기에 좀 더 현실적인 사례가 있습니다. Asha는 계정에 보유되지 않은 5000을 보내려고 합니다. Ben에 대한 대변이 먼저 실행된 다음 차변이 CHECK 규칙을 위반합니다.

BEGIN;
UPDATE accounts SET balance = balance + 5000 WHERE id = 2;
UPDATE accounts SET balance = balance - 5000 WHERE id = 1;
-- error: CHECK constraint failed: balance >= 0

ROLLBACK;

-- Asha | 700
-- Ben  | 500

거래가 없었다면 Ben은 5000을 보관했을 것이고 장부는 틀렸을 것입니다. 한 가지 중요한 세부 사항에 유의하세요. 실패하는 문이 항상 거래 자체를 취소하는 것은 아닙니다. 예를 들어 SQLite 및 MySQL에서는 이전 문이 보류 상태로 남아 있을 수 있으므로 코드에서 롤백을 실행해야 합니다. 대신 PostgreSQL은 전체 트랜잭션을 중단된 것으로 표시하고 롤백할 때까지 추가 명령문을 거부합니다.

애플리케이션 코드에서는 항상 트랜잭션과 오류 처리를 쌍으로 연결하십시오. Python의 아이디어는 다음과 같습니다. Python 예외 처리에 대한 가이드에서는 구문을 설명합니다.

try:
    conn.execute("BEGIN")
    conn.execute(debit_sql, values)
    conn.execute(credit_sql, values)
    conn.execute("COMMIT")
except Exception:
    conn.execute("ROLLBACK")
    raise

세이브포인트

저장점은 트랜잭션 내부의 위치를 표시하므로 작업의 일부만 취소할 수 있습니다.

BEGIN;
UPDATE accounts SET balance = balance - 50 WHERE id = 1;
SAVEPOINT bonus;
UPDATE accounts SET balance = balance + 999 WHERE id = 2;
ROLLBACK TO bonus;
UPDATE accounts SET balance = balance + 50 WHERE id = 2;
COMMIT;

-- Asha | 650
-- Ben  | 550

999 보너스는 취소되었으며 나머지 거래는 계속 진행되었습니다. 이는 긴 프로세스의 선택적 단계에 유용합니다.

ACID 속성 설명

일관성은 흔히 오해됩니다. 데이터베이스는 제약 조건 및 외부 키와 같이 선언한 규칙만 적용합니다. 코드가 잘못된 금액을 이체하는 것을 막지는 못합니다. 내구성은 일반적으로 미리 쓰기 로그를 통해 달성됩니다. 여기서 변경 사항은 커밋이 확인되기 전에 디스크에 안전하게 기록됩니다.

동시 트랜잭션에서는 어떻게 되나요?

하나의 SQLite 파일에 대해 두 개의 연결을 열었습니다. 첫 번째는 아직 커밋하지 않고 트랜잭션을 시작하고 행을 1에서 2로 업데이트했습니다. 두 번째 연결에서 본 내용은 다음과 같습니다.

Connection B reads:   1                     -- no uncommitted data
Connection B writes:  database is locked    -- it has to wait
(A commits)
Connection B reads:   2                     -- now it sees the change

SQLite는 한 번에 하나의 기록기만 허용합니다. 이는 많은 트랜잭션이 동시에 서로 다른 행을 쓸 수 있는 서버 데이터베이스보다 간단합니다. 그러나 원칙은 동일합니다. 다른 세션은 일반 설정에서 커밋되지 않은 변경 사항을 볼 수 없으며 충돌하는 쓰기는 기다려야 합니다. 저희 테스트에서는 두 번째 연결을 기다리지 않고 바로 포기하도록 설정했기 때문에 오류가 단번에 나타났습니다.

이상 징후 읽기

거래가 중복되면 특정 문제가 발생할 수 있습니다. SQL 표준은 트랜잭션이 관찰할 수 있는 항목을 다음과 같이 정의합니다.

또 다른 문제는 업데이트 손실입니다. 두 세션은 잔액 100을 읽고, 각각 10을 더하고, 각각 110을 씁니다. 답이 120이어야 할 때 한 번의 업데이트는 사실상 사라졌습니다.

SQL 격리 수준

격리 수준을 사용하면 동시성을 위해 엄격함을 교환할 수 있습니다. SQL 표준이 각 수준에서 허용하는 내용은 다음과 같습니다.

SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;

정확한 구문과 동작은 데이터베이스에 따라 다릅니다. 기본값도 다릅니다. PostgreSQL과 SQL Server는 커밋된 읽기를 사용하는 반면 MySQL의 InnoDB는 반복 가능한 읽기를 사용합니다. 일부 데이터베이스는 표준에서 요구하는 것보다 더 강력한 보증을 제공하거나 한 수준을 다른 수준으로 취급합니다. 예를 들어 PostgreSQL에서 커밋되지 않은 읽기는 커밋된 읽기처럼 동작합니다. 특정 동작에 의존하기 전에 항상 데이터베이스 문서를 읽으십시오.

교착상태

교착 상태는 두 트랜잭션이 각각 다른 트랜잭션에 필요한 잠금을 보유할 때 발생합니다. 트랜잭션 A는 행 1을 잠그고 행 2를 원하는 반면, 트랜잭션 B는 행 2를 잠그고 행 1을 원합니다. 둘 다 계속할 수 없습니다.

PostgreSQL, MySQL 및 SQL Server와 같은 데이터베이스는 이를 감지하고 오류가 있는 트랜잭션 하나를 취소합니다. 이는 정상적인 동작이므로 애플리케이션은 이에 대비해야 합니다. 교착 상태를 줄이려면 항상 가장 낮은 계정 ID부터 먼저 행을 업데이트하고, 트랜잭션을 짧게 유지하고, 피해자로 선택되면 다시 시도하는 등 일관된 순서로 행을 업데이트하세요.

모범 사례

• 거래를 짧게 유지하세요. 긴 거래는 잠금을 유지하고 다른 사용자를 차단합니다.
• 트랜잭션 내에서 사용자나 느린 API를 기다리지 마십시오. 시작하기 전이나 후에 해당 작업을 수행하십시오.
• 항상 실패를 처리합니다. 모든 경로는 커밋 또는 롤백으로 끝나야 합니다.
• 제약조건을 추가합니다. 데이터베이스에 적용할 실제 규칙을 제공합니다. 좋은 테이블 디자인도 도움이 됩니다.
• 좋은 색인을 사용하십시오. 조회가 빠르면 잠금이 유지되는 시간이 단축됩니다.
• 재시도에 주의하세요. 교착 상태에서 재시도하되 작업이 두 번 적용되지 않도록 하세요.
• 의도적으로 동시성을 테스트합니다. 이러한 버그 중 다수는 로드 시에만 나타나므로 기본적인 통합 테스트만으로는 이를 드러내지 못할 수도 있습니다.

마무리

거래는 여러 위험한 단계를 하나의 안전한 작업으로 바꾸고 ACID는 이를 신뢰할 수 있게 만드는 보장을 설명합니다. 비즈니스 작업이 두 개 이상의 행이나 테이블에 닿을 때마다 중간에 중지하면 어떤 일이 일어날지 자문해 보세요. 답변이 걱정된다면 거래로 마무리하세요. 연습하려면 로컬 데이터베이스에서 두 개의 세션을 열고 직접 이상 현상을 생성해 보십시오.

자주 묻는 질문

계속 학습하세요