Net's Digital Garden 🌱

ACID

อ่านราว 2 นาที

ACID

คุณสมบัติพื้นฐาน 4 ข้อที่ relational database ต้องมีเพื่อให้ transaction ทำงานถูกต้อง: Atomicity, Consistency, Isolation, Durability

Transaction คืออะไร?

Transaction = กลุ่มของ queries ที่ทำงานเป็น หน่วยเดียว (one unit of work)

BEGIN TX1;
SELECT BALANCE FROM ACCOUNT WHERE ID = 1;  -- เช็คยอด
UPDATE ACCOUNT SET BALANCE = BALANCE - 100 WHERE ID = 1;  -- หักเงิน A
UPDATE ACCOUNT SET BALANCE = BALANCE + 100 WHERE ID = 2;  -- เพิ่มเงิน B
COMMIT TX1;

Lifecycle: BEGIN → ทำงาน → COMMIT (ยืนยัน) หรือ ROLLBACK (ยกเลิก) — ถ้า crash ก่อน commit → rollback อัตโนมัติ

Transaction ไม่จำเป็นต้องมี write — read-only transaction ใช้เพื่อให้ snapshot คงที่ตลอดการอ่าน (เช่น ทำรายงาน)

1. Atomicity (อะตอม-แบ่งไม่ได้)

ถ้า query ใดใน transaction fail → query ที่สำเร็จไปแล้วทั้งหมดต้อง rollback กลับไปสภาพก่อนเริ่ม

ตัวอย่าง: โอนเงิน 100 บาท — ถ้า DB crash หลัง UPDATE บัญชี A แต่ก่อน UPDATE บัญชี B → เงิน $100 หายไป! Atomicity ป้องกันเรื่องนี้

Pitfall: deadlock, network timeout, app crash, OOM ระหว่าง transaction เกิดบ่อยกว่าที่คิด → ห่อ critical operations ใน explicit transaction เสมอ

2. Consistency (ความสอดคล้อง)

มี 2 ความหมายที่คนสับสนบ่อย:

Consistency in Data (ของ ACID)

กำหนดโดย user/schema — referential integrity (FK), constraints, atomicity, isolation ที่ทำให้ data ไม่ขัดกัน

Consistency in Reads (ของ distributed systems)

เขียนที่ master แล้ว replica เห็นทันทีมั้ย? → นี่คือ eventual consistency ใน CAP Theorem

“Consistency ใน ACID” ≠ “Consistency ใน CAP theorem” — คนละเรื่องกัน!

3. Isolation (การแยกระดับการมองเห็น)

คำถามหลัก: transaction ที่กำลังทำงานอยู่ เห็น changes ของ transaction อื่น ที่ทำพร้อมกันมั้ย?

→ รายละเอียดอยู่ใน Transaction Isolation

4. Durability (ความคงทน)

หลัง commit สำเร็จ → ข้อมูลต้อง อยู่จริง ในที่เก็บถาวร แม้ DB จะ crash ทันที

เทคนิคที่ใช้:

  • WAL (Write-Ahead Log) — เขียน log ก่อนเขียน data จริง → crash → recovery จาก log
  • Asynchronous Snapshot — เก็บ data ใน memory ก่อน periodic flush (เร็วแต่เสี่ยง)
  • AOF (Append-Only File) — Redis ใช้ append ทุก write command ไปที่ file

OS Cache คือศัตรู

DB เขียนข้อมูล → OS อาจ cache ไว้ใน memory ก่อน flush ลง disk จริง → ไฟดับก่อน flush → หาย → DB จริงจังต้องสั่ง fsync() บังคับเขียนลง disk

Pitfall: SSD บางรุ่น “lie” เกี่ยวกับ fsync → enterprise SSD จึงมี battery-backed cache

Key Points

  • ACID = มาตรฐาน transaction ของ relational DB
  • Atomicity = all-or-nothing — fail ต้อง rollback ทั้งหมด
  • Consistency ใน ACID ≠ ใน CAP — อย่าสับสน
  • Isolation = transactions ไม่กวนกัน → ดู Transaction Isolation
  • Durability = commit แล้วไม่หาย → WAL + fsync
  • Read-only transaction ก็มี — ใช้เพื่อ snapshot consistency
  • Transaction Isolation — 4 read phenomena + 4 isolation levels
  • WAL — เทคนิคหลักสำหรับ durability
  • Concurrency Control — locks ที่ enforce isolation
  • CAP Theorem — Consistency คนละความหมายกับ ACID
  • PostgreSQL — ใช้ MVCC สำหรับ isolation
  • MySQL — InnoDB รองรับ ACID ครบ

มุมมองกราฟ

หน้าที่กล่าวถึง