สืบเนื่องจากโพสก่อนหน้านี้ผมพูดถึง database engine ใน MySQL ไป โดยอธิบายไปว่า บางชนิดจะสนับสนุน transaction แต่บางชนิดไม่สนับสนุน แถมยังเอาลิงก์เกี่ยวกับ transaction ทิ้งไว้ให้ไปอ่านเองอีกด้วย โพสนี้เลยจะขออนุญาตมาขยายความเรื่องเกี่ยวกับ transaction ให้เห็นภาพชัดเจนมากขึ้นกันดีกว่า

Transaction (ทรานแซคชั่น) หมายถึงการดำเนินการธุรกรรมอะไรซักอย่าง แล้วแต่เนื้อหาที่นำไปใช้ เช่น ไปธนาคารถอนเงิน 1 ครั้ง ก็เรียกได้ว่าเกิด 1 transaction หรือโอนเงินให้เพื่อน 1 ครั้ง ก็เรียกว่า 1 transaction ได้เช่นกัน แล้วความสำคัญของ transaction มันอยู่ตรงไหน?… ลองพิจารณากระบวนการโอนเงินดูครับ (ตัวอย่างคลาสสิคมาก) ผมโอนเงินจากบัญชี A ไปบัญชี B กระบวนการย่อยที่เกิดขึ้นคือ ถอนเงินจาก A และฝากเข้าไปที่ B ดังนั้นเราจะเห็นได้ว่า ในธุรกรรมการโอนเงิน 1 transaction จะมี 2 operation ย่อยเกิดขึ้นคือ ถอนเงิน และฝากเงิน

ปัญหาคือ ในกรณีที่ระบบล่มระหว่าง transaction ยังไม่เสร็จสิ้นล่ะ (จากตัวอย่าง เช่น ถอนเงินจาก A มาแล้ว แต่ยังไม่ได้ฝากเข้าไปที่ B) จะเกิดอะไรขึ้น… งานงอกไงครับ

ดังนั้น ไอ้เจ้า transaction เนี่ย อย่างน้อยจำเป็นต้องมีคุณสมบัติที่จะทำให้เรามั่นใจได้ว่า กระบวนการย่อย ๆ ที่เกิดใน transaction เนี่ย ทำงานได้อย่างสมบูรณ์นะ คุณสมบัติพวกนี้ถ้าเอาเฉพาะตัวอักษรตัวแรกของชื่อภาษาอังกฤษมาเรียงกัน จะเขียนได้เป็น ACID ดังนั้น คุณสมบัติของ transaction นี้ก็จะเรียกง่าย ๆ กันว่า ACID properties ของ transaction นั่นเอง โดยที่ ACID properties นี้จะประกอบด้วย

ก่อนที่จะทำความรู้จัก ACID properties … ผมขอแนะนำให้รู้จักคำ 2 คำที่ใช้กันใน transaction ก่อน คือ rollback และ commit … การ rollback หมายถึงการยกเลิกสิ่งที่ทำมาทั้งหมดใน transaction นั้น ๆ ส่วนการ commit คือการยอมรับและบันทึกค่าที่เปลี่ยนแปลงทั้งหมดใน transaction นั้น ๆ

1. Atomicity – คุณสมบัตินี้จะสอดคล้องกับตัวอย่างที่ผมพูดไปก่อนหน้านี้ โดยจะมีหลักง่าย ๆ ที่ชัดเจนคือ transaction ที่ถูกกระทำนี้มี operation ย่อย ๆ หลายคำสั่ง ถ้าทำได้ ก็หมายถึงทำได้ทั้งหมด ถ้าทำอันใดอันหนึ่งไม่ได้ จะหมายถึงทำไม่ได้เลยตั้งแต่คำสั่งแรก (All or nothing)

2. Consistency – คุณสมบัตินี้หมายถึงว่า ความสอดคล้องของข้อมูลจะต้องถูกต้องเสมอ ถ้าไม่ถูกต้องระบบจะต้องทำการ rollback กลับไปยังจุดที่ข้อมูลทั้งหมดสอดคล้องกันอยู่ ยกตัวอย่างเช่น จำนวนเงินที่ก่อนที่จะทำการโอนของทั้ง 2 บัญชีรวมกันจะต้องเท่ากันกับหลักจากทำการโอนแล้ว หรือข้อมูลที่เก็บเฉพาะ integer แต่เราใส่ข้อมูลที่เป็นทศนิยมเข้าไป ข้อมูลทั้งเรคอร์ดนี้ก็ไม่ควรถูกบันทึก หรือในระบบฐานข้อมูลที่มีการกำหนดฟิลด์อ้างอิงได้ (ว่าฟิลด์นี้อ้างถึงฟิลด์ไหนในตารางอื่น) การลบเรคอร์ดที่มีฟิลด์ที่ถูกอ้างอิงก็ควรจะก่อให้เกิด …

• ยกเลิก transaction และ rollback กลับไปยังจุดที่สอดคล้องล่าสุด…หรือ
• ลบเรคอร์ดที่มีการอ้างถึงข้อมูลนี้…หรือ
• ทำฟิลด์ที่อ้างถึงข้อมูลนี้ให้เป็น NULL ซะ

3. Isolation – หมายถึงว่า การประมวลผล transaction หนึ่ง ๆ ถ้ามันยังไม่เสร็จ transaction อื่น ๆ จะต้องไม่เห็นผลจากการกระทำของ transaction นี้ เช่น transaction ที่ 1 โอนเงินจากบัญชี A ไป B จำนวน 200 บาท และ transaction ที่ 2 คือ ถอนเงินจาก A 100 บาท กำหนดให้ในขั้นตอนของ transaction ที่ 2 เกิดขึ้นหลังจากที่ถอนเงินออกจาก A ไป 200 เพื่อที่จะนำไปฝากเข้า B แล้ว จากคุณสมบัติของ Isolation นี้จะทำให้ transaction ที่ 2 ยังไม่เห็นว่า A เงินหายไปแล้ว 200 หรือ B ได้รับเงินแล้ว 200

4. Durability – หมายถึง transaction ใด ๆ ก็ตามที่ทำการ commit แล้ว ข้อมูลจะต้องอยู่แบบนั้น ไม่ว่าระบบจะล่มยังไง เมื่อกู้คืนมาได้ transaction นั้นก็จะยังถือว่า commit และประมวลผลเสร็จสิ้นแล้ว

ครบ 4 อย่างแล้ว… พอเห็นภาพความสำคัญของ transaction ใน database มากขึ้นแล้วหรือยังครับ

การที่เราจะรู้ว่า storage engine แบบไหนเหมาะกับเรานั้น เราก็ต้องมาทำความรู้จักกับ storage engine แต่ละชนิดกันก่อน เพื่อไม่ให้เป็นการเสียเวลา เรามาทำความรู้จักกับ storage engine แต่ละตัวกันดีกว่า (เราสามารถกำหนดให้แต่ละตารางใช้ engine ต่างกันได้ตามความเหมาะสมในการใช้งาน)

• ISAM เป็น storage engine ที่ถูกออกแบบมาโดยที่มีแนวคิดที่ว่า ตารางมักจะถูกอ่านมากกว่าอัพเดท ทำให้ storage engine ชนิดนี้สามารถประมวลผลคำสั่งที่เป็นการอ่านได้อย่างรวดเร็วมาก ๆ แต่มีข้อเสียใหญ่ ๆ คือการไม่สนับสนุนการทำงานแบบ transaction (คือไม่สามารถ rollback ได้ ถ้าเกิดกรณีการทำงานไม่สมบูรณ์ ทางทฤษฎีเรียกว่า ACID transaction properties : สามารถอ่านเพิ่มเติมได้จากที่ http://en.wikipedia.org/wiki/ACID)  และไม่รองรับระบบ fault-tolerant (คือถ้าระบบล่ม ก็อาจจะไม่สามารถที่จะกู้ข้อมูลกลับขึ้นมาได้เลย) ดังนั้นถ้าจะใช้ engine นี้ในงานสำคัญ ก็แนะนำว่าหมั่น backup บ่อย ๆ ครับ
• MyISAM เป็น engine ยอดนิยมสำหรับเว็บทั่ว ๆ ไป พัฒนาต่อเนื่องมาจาก ISAM ทำให้ความเร็วในการอ่านยังเป็นเรื่องที่โดดเด่นอยู่เหมือนเดิม นอกจากนี้แล้วยังมีการเพิ่มส่วนของการทำ indexing และ operation สำหรับ field บางอย่างลงไปด้วย ข้อดีอีกอย่างคือ ใน MyISAM นี้ มี tool ที่ใช้ในการกู้ข้อมูลในกรณีที่ตารางมีปัญหาด้วย (MyISAMChk) แต่ข้อเสียที่สำคัญก็ยังคงอยู่คือ ไม่สนับสนุนการทำงานแบบ transaction และคำสั่ง update ยังส่งผลให้เกิดขยะที่ไม่จำเป็นอีกด้วย ทำให้เราต้องใช้คำสั่ง OPTIMIZE เพื่อจัดการขยะพวกนี้ให้หายไปจากตาราง
• HEAP (หรือ Memory) เป็น engine ที่ไม่ได้สร้างตารางขึ้นมาเป็นไฟล์จริง ๆ เหมือนกับ engine อื่น ๆ แต่จะสร้างตารางลงใน Memory ของเครื่อง ทำให้การเข้าถึงทำได้รวดเร็วยิ่งกว่า ISAM และ MyISAM แต่ข้อเสียคือ มันไม่อยู่ถาวร ถ้ามีการปิดเครื่องหรือระบบล่มโดยที่ยังไม่ได้บันทึกค่าในตารางลงไฟล์ ข้อมูลใน Memory ขณะนั้นก็จะหายไปทั้งหมด ไม่สามารถกู้คืนได้ และทุกครั้งที่ใช้งานตารางที่ใช้ engine นี้เสร็จ ก็จะต้องลบตารางนี้ทิ้งด้วย ไม่เช่นนั้นแล้วจะเกิดขยะใน Memory อาจจะทำให้ Memory ไม่พอในการทำงานได้
• InnoDB และ Berkley DB (BDB) เป็นฐานข้อมูลที่ถูกพัฒนามาให้สนับสนุน transaction และแถมด้วยการสนับสนุน Foreign Key แต่ก็มีข้อเสียคือมันช้ากว่า ISAM และ MyISAM แต่สำหรับผู้ที่จำเป็นจะต้องใช้ transaction แล้ว ก็คงเลี่ยงไม่ได้ที่จะใช้ engine ชนิดนี้
• Cluster ถูกพัฒนาขึ้นเพื่อเพิ่ม High Availability และ High Performance (ประมาณว่าใช้งานได้นาน ๆ และมีประสิทธิภาพดี) แต่ก็จะต้องใช้ resource ในการ implement ค่อนข้างมากเช่นเดียวกัน โดยที่ engine สำหรับ Cluster นี้มีชื่อว่า NDB หรือ NDBCLUSTER (NDB = Network Database)

SELECT  *, (SELECT count(  *  ) FROM comment WHERE topic_id = t.id) rcount FROM  `topic` t

ทีนี้ข้อเสียมันอยู่ตรงไหน? ถ้ายังไม่เห็น ลองสังเกตดี ๆ อีกทีครับ ใครยังนึกไม่ออก ผมจะยกตัวอย่างที่ทำให้เห็นชัดเจนมากขึ้น สมมติว่า แต่ละกระทู้ มีคนตอบกระทู้โดยเฉลี่ยกระทู้ละ 50 comment คำสั่ง COUNT มันก็จะไปนั่งนับจนครบ 50 comment โดย filter ตาม t.id ที่กำหนดแต่ถ้ามีมากกว่านี้ล่ะ เว็บไซต์ดัง ๆ ฮอต ๆ สมาชิกล้นหลาม คนตอบกระทู้เป็นร้อย ๆ พัน ๆ ล่ะ

จะเห็นได้ว่า “ทุกครั้ง” ที่มีคนเปิดหน้าแสดงรายชื่อกระทู้ มันจะต้องไปนั่งนับทุกครั้ง ทั้ง ๆ ที่อาจจะไม่ได้มีใครไปตอบกระทู้เพิ่มเลยก็ได้ สิ่งที่เราได้กลับมาจากการทำ Normalization ในครั้งนี้คือ การสิ้นเปลือง CPU สุด ๆ นั่นเอง เรามาหาทางแก้ปัญหากันดีกว่า

วิธีแก้ปัญหาแบบหนึ่งที่ผมจะพูดถึงในครั้งนี้คือการทำ cache ผมไม่ได้หมายถึงการทำ file cache หรือ memory cache นะ แต่ผมหมายถึงการ cache ลงไปในฟิลด์ในตารางครับ

พูดให้ชัดเจนอีกนิดคือ ผมหมายถึงการเพิ่มความซ้ำซ้อนของข้อมูลลงไปอีกนิด เพื่อชีวิตที่ดีกว่า โดยการเพิ่มฟิลด์ชื่อ comment_count ลงไปในตาราง topic และทุกครั้งที่มีการตอบกระทู้ หรือลบ comment ผมก็แค่มาอัพเดทฟิลด์นี้ด้วยเท่านั้นเอง

UPDATE topic SET comment_count = (SELECT COUNT(*) comment_count FROM comment WHERE topic_id = t.id)

ด้วย SQL Statement ข้างบนนี้ มันก็จะไป sync ข้อมูลจำนวนนับจากตาราง comment มาลงในตาราง topic ให้ผม และทุกครั้งที่แสดงหน้ากระทู้ ผมก็เอา comment_count ไปใช้แทน subquery ได้เลย สบายจริง ๆ ครับ

แบบแรกคือ การเปรียบเทียบด้วย Binary String เช่น

mysql> SET @s = BINARY 'MySQL';
mysql> SELECT @s = 'mysql';

+--------------+
| @s = 'mysql' |
+--------------+
|            0 |
+--------------+

แบบที่สองคือ การสั่งเปลี่ยน COLLATE ให้เป็นแบบที่สนับสนุนการเปรียบเทียบแบบ case-sensitive นั่นคือ latin1_bin หรือ latin1_general_cs เช่น

mysql> SET @s1 = 'MySQL' COLLATE latin1_bin,
    ->     @s2 = 'mysql' COLLATE latin1_bin;
mysql> SELECT @s1 = @s2;
+-----------+
| @s1 = @s2 |
+-----------+
|         0 |
+-----------+

แบบที่ 3 ก็เป็นการเปลี่ยน Collation เช่นเดียวกัน แต่เป็นการไปตั้งค่าที่ field ใน table ของเราเลยครับ แค่เพียงเลือก field ที่ต้องการ และเปลี่ยน collation ให้เป็น latin1_bin หรือ latin1_general_cs ก็ใช้ได้แล้วครับ

อ้างอิง

• http://dev.mysql.com/doc/refman/5.0/en/case-sensitivity.html