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

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

การเปลี่ยนโครงสร้างฐานข้อมูลของระบบที่ใช้งานอยู่ เสี่ยงทำระบบล่มถ้าทำผิดจังหวะ วิธี expand-contract ค่อย ๆ เปลี่ยนเป็นขั้น ให้โค้ดเก่าและใหม่อยู่ร่วมกันได้ จนเปลี่ยนเสร็จโดยไม่ต้องหยุดบริการ

การเปลี่ยนโครงสร้างฐานข้อมูล เช่น เปลี่ยนชื่อคอลัมน์ แยกตาราง หรือเปลี่ยนชนิดข้อมูล ในระบบที่กำลังใช้งานจริง เป็นงานเสี่ยง เพราะถ้าเปลี่ยนโครงสร้างพร้อมกับปล่อยโค้ดใหม่ในจังหวะเดียว ช่วงเปลี่ยนผ่านอาจมีโค้ดเก่าที่ยังทำงานอยู่แต่หาคอลัมน์เดิมไม่เจอ ทำให้ระบบพัง วิธีที่ปลอดภัยคือ expand-contract คือค่อย ๆ เปลี่ยนเป็นขั้น ให้ทั้งของเก่าและของใหม่อยู่ร่วมกันได้ระหว่างทาง

expand ก่อน แล้วค่อย contract

แนวคิด expand-contract แบ่งการเปลี่ยนเป็นขั้น ขั้น expand คือเพิ่มโครงสร้างใหม่เข้าไปโดยไม่ลบของเก่า เช่น เพิ่มคอลัมน์ใหม่ แล้วให้โค้ดเขียนลงทั้งที่เก่าและใหม่ จากนั้นค่อย ๆ ย้ายให้โค้ดอ่านจากที่ใหม่ เมื่อมั่นใจว่าไม่มีใครใช้ของเก่าแล้ว ขั้น contract คือลบโครงสร้างเก่าทิ้ง การทำเป็นขั้นแบบนี้ทำให้ไม่มีช่วงไหนที่โค้ดที่รันอยู่หาโครงสร้างที่ต้องใช้ไม่เจอ จึงเปลี่ยนได้โดยไม่ต้องหยุดบริการ

  • เพิ่มของใหม่ก่อน โดยยังไม่ลบของเก่า (expand)
  • ให้โค้ดเก่าและใหม่อยู่ร่วมกันได้ระหว่างเปลี่ยนผ่าน
  • ลบของเก่าเมื่อมั่นใจว่าไม่มีใครใช้แล้ว (contract)

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

Schema MigrationDatabaseZero DowntimeDeployment

บริการที่เกี่ยวข้อง

รับพัฒนาเว็บแอปพลิเคชัน

สร้างเว็บแอปที่รองรับการเติบโตและเชื่อมกับระบบอื่นได้

WhaleScope

ดูโครงสร้างตลาดของทุกหมวดธุรกิจไทย บน WhaleScope

รายชื่อบริษัท ผู้เล่นรายใหญ่ และอัตราคงอยู่ของแต่ละหมวด — จากข้อมูลจดทะเบียน 2 ล้านนิติบุคคล

อ่านต่อ

Containerization: แพ็กแอปให้รันเหมือนกันทุกที่

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

Feature Flags: ปล่อยฟีเจอร์ทีละนิด และปิดได้ทันทีเมื่อพัง

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

Database Sharding: แบ่งฐานข้อมูลเมื่อใหญ่เกินเครื่องเดียว

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

Read Replica: แยกงานอ่านออกจากงานเขียน เพื่อให้ระบบไหว

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