SQLite에서 시스템 트랜잭션에서 사용자 트랜잭션으로

I’m happy to translate the article for you, but I need the text you’d like translated. Could you please paste the content (or the portion you want translated) here? I’ll keep the source link exactly as you provided and preserve all formatting, markdown, and code blocks.

사용자 트랜잭션: 자동 커밋 탈피

기본적으로 SQLite는 autocommit mode로 실행됩니다. SELECT가 아닌 모든 문장은 자체 트랜잭션으로 감싸집니다:

쓰기‑중심 워크로드의 경우, 이러한 반복적인 설정 및 해제가 실제 오버헤드를 발생시킵니다:

• 각 문장마다 저널 파일이 다시 열림
• 잠금이 반복적으로 획득되고 해제됨
• 동시성에서 경쟁이 증가함

명시적 사용자 트랜잭션

이를 방지하기 위해, 애플리케이션은 사용자 수준 트랜잭션을 명시적으로 정의할 수 있습니다:

BEGIN TRANSACTION;
    INSERT INTO table1 VALUES (100);
    INSERT INTO table2 VALUES (20, 100);
    UPDATE table1 SET x = x + 1 WHERE y > 10;
    INSERT INTO table3 VALUES (1, 2, 3);
COMMIT;   -- or ROLLBACK

BEGIN이 실행되면, SQLite는 자동 커밋 모드를 벗어납니다:

• 단일 쓰기 트랜잭션이 여러 문에 걸칩니다.
• 저널링 및 잠금 비용이 모든 쓰기 작업에 걸쳐 분산됩니다.

이후의 모든 SELECT가 아닌 문은 동일한 사용자 트랜잭션의 일부가 됩니다. SELECT 문은 여전히 독립적인 읽기 트랜잭션으로 실행됩니다.

애플리케이션이 실행할 때:

• COMMIT → 쓰기 트랜잭션이 커밋됩니다.
• ROLLBACK → 쓰기 트랜잭션이 중단됩니다.

그 후, SQLite는 자동으로 자동 커밋 모드로 돌아갑니다.

중요한 제약 조건

• SQLite는 단일 평면 사용자 트랜잭션만 지원합니다.
• 중첩된 BEGIN 문은 허용되지 않습니다.
• 한 번에 데이터베이스 연결당 하나의 사용자 트랜잭션만 존재할 수 있습니다.

이 설계는 SQLite의 트랜잭션 모델을 단순하고 예측 가능하게 유지합니다.

저장점: 트랜잭션 내부에서 제어된 롤백

SQLite는 중첩 트랜잭션을 지원하지 않지만, 저장점을 지원하며 이는 트랜잭션 내부에서 제어된 롤백 메커니즘을 제공합니다.

저장점은 실행 중 논리적인 “양호한 상태”를 표시합니다:

SAVEPOINT sp1;
-- do work
ROLLBACK TO sp1;

핵심 속성

• 여러 저장점을 동시에 존재시킬 수 있습니다.
• 활성화된 어떤 저장점으로든 롤백할 수 있습니다.
• 저장점으로 롤백해도 전체 트랜잭션이 중단되지 않습니다.

트랜잭션 외부의 저장점

사용자 트랜잭션 외부에 저장점을 생성하면:

1. SQLite가 암묵적으로 사용자 트랜잭션을 엽니다.
2. 저장점을 실행합니다.
3. 저장점이 해제될 때 자동으로 커밋됩니다.

따라서 저장점은 필요할 때 트랜잭션‑라이트 추상화 역할을 합니다.

Statement Subtransactions: Atomicity at Statement Level

Even inside a user transaction, each non‑SELECT statement runs in its own subtransaction. At any moment only one statement subtransaction exists. SQLite implements this using an implicit (anonymous) savepoint.

The flow looks like this:

Why This Matters

• If a statement fails, SQLite rolls back only that statement.
• The user transaction continues.
• Previous successful statements remain intact.

Unless explicitly instructed, SQLite does not abort the entire transaction because of a single statement failure.

예시: 문장 서브트랜잭션 동작

BEGIN TRANSACTION;

INSERT INTO table1 VALUES (100);
INSERT INTO table2 VALUES (20, 100);
UPDATE table1 SET x = x + 1 WHERE y > 10;
INSERT INTO table3 VALUES (1, 2, 3);

COMMIT;

실행 모델

• 각 문장은 자신만의 서브트랜잭션에서 실행됩니다.
• 만약 UPDATE가 제약 조건 위반에 부딪히면:
  • 그 UPDATE에 의해 이루어진 모든 변경이 롤백됩니다.
  • 주변의 INSERT 문들은 그대로 유지됩니다.
  • 마지막 COMMIT은 성공한 모든 내용을 영구히 저장합니다.

이 때문에 SQLite는 애플리케이션이 트랜잭션을 다시 시작하도록 강요하지 않고도 부분적인 실패에서 깔끔하게 복구할 수 있습니다.

충돌 해결: 제약 조건 위반 시 발생하는 일

제약 조건 위반이 INSERT 또는 UPDATE 중에 발생하면, SQLite는 충돌‑해결 알고리즘을 적용합니다. 각 정책은 롤백이 얼마나 전파되는지를 정의합니다.

이러한 모드는 실패가 문장 서브‑트랜잭션에 국한되어 유지되는지, 아니면 상위 사용자 트랜잭션으로 확대되는지를 결정합니다.

모두 합쳐서

SQLite의 트랜잭션 모델은 계층화되어 있습니다:

• 시스템 트랜잭션 – 개별 문장의 원자적 실행을 보장합니다.
• 사용자 트랜잭션 – 여러 쓰기 작업에 걸쳐 저널링 및 락 비용을 분산합니다.
• 세이브포인트 – 전체 트랜잭션을 중단하지 않고 제어된 롤백을 허용합니다.
• 문장 서브‑트랜잭션 – 긴 트랜잭션 내부에서도 문장별 원자성을 보장합니다.

SQLite는 평면 트랜잭션만 지원하지만, 세이브포인트와 서브‑트랜잭션을 활용해 세밀한 정확성을 달성하고 애플리케이션에 불필요한 복잡성을 노출하지 않습니다.

SQLite와 관련된 나의 실험 및 직접 실행 예제는 여기에서 확인할 수 있습니다:
lovestaco/sqlite

참고 문헌

1. SQLite Database System: Design and Implementation – Sibsankar Haldar.

2. 
   👉 확인해 보세요: FreeDevTools

피드백이나 기여를 언제든 환영합니다!

온라인이며 오픈‑소스이고 누구든 사용할 수 있습니다.

⭐ GitHub에서 별표 달기: HexmosTech/FreeDevTools