Schema Migration: เปลี่ยนโครงสร้างฐานข้อมูลโดยไม่ทำระบบล่ม

การเปลี่ยนโครงสร้างฐานข้อมูลของระบบที่ใช้งานอยู่ เสี่ยงทำระบบล่มถ้าทำผิดจังหวะ วิธี expand-contract ค่อย ๆ เปลี่ยนเป็นขั้น ให้โค้ดเก่าและใหม่อยู่ร่วมกันได้ จนเปลี่ยนเสร็จโดยไม่ต้องหยุดบริการ
การเปลี่ยนโครงสร้างฐานข้อมูล เช่น เปลี่ยนชื่อคอลัมน์ แยกตาราง หรือเปลี่ยนชนิดข้อมูล ในระบบที่กำลังใช้งานจริง เป็นงานเสี่ยง เพราะถ้าเปลี่ยนโครงสร้างพร้อมกับปล่อยโค้ดใหม่ในจังหวะเดียว ช่วงเปลี่ยนผ่านอาจมีโค้ดเก่าที่ยังทำงานอยู่แต่หาคอลัมน์เดิมไม่เจอ ทำให้ระบบพัง วิธีที่ปลอดภัยคือ expand-contract คือค่อย ๆ เปลี่ยนเป็นขั้น ให้ทั้งของเก่าและของใหม่อยู่ร่วมกันได้ระหว่างทาง
expand ก่อน แล้วค่อย contract
แนวคิด expand-contract แบ่งการเปลี่ยนเป็นขั้น ขั้น expand คือเพิ่มโครงสร้างใหม่เข้าไปโดยไม่ลบของเก่า เช่น เพิ่มคอลัมน์ใหม่ แล้วให้โค้ดเขียนลงทั้งที่เก่าและใหม่ จากนั้นค่อย ๆ ย้ายให้โค้ดอ่านจากที่ใหม่ เมื่อมั่นใจว่าไม่มีใครใช้ของเก่าแล้ว ขั้น contract คือลบโครงสร้างเก่าทิ้ง การทำเป็นขั้นแบบนี้ทำให้ไม่มีช่วงไหนที่โค้ดที่รันอยู่หาโครงสร้างที่ต้องใช้ไม่เจอ จึงเปลี่ยนได้โดยไม่ต้องหยุดบริการ
- เพิ่มของใหม่ก่อน โดยยังไม่ลบของเก่า (expand)
- ให้โค้ดเก่าและใหม่อยู่ร่วมกันได้ระหว่างเปลี่ยนผ่าน
- ลบของเก่าเมื่อมั่นใจว่าไม่มีใครใช้แล้ว (contract)
Schema Migration แบบ expand-contract เป็นแนวปฏิบัติที่ทำให้ระบบเปลี่ยนแปลงและเติบโตได้โดยไม่ต้องหยุดบริการ ซึ่งสำคัญมากเมื่อธุรกิจพึ่งระบบออนไลน์ตลอดเวลา การเข้าใจว่าการเปลี่ยนโครงสร้างข้อมูลต้องทำอย่างค่อยเป็นค่อยไป ช่วยให้ตั้งคำถามกับทีมได้ว่าการเปลี่ยนแปลงครั้งต่อไปจะกระทบผู้ใช้หรือไม่ และเป็นอีกชิ้นหนึ่งของการปล่อยของแบบไม่มีดาวน์ไทม์
บริการที่เกี่ยวข้อง
รับพัฒนาเว็บแอปพลิเคชัน
สร้างเว็บแอปที่รองรับการเติบโตและเชื่อมกับระบบอื่นได้
WhaleScope
ดูโครงสร้างตลาดของทุกหมวดธุรกิจไทย บน WhaleScope
รายชื่อบริษัท ผู้เล่นรายใหญ่ และอัตราคงอยู่ของแต่ละหมวด — จากข้อมูลจดทะเบียน 2 ล้านนิติบุคคล
อ่านต่อ

Containerization: แพ็กแอปให้รันเหมือนกันทุกที่
ปัญหาคลาสสิกคือ บนเครื่องผมมันรันได้ แต่ขึ้นเซิร์ฟเวอร์กลับพัง Containerization แก้ด้วยการแพ็กแอปพร้อมทุกอย่างที่ต้องใช้ ให้รันเหมือนกันทุกที่ ลดปัญหาความต่างของสภาพแวดล้อม

Feature Flags: ปล่อยฟีเจอร์ทีละนิด และปิดได้ทันทีเมื่อพัง
การปล่อยฟีเจอร์ใหม่ให้ทุกคนพร้อมกัน คือการเดิมพันก้อนใหญ่ Feature Flags ช่วยให้เปิดฟีเจอร์ทีละกลุ่ม วัดผล และปิดได้ทันทีถ้ามีปัญหา โดยไม่ต้องรีบแก้โค้ดกลางดึก

Database Sharding: แบ่งฐานข้อมูลเมื่อใหญ่เกินเครื่องเดียว
เมื่อข้อมูลใหญ่จนเครื่องเดียวรับไม่ไหว การเพิ่มเครื่องให้แรงขึ้นมีเพดาน Sharding คือการแบ่งข้อมูลออกไปหลายเครื่อง ช่วยให้ขยายต่อได้ แต่ก็เพิ่มความซับซ้อนที่ต้องแลก

Read Replica: แยกงานอ่านออกจากงานเขียน เพื่อให้ระบบไหว
ระบบส่วนใหญ่อ่านข้อมูลบ่อยกว่าเขียนมาก เมื่อฐานข้อมูลเดียวรับทั้งสองไม่ไหว Read Replica คือการทำสำเนาไว้รับงานอ่าน ช่วยให้รายงานและหน้าเว็บเร็วขึ้นโดยไม่กระทบงานเขียน
