CQRS: แยกเส้นทางเขียนกับอ่านข้อมูล เมื่อความต้องการต่างกันสุดขั้ว
การบันทึกข้อมูลต้องการความถูกต้องเข้มงวด ส่วนการอ่านต้องการความเร็วและรูปแบบที่หลากหลาย การใช้โมเดลเดียวรับทั้งสองหน้าที่มักได้ของกลาง ๆ ที่ไม่ดีสักด้าน CQRS แยกสองเส้นทางนี้ออกจากกัน
ระบบส่วนใหญ่ใช้โครงสร้างข้อมูลชุดเดียวทั้งตอนบันทึกและตอนอ่าน ซึ่งทำงานได้ดีจนกระทั่งสองฝั่งเริ่มต้องการสิ่งที่ตรงข้ามกัน ฝั่งบันทึกต้องการโครงสร้างที่เข้มงวด ตรวจกฎธุรกิจครบ ไม่ให้ข้อมูลผิดหลุดเข้า ส่วนฝั่งอ่านต้องการความเร็วและรูปแบบที่ตรงกับหน้าจอ เช่น หน้าแดชบอร์ดที่รวมข้อมูลจากสิบตาราง CQRS หรือ Command Query Responsibility Segregation คือแนวคิดแยกสองหน้าที่นี้ออกจากกัน ฝั่งเขียนมีโมเดลของตัวเองที่เน้นความถูกต้อง ฝั่งอ่านมีโมเดลของตัวเองที่จัดรูปข้อมูลไว้ล่วงหน้าให้อ่านเร็ว
ราคาที่ต้องจ่าย คือความซับซ้อน
เมื่อแยกสองโมเดล ก็ต้องมีกลไกส่งข้อมูลจากฝั่งเขียนไปอัปเดตฝั่งอ่าน ซึ่งใช้เวลาชั่วครู่ หมายความว่าหน้าจออาจแสดงข้อมูลที่ช้ากว่าความจริงเล็กน้อย และทีมต้องดูแลสองโครงสร้างแทนที่จะเป็นหนึ่ง นี่คือเหตุผลที่ CQRS ไม่ใช่ของที่ควรใช้ทุกที่ ระบบทั่วไปที่โมเดลเดียวยังตอบทั้งสองฝั่งได้ดี ก็ควรใช้โมเดลเดียวต่อไป CQRS คุ้มเมื่อสองฝั่งขัดแย้งกันจริง เช่น ระบบที่มีคนอ่านมากกว่าคนเขียนหลายเท่า หรือหน้ารายงานที่ซับซ้อนจนถ่วงระบบหลัก ซึ่งเป็นเส้นทางเดียวกับที่หลายทีมเริ่มจากการทำสำเนาฐานข้อมูลสำหรับอ่านก่อน แล้วค่อยขยับมาแยกโมเดลเต็มตัว
- ฝั่งเขียนเน้นตรวจกฎให้ถูกต้อง ฝั่งอ่านเน้นจัดรูปไว้ให้เร็ว
- ยอมรับว่าฝั่งอ่านตามหลังความจริงชั่วครู่ และออกแบบหน้าจอให้เหมาะ
- ใช้เมื่อสองฝั่งขัดแย้งกันจริง อย่าแยกเพราะเห็นคนอื่นแยก
CQRS เป็นตัวอย่างที่ดีของหลักการใหญ่ในการออกแบบระบบ คือเมื่อหน้าที่สองอย่างต้องการคุณสมบัติที่ตรงข้ามกัน การแยกมันออกจากกันมักดีกว่าฝืนรวม สำหรับธุรกิจ ความเข้าใจนี้ช่วยอธิบายว่าทำไมระบบที่คนใช้อ่านรายงานหนัก ๆ ถึงควรแยกเส้นทางออกจากระบบงานหลัก และทำไมการแยกนั้นถึงมาพร้อมต้นทุนการดูแลที่ต้องชั่งใจก่อนตัดสินใจ
บริการที่เกี่ยวข้อง
รับพัฒนาเว็บแอปพลิเคชัน
สร้างเว็บแอปที่รองรับการเติบโตและเชื่อมกับระบบอื่นได้
WhaleScope
ดูโครงสร้างตลาดของทุกหมวดธุรกิจไทย บน WhaleScope
รายชื่อบริษัท ผู้เล่นรายใหญ่ และอัตราคงอยู่ของแต่ละหมวด — จากข้อมูลจดทะเบียน 2 ล้านนิติบุคคล
อ่านต่อ
Read Replica: แยกงานอ่านออกจากงานเขียน เพื่อให้ระบบไหว
ระบบส่วนใหญ่อ่านข้อมูลบ่อยกว่าเขียนมาก เมื่อฐานข้อมูลเดียวรับทั้งสองไม่ไหว Read Replica คือการทำสำเนาไว้รับงานอ่าน ช่วยให้รายงานและหน้าเว็บเร็วขึ้นโดยไม่กระทบงานเขียน
Database Index: ทำไมระบบช้าลงเมื่อข้อมูลโต และแก้ได้อย่างไร
ระบบที่เคยเร็วตอนข้อมูลน้อย เริ่มอืดเมื่อข้อมูลโตขึ้น สาเหตุยอดฮิตคือการค้นหาที่ไม่มี Index เข้าใจว่า Index ช่วยอย่างไร และทำไมใส่มากเกินก็เป็นปัญหา
Connection Pooling: จัดการการเชื่อมต่อฐานข้อมูลให้ไม่ล้น
ทุกการเชื่อมต่อฐานข้อมูลมีต้นทุน ถ้าเปิดใหม่ทุกคำขอ ระบบจะช้าและล้มเมื่อคนเยอะ Connection Pooling คือการใช้การเชื่อมต่อซ้ำจากสระกลาง ทำให้เร็วขึ้นและทนโหลดได้มากขึ้น
N+1 Query: ปัญหายอดฮิตที่ทำให้ระบบช้าโดยไม่รู้ตัว
หน้าจอที่แสดงรายการ 100 รายการ อาจยิงคำขอไปฐานข้อมูลถึง 101 ครั้งโดยไม่จำเป็น นี่คือปัญหา N+1 Query ที่พบบ่อยมาก ฟังดูเล็กแต่ทำให้ระบบช้าลงหลายเท่า