- บทความนี้กล่าวถึงประสบการณ์ของผู้เขียนในการดูแลประสิทธิภาพของ Postgres ในแอปพลิเคชัน SaaS โดยฐานข้อมูลเริ่มมีปัญหาในการรองรับภาระงาน
- ทีมของผู้เขียนขยายระบบในแนวตั้งโดยเปลี่ยนไปใช้อินสแตนซ์ที่ใหญ่ขึ้นทุกครั้งที่ฐานข้อมูลยุ่งเกินไป แต่สุดท้ายก็ไปถึงจุดที่ใช้ขนาดใหญ่ที่สุดอยู่แล้วและกำลังจะเข้าสู่ภาวะโอเวอร์โหลด
- มีการเสนอแนวทางแก้ปัญหาที่เป็นไปได้สองแบบ คือการ shard การเขียนไปยังคลัสเตอร์ฐานข้อมูลอิสระ และการแยกโมโนลิทออกเป็นหลายบริการที่เชื่อมต่อกัน (microservices)
- ทั้งสองแนวทางช่วยเพิ่มความจุ และเปิดทางเลือกที่น่าสนใจในด้านความทนทานต่อความขัดข้องและความยืดหยุ่นในการปฏิบัติการ แต่ก็จะเพิ่มความซับซ้อนอย่างมาก
- ผู้เขียนมองว่าต้นทุนที่แท้จริงของความซับซ้อนคือความใส่ใจที่ต้องใช้ ซึ่งจะทำให้ทุกการตัดสินใจทางเทคนิคหลังจากนั้นซับซ้อนขึ้น
- ผู้เขียนเสนอว่า ก่อนจะเพิ่มความซับซ้อนครั้งใหญ่ โดยทั่วไปมักยังมีโอกาส “เค้น” ประสิทธิภาพเพิ่มออกมาจากระบบเดิมได้อีกเล็กน้อย ผ่านการปรับเวิร์กโหลด การจูนประสิทธิภาพ หรือการเสริมระบบในบางรูปแบบ
- ในกรณีของพวกเขา การปรับแต่งคิวรีหนัก ๆ การจูนค่าตั้งของ Postgres และการย้ายคิวรีอ่านอย่างเดียวที่มีต้นทุนสูงบางส่วนไปยังฐานข้อมูลสำเนา ช่วยลดการใช้ CPU สูงสุดรายสัปดาห์ของฐานข้อมูลจาก 90% เหลือ 30%
- ผู้เขียนสรุปว่า แม้ความซับซ้อนจะเป็นสิ่งจำเป็นและหลีกเลี่ยงไม่ได้ แต่ก็ควรเลื่อนการเพิ่มความซับซ้อนออกไปให้นานที่สุด และรีดประสิทธิภาพจากระบบที่มีอยู่ให้ได้มากที่สุดก่อน
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News