PlusMagi's Blog By Pitt Phunsanit Backend,Database 5. Transaction & Atomicity Differences (Single-document vs Multi-document ACID Transactions)

5. Transaction & Atomicity Differences (Single-document vs Multi-document ACID Transactions)

ในโลกของการจัดการฐานข้อมูลระดับองค์กร ความน่าเชื่อถือของข้อมูล (Data Integrity) คือรากฐานที่สำคัญที่สุด การดำเนินการทางธุรกิจส่วนใหญ่ไม่ได้เป็นเพียงการบันทึกข้อมูลครั้งเดียว แต่เป็นการรวมกันของหลายขั้นตอนที่ต้องเกิดขึ้นพร้อมกัน เช่น การโอนเงินที่ต้องมีการหักเงินจากบัญชีต้นทางและเพิ่มยอดในบัญชีปลายทาง หากขั้นตอนใดขั้นตอนหนึ่งล้มเหลว ข้อมูลทั้งหมดจะต้องถูกย้อนกลับสู่สถานะเดิมอย่างสมบูรณ์

แนวคิดหลักที่รับประกันความถูกต้องนี้คือ **ACID Properties** (Atomicity, Consistency, Isolation, Durability) โดยเฉพาะอย่างยิ่งหลักการ **Atomicity** ที่รับประกันว่ากลุ่มของการดำเนินการ (Transaction) จะต้องสำเร็จทั้งหมด หรือล้มเหลวทั้งหมดอย่างสมบูรณ์

🔬 เจาะลึก: Single-document vs Multi-document Transactions ใน PostgreSQL

เมื่อเราพูดถึงขอบเขตของธุรกรรม เราสามารถแบ่งความซับซ้อนนี้ออกเป็นสองระดับหลักๆ ซึ่ง PostgreSQL ได้รับการออกแบบมาเพื่อรองรับทั้งสองรูปแบบอย่างมีประสิทธิภาพ:

1. Single-document/Single-statement Transaction (ระดับเอกสารเดียว)

ในกรณีนี้ การดำเนินการทั้งหมดเกิดขึ้นภายในขอบเขตของคำสั่ง SQL เดียว หรือคำสั่งที่เกี่ยวข้องกับแถวข้อมูล (Row) หรือตาราง (Table) เพียงตารางเดียว ความเป็นอะตอมมิตี้จะถูกรับประกันในระดับธรรมชาติของฐานข้อมูล PostgreSQL โดยอัตโนมัติ เมื่อคุณรันคำสั่ง `UPDATE` หรือ `INSERT` บนแถวเดียว การดำเนินการนั้นจะเสร็จสมบูรณ์ทั้งหมด หรือไม่ก็ล้มเหลวทั้งหมดในระดับแถวนั้นๆ ซึ่งให้ประสิทธิภาพสูงและง่ายต่อการจัดการ

2. Multi-document/Multi-statement ACID Transactions (ระดับหลายเอกสาร)

นี่คือสถานการณ์ที่ซับซ้อนกว่าและเป็นหัวใจของการทำธุรกรรมทางธุรกิจส่วนใหญ่ (เช่น การโอนเงิน) ซึ่งต้องมีการเปลี่ยนแปลงข้อมูลในหลายตาราง หรือหลายแหล่งข้อมูลพร้อมกัน PostgreSQL ใช้กลไก **Distributed Transaction Management** ผ่านคำสั่ง `BEGIN` และ `COMMIT` เพื่อให้มั่นใจว่าทุกขั้นตอนจะถูกประสานงานอย่างเป็นระเบียบ

หากเราต้องการให้การหักเงินจากบัญชี A และการเพิ่มเงินเข้าบัญชี B เกิดขึ้นพร้อมกัน เราจะต้องห่อหุ้มคำสั่งทั้งหมดไว้ในบล็อกธุรกรรมเดียว หากคำสั่งใดคำสั่งหนึ่งล้มเหลว (เช่น บัญชีปลายทางไม่มีอยู่จริง) PostgreSQL จะทำการ **ROLLBACK** ข้อมูลทั้งหมดที่เกิดขึ้นก่อนหน้าให้กลับสู่สถานะเดิมโดยอัตโนมัติ

⚙️ ตัวอย่างการใช้งาน PostgreSQL Transaction

ตัวอย่างนี้แสดงการโอนเงินจากบัญชีหนึ่งไปยังอีกบัญชีหนึ่ง ซึ่งต้องอาศัยการทำธุรกรรมหลายขั้นตอน (Multi-statement Transaction):

SQL

-- 1. เริ่มต้นธุรกรรม (BEGIN) เพื่อให้แน่ใจว่าทุกคำสั่งต้องสำเร็จทั้งหมด<br>BEGIN;<br><br>-- 2. หักเงินจากบัญชีต้นทาง (Account 1)<br>UPDATE accounts SET balance = balance - 100 WHERE account_id = 'A1';<br><br>-- 3. เพิ่มเงินเข้าบัญชีปลายทาง (Account 2)<br>UPDATE accounts SET balance = balance + 100 WHERE account_id = 'A2';<br><br>-- 4. หากทุกอย่างถูกต้อง ให้ยืนยันการเปลี่ยนแปลง (COMMIT)<br>COMMIT;<br><br>-- หากเกิดข้อผิดพลาดใดๆ ในขั้นตอน 2 หรือ 3 เราจะใช้ ROLLBACK<br>-- ROLLBACK;

✅ สรุปและข้อควรจำ

การทำความเข้าใจความแตกต่างนี้ช่วยให้เราออกแบบระบบได้อย่างถูกต้อง: หากการเปลี่ยนแปลงข้อมูลอยู่ภายในขอบเขตเดียว (เช่น การอัปเดตข้อมูลโปรไฟล์ผู้ใช้) การจัดการจะง่ายและมีประสิทธิภาพสูง แต่หากการเปลี่ยนแปลงเกี่ยวข้องกับหลายส่วนงาน (เช่น การสั่งซื้อสินค้าที่ต้องอัปเดตสต็อกและบันทึกรายการสั่งซื้อ) เราจำเป็นต้องใช้กลไก **Multi-statement Transaction** ของ PostgreSQL เพื่อรับประกันความสมบูรณ์ของข้อมูลตามหลัก ACID เสมอ

Exit mobile version