[G1-Sync] Manual knowledge update
This commit is contained in:
Antigravity Agent
@@ -2,134 +2,144 @@
|
||||
id: wiki-2026-0508-acid-transactions
|
||||
title: ACID Transactions
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: [P-REINFORCE-WIKI-3FC2171D]
|
||||
aliases: [ACID, Database Transactions, Atomicity Consistency Isolation Durability]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.95
|
||||
tags: [acid-transactions, microservices-architecture, eventual-consistency, saga-pattern, base, architecture-principles]
|
||||
verification_status: applied
|
||||
tags: [database, transactions, consistency, postgres]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-02
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
language: sql
|
||||
framework: postgres-17
|
||||
---
|
||||
|
||||
# [[ACID Transactions]]
|
||||
# ACID Transactions
|
||||
|
||||
## 📌 Brief 소스에 관련 정보가 부족합니다.
|
||||
ACID 트랜잭션은 작업의 구현을 더 쉽게 만들어주는 전통적인 데이터베이스 트랜잭션 관리 방식입니다 [1]. 그러나 각 서비스가 자체 데이터베이스를 가져야 하는 마이크로서비스 아키텍처(분산 시스템)에서는 도입이 매우 어려워, 시스템 설계 시 최종 일관성(Eventual Consistency) 모델이나 BASE, Saga 패턴 등으로 대체되는 특성을 지닙니다 [2, 3]. 소스에 ACID의 구체적인 원리나 4가지 속성(Atomicity, Consistency, Isolation, Durability)에 대한 상세한 정의 등 관련 정보가 부족합니다.
|
||||
## 매 한 줄
|
||||
> **"Atomicity / Consistency / Isolation / Durability — 매 transaction 의 four guarantees."** Härder & Reuter (1983) 가 정식화한 properties. 매 RDBMS (Postgres, Oracle, MySQL InnoDB) 의 default 보장이며, 2026 distributed era 에도 매 NewSQL (CockroachDB, Spanner, TiDB, Neon) 가 매 ACID across nodes 를 표방. 매 단일 transaction 이 매 multi-statement 의 all-or-nothing + isolated + persisted 를 보장.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
소스에 관련 정보가 부족합니다. 다만, 제공된 소스에서 파악할 수 있는 ACID 트랜잭션의 아키텍처적 맥락은 다음과 같습니다:
|
||||
## 매 핵심
|
||||
|
||||
* **구현의 용이성 우위:** 일반적으로 최종 일관성(Eventual Consistency)을 가지는 Saga 패턴이나 BASE 모델을 구현하는 것보다, 전통적인 ACID 트랜잭션으로 작업을 구현하는 것이 훨씬 더 쉽고 직관적입니다 [1].
|
||||
* **분산 아키텍처에서의 적용 한계:** 마이크로서비스 아키텍처는 느슨한 결합(Loose coupling)을 달성하기 위해 '서비스당 데이터베이스(Database per service)' 패턴을 따라야 합니다 [2]. 이로 인해 여러 서비스의 데이터베이스에 걸친 비즈니스 트랜잭션을 중앙에서 관리해야 할 때, 기존의 ACID 트랜잭션을 그대로 적용하는 것은 불가능에 가깝거나 매우 어렵습니다 [2, 3].
|
||||
* **비-ACID(non-ACID) 모델로의 전환:** 여러 서비스에 걸친 복잡한 트랜잭션을 관리하기 위해 현대 분산 아키텍처에서는 ACID 트랜잭션을 포기하는 대신, 결국에는 상태가 동기화됨을 보장하는 비-ACID 방식인 최종 일관성 관리(예: Saga 패턴)를 대안으로 도입하게 됩니다 [2, 3].
|
||||
### 매 4 properties
|
||||
- **Atomicity**: 매 all statements commit or all rollback. 매 partial state 없음.
|
||||
- **Consistency**: 매 transaction 종료 시 매 모든 invariant (FK, check, unique) 가 valid.
|
||||
- **Isolation**: 매 concurrent transactions 가 매 serially executed 처럼 보임. 매 isolation level 로 trade-off.
|
||||
- **Durability**: 매 commit 후 매 crash / power loss 에도 매 data 가 살아남음 (WAL → fsync).
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
소스에 ACID 트랜잭션 자체의 원리적 한계에 대한 정보는 부족하나, 아키텍처 선택 관점에서의 반대 급부는 다음과 같습니다:
|
||||
### 매 Isolation levels (SQL standard + Postgres)
|
||||
- **Read Uncommitted**: 매 dirty read 허용 (Postgres 는 사실상 RC 로 mapping).
|
||||
- **Read Committed** (Postgres default): 매 dirty read X, 매 non-repeatable read O.
|
||||
- **Repeatable Read** (Postgres = snapshot isolation): 매 phantom read 거의 없음, 매 serialization anomaly O.
|
||||
- **Serializable** (Postgres = SSI): 매 strictest, 매 overhead 큼.
|
||||
|
||||
* **느슨한 결합(Loose Coupling)과의 충돌:** 애플리케이션의 유연성과 확장성을 위해 마이크로서비스 아키텍처를 도입할 경우, ACID 트랜잭션이 보장하는 강력한 데이터 일관성을 포기해야 하는 구조적 제약이 발생합니다 [2, 3].
|
||||
* **대안 선택 시의 복잡성 증가:** ACID 트랜잭션을 유지할 수 없는 분산 환경에서 최종 일관성 모델(Saga 패턴 등)을 도입하면, 트랜잭션 처리와 관련된 구현 및 테스트 난이도가 급격히 상승하는 반대 급부가 따릅니다 [3]. 비즈니스 로직에 실패 시 롤백을 처리하는 복잡한 보상 트랜잭션(Compensating transaction) 등을 추가로 구현해야 하는 부담이 생깁니다 [4].
|
||||
### 매 응용
|
||||
1. 매 financial / inventory 의 multi-row update.
|
||||
2. 매 idempotent worker — 매 transaction + unique key.
|
||||
3. 매 saga compensation 의 단위.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
### Related Concepts
|
||||
(소스에 관련 정보가 부족하여 분산 시스템에서의 트랜잭션 관리 맥락을 중심으로 연결합니다.)
|
||||
## 💻 패턴
|
||||
|
||||
#### [아키텍처/기반 기술]
|
||||
- [[Microservices Architecture]]
|
||||
- 연결 이유: 각 서비스가 개별 데이터베이스를 가지는 특성으로 인해 ACID 트랜잭션 적용이 어렵다는 맥락의 배경이 됩니다 [2].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 단일 모놀리식 아키텍처에서 쉽게 보장되던 ACID 속성이 시스템이 분산됨에 따라 왜 깨지게 되는지 근본적인 아키텍처 원리를 이해할 수 있습니다 [2, 3].
|
||||
|
||||
#### [구현/활용 도구]
|
||||
- [[Eventual Consistency]]
|
||||
- 연결 이유: 분산 시스템 환경에서 ACID 트랜잭션의 강력한 일관성을 대체하기 위해 채택되는 데이터 일관성 모델입니다 [1-3].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 아키텍처가 ACID를 포기할 때, 시스템이 데이터를 동기화하고 최종적으로 상태를 일치시키는 메커니즘을 파악할 수 있습니다 [2, 3].
|
||||
- [[Saga Pattern]]
|
||||
- 연결 이유: 여러 마이크로서비스에 걸친 트랜잭션을 관리하기 위해 ACID 트랜잭션 대신 구체적으로 도입되는 구현 패턴입니다 [3].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 비-ACID(non-ACID) 환경에서 분산 트랜잭션의 순서와 롤백 과정을 어떻게 설계해야 하는지 배울 수 있습니다 [2, 3].
|
||||
- [[BASE]]
|
||||
- 연결 이유: 마이크로서비스 설계 시 전통적인 ACID 트랜잭션 모델과 대조되는 개념으로 언급됩니다 [1].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: ACID 방식이 불가능한 분산 시스템 환경에서 적용하는 데이터베이스 트랜잭션 철학을 이해할 수 있습니다 [1].
|
||||
|
||||
### Deeper Research Questions
|
||||
(소스에 관련 정보가 부족하여 ACID 트랜잭션의 깊이 있는 탐구를 위해 추가 외부 조사가 필요한 질문들입니다.)
|
||||
|
||||
- 분산 아키텍처에서도 ACID 트랜잭션을 보장하기 위해 2PC(Two-Phase Commit) 등의 프로토콜을 사용할 경우 발생하는 성능 및 가용성 저하의 구체적인 원리는 무엇인가?
|
||||
- ACID의 핵심 속성(원자성, 일관성, 고립성, 지속성) 중 분산 환경에서 가장 달성하기 어렵고 성능 병목을 일으키는 속성은 무엇이며 그 이유는 무엇인가?
|
||||
- 금융 시스템과 같이 강한 데이터 일관성(ACID)이 절대적으로 필요한 도메인에서 마이크로서비스를 도입할 때, 일관성과 가용성 사이의 트레이드오프를 해결하는 현대적인 하이브리드 아키텍처 전략은 무엇인가?
|
||||
- 이벤트 기반 아키텍처(EDA)와 이벤트 소싱(Event Sourcing) 환경에서 전통적인 ACID 트랜잭션과 같은 데이터 무결성을 검증하는 방법론은 어떻게 구성되는가?
|
||||
- 마이크로서비스의 Saga 패턴 내에서 일시적인 데이터 불일치(Eventual Consistency)가 발생하는 시간(Window) 동안 사용자에게 발생할 수 있는 이상 현상(Anomalies)을 UI/UX 측면에서 어떻게 방어해야 하는가?
|
||||
|
||||
### Practical Application Contexts
|
||||
|
||||
- **Implementation:** 모놀리식 시스템의 경우 단일 데이터베이스 구조이므로 ACID 트랜잭션을 활용한 쉽고 안전한 데이터 작업 구현이 가능하지만, 향후 마이크로서비스로 전환할 때는 이 구현 방식을 Saga 등으로 전면 수정해야 합니다 [1-3].
|
||||
- **System Design:** 소프트웨어 설계 시, 시스템이 반드시 강한 데이터 일관성(ACID)을 요구하는지, 아니면 최종 일관성만으로도 충분한지를 비즈니스 도메인에 맞춰 분석하고 그에 따라 데이터베이스 분리 여부를 결정해야 합니다 [2, 3].
|
||||
- **Operation / Maintenance:** 단일 시스템의 ACID 환경과 달리 최종 일관성 모델 도입 시 트랜잭션 실패 추적 및 디버깅이 매우 복잡해집니다. 따라서 분산 추적(Distributed Tracing) 및 로그 집계와 같은 강력한 관측성(Observability) 확보 계획이 운영 맥락에서 필수적입니다 [3].
|
||||
- **Learning Path:** 단일 데이터베이스에서의 전통적 ACID 속성(외부 지식 필요) 이해 ➔ 마이크로서비스 분산 환경의 제약사항(Database per Service) 인식 ➔ CAP 정리 및 BASE 모델 학습 ➔ 비-ACID 환경 극복을 위한 분산 트랜잭션 및 Saga 패턴 설계 단계로 아키텍처 학습을 확장할 수 있습니다.
|
||||
- **My Project Relevance:** 현재 대규모 시스템을 작은 서비스 단위로 분해하려는 프로젝트(예: 모놀리스에서 MSA로의 마이그레이션)를 계획 중이라면, 기존에 의존하던 ACID 트랜잭션 보장이 불가능해진다는 점을 사전에 식별하고, 데이터 무결성 보장을 위한 대안 설계를 프로젝트 초기부터 준비하는 데 직결됩니다.
|
||||
|
||||
### Adjacent Topics
|
||||
|
||||
- [[Database per Service Pattern]]
|
||||
- 확장 방향: 마이크로서비스 구조에서 각 서비스의 독립성을 보장하기 위해 데이터가 어떻게 격리되는지 살펴보고, 이 패턴이 분산 트랜잭션 관리와 ACID 트랜잭션 포기에 미치는 직접적인 영향을 연구할 수 있습니다.
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-02*
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
|
||||
> *(TODO: 한 문장으로 핵심 통찰을 작성. "X는 Y 조건에서 Z 효과를 낸다" 구조 권장.)*
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
### 1) Postgres BEGIN/COMMIT
|
||||
```sql
|
||||
BEGIN;
|
||||
UPDATE accounts SET balance = balance - 100 WHERE id = 1;
|
||||
UPDATE accounts SET balance = balance + 100 WHERE id = 2;
|
||||
COMMIT; -- 매 atomic + durable
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
### 2) SAVEPOINT 로 partial rollback
|
||||
```sql
|
||||
BEGIN;
|
||||
INSERT INTO orders(id, total) VALUES (1, 50);
|
||||
SAVEPOINT before_items;
|
||||
INSERT INTO items(order_id, sku) VALUES (1, 'BAD-SKU'); -- FK 위반
|
||||
ROLLBACK TO SAVEPOINT before_items;
|
||||
INSERT INTO items(order_id, sku) VALUES (1, 'OK');
|
||||
COMMIT;
|
||||
```
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
### 3) Isolation level 명시 (Python + asyncpg)
|
||||
```python
|
||||
async with conn.transaction(isolation="serializable"):
|
||||
row = await conn.fetchrow("SELECT balance FROM accounts WHERE id=$1", 1)
|
||||
await conn.execute("UPDATE accounts SET balance=$1 WHERE id=$2", row["balance"]-100, 1)
|
||||
# 매 SSI — 매 serialization_failure 시 retry 필요
|
||||
```
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
### 4) Optimistic concurrency (version column)
|
||||
```sql
|
||||
UPDATE doc SET body = $1, version = version + 1
|
||||
WHERE id = $2 AND version = $3;
|
||||
-- 매 affected_rows = 0 → conflict, 매 retry / 사용자 alert
|
||||
```
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
### 5) SELECT FOR UPDATE (pessimistic lock)
|
||||
```sql
|
||||
BEGIN;
|
||||
SELECT * FROM accounts WHERE id = 1 FOR UPDATE; -- 매 row lock
|
||||
UPDATE accounts SET balance = balance - 100 WHERE id = 1;
|
||||
COMMIT;
|
||||
```
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
### 6) Outbox pattern (transaction + async publish)
|
||||
```sql
|
||||
BEGIN;
|
||||
INSERT INTO orders(id, ...) VALUES (...);
|
||||
INSERT INTO outbox(event_type, payload) VALUES ('OrderCreated', $1);
|
||||
COMMIT;
|
||||
-- 매 separate worker 가 outbox 를 읽고 매 broker 로 publish
|
||||
```
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
### 7) Retry on serialization failure (Python)
|
||||
```python
|
||||
from psycopg.errors import SerializationFailure
|
||||
for _ in range(5):
|
||||
try:
|
||||
with conn.transaction(): do_work()
|
||||
break
|
||||
except SerializationFailure:
|
||||
time.sleep(random.uniform(0, 0.05))
|
||||
```
|
||||
|
||||
## 매 결정 기준
|
||||
| 상황 | Isolation level |
|
||||
|---|---|
|
||||
| 매 read-heavy dashboard | Read Committed |
|
||||
| 매 report 의 consistent snapshot | Repeatable Read |
|
||||
| 매 money / counter / unique reservation | Serializable |
|
||||
| 매 high-conflict hot row | Pessimistic FOR UPDATE |
|
||||
| 매 low-conflict OLTP | Optimistic version |
|
||||
|
||||
**기본값**: Postgres Read Committed + 매 critical path 만 매 Serializable / FOR UPDATE.
|
||||
|
||||
## 🔗 Graph
|
||||
- 부모: [[Database]] · [[Transactions]]
|
||||
- 변형: [[BASE]] · [[Snapshot Isolation]] · [[Serializable Snapshot Isolation (SSI)]]
|
||||
- 응용: [[Outbox Pattern]] · [[Saga Pattern]] · [[Idempotency]]
|
||||
- Adjacent: [[CAP Theorem]] · [[WAL (Write-Ahead Log)]]
|
||||
|
||||
## 🤖 LLM 활용
|
||||
**언제**: 매 codegen 의 SQL transaction boundary 검증, 매 isolation level mismatch 점검.
|
||||
**언제 X**: 매 eventually-consistent NoSQL (DynamoDB single-region) — 매 BASE 모델로 reasoning.
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **App-side "transaction"**: 매 read-modify-write 가 매 BEGIN/COMMIT 밖. 매 race condition.
|
||||
- **Long transaction**: 매 minutes 단위 hold → 매 lock contention + bloat.
|
||||
- **Wrong isolation**: 매 default RC 에서 매 lost update 발생, 매 detect 못 함.
|
||||
- **Ignoring serialization failure**: 매 SSI 에서 매 retry 안 함 → 매 user-facing error.
|
||||
- **Transaction across services**: 매 distributed XA 시도 → 매 saga 로 대체.
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified (Postgres 17 docs, Härder & Reuter 1983, Bailis "Highly Available Transactions" 2014).
|
||||
- 신뢰도 A.
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — ACID + Postgres isolation levels + 7 patterns |
|
||||
|
||||
Reference in New Issue
Block a user