บทความจากสมาชิก: Basic Tracsaction Processing

จัดทำโดย Pichamol Yindeephop
Department of Computer Engineering, Faculty of Engineering
King Mongkut's Institute of Technology Ladkrabang

ในยุคสมัยนี้เวลาไปทางานในสถานที่ต่างๆ เจอผู้คนมากมาย ยิ่งทำงานด้านสายไอทีแล้ว ก็คงจะเคยได้ยิน คำว่า Transaction กันมาบ้าง ต่างคนต่างให้คานิยามที่น่าสับสนชวนปวดหัว ต่างที่ต่างถิ่นก็ให้นิยามอีกแบบหนึ่ง ต่างสายต่างสาขาก็ให้นิยามอีกแบบหนึ่ง เช่น ถ้าได้ยินคนกล่าวว่า Transaction คือ file ที่เก็บรายการการ เปลี่ยนแปลง มันคือนิยามตั้งแต่ปี 1960 หรืออาจจะมีคนกล่าวว่า Transaction คือแต่ละ operation บน file กล่าวคือ 1 insert คือ 1 transaction อีก 1 update ก็คืออีก 1 transaction มันคือนิยามตั้งแต่ปี 1970 ยุคสมัยก่อนทั้งนั้น แต่ในยุคปัจจุบันนี้ผู้คนส่วนใหญ่จะรู้จักคำว่า Transaction ในความหมายที่ว่า “A Transaction is a logical unit of work in which integrity constraints are allowed to be violated. (LUW) กล่าวคือ กลุ่มของคำสั่งในภาษาฐานข้อมูลในระดับ Logical ที่ยอมให้มีการละเมิด Integrity constraints เป็นการภายในได้ ซึ่ง Integrity constraints หมายถึง กฎที่บังคับความถูกต้องของฐานข้อมูล รวมถึง business rule ต่างๆ ด้วย โดยจะเก็บอยู่ใน Database และบังคับใช้โดย DBMS"

ขอยกตัวอย่างเพื่อความเข้าใจมากขึ้น

สมมติมีกฎที่ว่า R1 : นักศึกษาต้องมีสาขาวิชาที่เรียน ดังนั้นจึงเริ่มปฏิบัติคำสั่ง ดังนี้


เมื่อเกิดเหตุการณ์เช่นนี้แล้ว และเราก็ไม่สามารถที่จะไปเปลี่ยนแปลงกฎเกณฑ์ข้อนั้นได้เพราะมันคือกฎเกณฑ์ ที่มีความถูกต้องและต้องการให้ผลลัพธ์เป็นเช่นนั้นจึงเปลี่ยนเป็นรวมทั้งข้อ 1 และข้อ 2 เป็นก้อนเดียวกัน ดังนี้

การ Insert ในข้อ 1 จะถูก reject โดย R1 เพราะนักศึกษาคนนั้นยังไม่มสี าขาวิชาเรียน
page1image11344

คราวนี้ Transaction ของเราจะไม่ถูก reject โดย R1 แล้ว จะเห็นได้ว่ากฎ R1 ข้างต้นถูกละเมิดเป็นการ ชั่วคราว กล่าวคือทำทั้งก้อนนี้ก่อนแล้วค่อยตรวจ constraints ซึ่งสุดท้ายแล้ว Database จะต้องสอดคล้อง ตาม Integrity rules

จากนั้นจึงเกิดคำถามว่าเมื่อไหร่ถึงจะรวมเป็นก้อนเดียวกัน ตอบอย่างง่ายๆคือรวบรวมอะไรที่เกี่ยวข้องกันไว้ ด้วยกัน แล้วใส่ begin-end ซึ่งเรียกชื่อที่เป็นทางการขึ้นหน่อยเรียกว่าจุด Sync points บางคนก็เกิดข้อสงสัยว่า ควรใส่คำสั่ง SQL ข้างนอกหรือข้างในจุด Sync points ดี อย่างไหนจะเร็วกว่ากัน? ขอตอบเลยว่า ไม่เกี่ยวกับเรื่อง ความเร็ว มันเป็นเรื่องของการรักษาความถูกต้อง แค่พยายาม disable ภายในให้ไม่ละเมิด constraint ที่มี ถ้าแต่ ละคำสั่งไม่มีการละเมิด constraint อยู่แล้วก็ไม่จาเป็นต้องใส่จุด Sync points ก็ได้

ในผลิตภัณฑ์ชั้นนำต่างๆ อนุญาตให้กาหนด Constraint ต่างๆ ได้ โดยสามารถใช้คำสั่ง create constraint จากนั้นใส่กฎที่ต้องการ create แล้วตามท้ายด้วย Deferable หมายความว่า ให้เลื่อนกฎนี้ไปบังคับใช้ หลังจบ Transaction แล้ว เพราะฉะนั้นจากตัวอย่างข้างต้น กฎ R1 ควรจะใส่ Deferable ต่อท้ายเมื่อ create กฎ นี้ขึ้น แต่บางผลิตภัณฑ์ เช่น ในบาง constraint Oracle ก็ไม่อนุญาตให้ใส่ Deferable ตัวอย่างเช่น กฎถ้า primary key ซ้าก็ให้ reject เป็นต้น

จุด Sync points ในภาษา SQL
คือคำสั่งที่ใส่ไว้เมื่อเริ่มต้นและลงท้าย Transaction มีดังนี้

1. Commit [work]
คือจุดที่ยืนยันการเปลี่ยนแปลง ตั้งแต่ Sync points ล่าสุด จนถึงจุด commit กล่าวคือเป็นการที่ DBMS ยืนยันการเปลี่ยนแปลงระดับ Logical หลังจากนี้ถ้าเกิดอะไรในภายหลัง DBMS จะรับผิดชอบเอง โดย การเปลี่ยนแปลงนั้นยังไม่จาเป็นต้อง save ลง disk

2. Rollback [work]
เป็นการยกเลิกการเปลี่ยนแปลงตั้งแต่ Sync points ล่าสุดจนถึงจุด rollback

3. Set autocommit off
เป็นการบอกไว้ว่าเมื่อปฏิบัติคำสั่ง SQL แต่ละคำสั่งสำเร็จ ยังไม่ต้อง commit โดยจะ commit ก็ต่อเมื่อ ได้รับคาสั่ง commit เท่านั้น ซึ่งตรงกันข้ามกับ set autocommit on (เป็นค่า default) ที่เมื่อเสร็จแต่ ละคำสั่ง SQL ก็จะ commit ทันที

ตัวอยางเช่น

Set autocommit off (จุด begin tx)
update ACCT
set amount = amount - x where ACC# = ‘A’;
update ACCT
set amount = amount + x where ACC# = ‘B’;
commit work (จุด end tx)

ทั้งหมดนี้คือ 1 Transaction การโอนรวมการถอนและฝาก ถ้าเราย้าย commit work ไปใส่หลัง คำสั่ง update ช่วงแรกคือการถอน และการ update ช่วงหลังคือการฝากนั้นไม่มี commit หมายความ ว่าการถอนจะถูก confirm การเปลี่ยนแปลงแล้ว ถ้าเกิด fail การฝากจะ fail ไป แต่ถ้าเรารวมเป็น Transaction เดียวกันอย่างข้างต้น ถ้าเกิดการ fail ระหว่างทางก็จะ rollback เป็นค่าเก่าหมด

เมื่อเราเข้าใจความหมายของ Transaction คร่าวๆ แล้ว สิ่งที่ควรรู้ต่อไป คือ คุณสมบัติที่ดีของ Transaction หรือที่เขาเรียกกันว่า ACID properties

ACID Properties ประกอบด้วย

1. Atomicity
กิจกรรมที่ทำใน transaction ถ้าสำเร็จก็ต้องสำเร็จหมด ถ้า fail ก็ต้อง fail หมด ยกเว้น Long duration transaction คือ transaction ที่มีคนมาเกี่ยวข้องด้วย เช่น บริษัททัวร์คุยเรื่องการจองตั๋วที่นั่งกับลูกค้ามาเป็น เวลานานหลายชั่วโมง อยู่ดีๆ ไฟดับ จะให้ rollback หายหมด ก็ไม่ใช่เรื่องที่น่ายินดี เลยมีแนวคิดที่ว่า ถ้ามีคน มาเกี่ยวข้อง พอไฟมา ให้ย้อนกลับมา ณ จุดที่ทำค้างไว้ได้

2. Consistency
ถ้า Transaction วิ่งแยกกัน ต่างคนต่างวิ่ง สุดท้ายแล้วแต่ละ Transaction สาเร็จจะต้องถูกต้องและ
สอดคล้องตาม Integrity constraints ยกเว้น Distributed Database โดยหลักการของมันต้องการ 2 Phase Commit เช่น ถอนจากธนาคาร A ฝากที่ธนาคาร B จะต้อง Commit ที่ธนาคาร A และ Commit ที่ธนาคาร B การ Commit ทั้งสองที่นั่นเรียกว่า Local Commit จากนั้นจะต้องการ Global Commit อีกครั้งเพื่อยืนยัน การเปลี่ยนแปลงทุกอย่าง ซึ่งจะมี Delay บ้าง ยอมไม่สอดคล้องแบบทันที สิ่งนี้เป็นสิ่งที่เกิดขึ้นจริงในทางธุรกิจ เรียกเป็นทางการว่า Eventual Consistency (Eventual Commit)

3. Isolation
ถ้ามี Transaction วิ่งร่วมกันในระยะเวลาเดียวกัน ต้องไม่รบกวนกัน แต่ละ Transaction นั้น ไม่
จาเป็นต้องทราบว่ามี Transaction อื่นวิ่งอยู่ และผลลัพธ์ของ Transaction นั้นๆ ต้องไม่มีใครเห็น หรือปรับ ได้ว่าเห็นได้แค่ไหน ไม่จาเป็นต้องไม่ให้เห็นเลย 100 เปอร์เซ็นต์ก็ได้ โดยการปรับ Isolation Levels


ถ้ามี Transaction Ti และ Tj วิ่งร่วมกันดังแบบท่ี 1 ขอให้ผลลัพธ์เหมือนแบบท่ี 2 หรือแบบท่ี 3 ก็ได้ เหมือนแบบไหนก็ได้เพราะมันแค่เสี้ยววินาที อีกทั้งอีกฝ่ายก็ไม่รู้ด้วยว่ามีอีก Transaction วิ่งอยู่ ซึ่งผลลัพธ์ สุดท้ายของแบบท่ี 2 และแบบท่ี 3 จะไม่เหมือนกัน ใครวิ่งก่อนวิ่งหลังไม่สนใจ ขอแค่อย่าวิ่งกวนกันก็พอ ต่างคนต่างวิ่ง สำหรับ Isolation ก็มีข้อยกเว้นเช่นกัน ตัวอย่างเช่น เจ้านายต้องการดูข้อมูลที่ลูกน้องคีย์เข้ามา แต่ เขาบ่นว่าทาไมไม่เห็นทันที ต้องเปิด-ปิดใหม่ทุกครั้ง แสดงว่า DBMS น้ีใช้ Isolation โดย set ระดับที่เจ้านาย (Ti) ไม่เห็นข้อมูลที่ลูกน้องคีย์ (Tj) แต่ในกรณีน้ีควรจะเห็น จึงต้องเปลี่ยนระดับ Isolation ใหม่เป็นระดับที่ ต่ำลง

4. Durability
ถ้า Transaction commit แล้ว การเปล่ียนแปลงท่ีเกิดข้ึนจะต้องคงอยู่ถาวร แม้จะเกิด failure ขึ้นก็ตาม
ซึ่ง failure ก็มีหลายกรณีเช่นที่เกิดโดย Transaction เอง หรือ server down เป็นต้น สาหรับ Durability จะ ไม่มีข้อยกเว้น
โดยสรุปจะเห็นว่าเรื่อง ACID Properties เกี่ยวกับ Transaction เท่านั้น ไม่มีส่วนใดพูดถึง Data model เลย ดังน้ันจะกล่าวว่ามี NoSQL ดีกว่า Relational Database หรือ Relational Database ดีกว่า NoSQL เพราะ อีกตัวไม่มี ACID Properties ไม่ได้ ซึ่ง Data Model ไม่ว่าจะเป็น NoSQL, Tree หรือ Relational Database ล้วนมี ACID Properties ได้ทั้งสิ้น Data Model จะกล่าวเพียง 3 เรื่อง คือ Logical Data Structure, Integrity constraints และ Data Manipulation Language

ยังมีเรื่องราวอีกมากเกี่ยวกับ Transaction Processing เช่น ในการทำ Recovery จะเป็นการดูแล Transaction ให้มี Atomicity และ Durability ส่วนการทา Concurrency control ในการ set Isolation level ต่างๆ เป็นการดูแล Transaction ให้เป็นไปตามหลัก Isolation ซึ่งเป็นคนละเรื่องกับ Recovery system โดย การ recovery ไม่ได้มีส่วนช่วยในการแก้ปัญหาที่เกิดจากการมี Transaction วิ่งร่วมกันมากกว่า 1 Transaction ในช่วงเวลาเดียวกัน ซึ่งปัญหาต่างๆ ช่วยได้ด้วยการ set Isolation Levels ในระดับต่างๆ ซึ่งในแต่ละระดับ DBMS ดูแลไม่เท่ากัน ยิ่ง set ระดับสูงๆก็จะช่วยแก้ปัญหาได้มาก แต่ก็ต้องแลกกับ Performance ซึ่ง DBMS ก็จะต้อง ทำงานหนักขึ้นเช่นกัน แต่ถ้า set ในระดับที่ตำ่กว่าลงมา ก็จะดูแลปัญหาได้ไม่ครบ แต่ performance ก็จะดีขึ้น

จากนี้ก็ยังมีรายละเอียดมากมายที่น่าสนใจทั้งการที่ DBMS ทำ Recovery อย่างไร ถ้า Transaction failure หรือ System crash แล้ว DBMS ดูแลความถูกต้องของ Transaction อย่างไร นิยามที่ว่าถูกต้องนั้นคืออะไร ใช้ กลไกอะไรในการแก้ไขปัญหา Transaction ต่างๆ เช่น ถ้ามี 2 Transactions วิ่งร่วมกัน Transaction ที่มาก่อน read ข้อมูลหนึ่ง จากนั้นมีอีก Transaction มา read ข้อมูลตัวเดียวกัน จากนั้น Transaction แรกก็ write แก้ ข้อมูลเดิมที่พึ่ง read ไป แต่ transaction ที่สองก็มา write ทับไป ข้อมูลที่ต้องการดันหายไป เราเรียกปัญหานี้ว่า Lost update ซึ่งมีอีกหลายๆปัญหาเลยที่ DBMS ช่วยดูแลและแก้ไขปัญหานั้น ซึ่งเป็นเรื่องที่น่าสนใจและสามารถ คุยต่อได้ยาวเลยทีเดียว ถ้ามีโอกาส จะเล่าต่อไปในครั้งหน้าค่ะ

Reference: Database System Concepts (6th Edition), A. Silberschatz, H. Korth and S. Sudarshan, McGraw-Hill Higher Education.


141208.9:32:15
• แปลงจาก PDF ขึ้น web.