คำถามที่น่าสนใจเกี่ยวกับ database คือ
ในแต่ละ database ของระบบงานเรานั้น
มีจำนวน table เท่าไร ?
ในแต่ละ table มีกี่ column ?
ในแต่ละ table มี PK, FK และ index กี่ตัว ?
ในแต่ละ table มีข้อมูลกี่ row และจะโตขึ้นอีกด้วยอัตราความเร็วเท่าไร ?
คำถามเหล่านี้จะเป็นตัวชี้วัดคร่าว ๆ ว่า
database ที่เราออกแบบ หรือ ใช้งานนั้น จะระเบิดเมื่อใด นั่นเอง !!
ปัญหาที่มักจะเจอกับ database เช่น
- Out-of-Memory (OOM)
- CPU มัน peak ขึ้นมา สำหรับ long-running query !!
หนึ่งในคำถามที่น่าสนใจคือ ใน database มี table จำนวนเท่าไร ?
และมันส่งผลต่อการใช้งาน memory อย่างไร ?
ยกตัวอย่างเช่นใน PostgreSQL
เมื่อทำการสร้าง table และ column จำนวนมาก ๆ ขึ้นมา
พบว่าจำมีการทำ cache ใน memory ขึ้นมา
โดยทุกคนที่ใช้งาน ต้องรู้ limit อยู่แล้ว
ตัวอย่างเช่นสร้าง table จำนวน 1,000 table
และในแต่ละ table มีสัก 10 column ขึ้นมา
จากนั้นทำการ query ข้อมูลจากทั้ง 1,000 table ขึ้นมา
พบว่า ในแต่ละ connection นั้นจะมีการทำ caching ให้
โดยก่อนและหลังจะมีค่าเป็นดังนี้
ข้อมูลที่เจอคือ ใช้ memory ต่อ 1 connection ไป 16 MB
นั่นหมายความว่ายิ่งมี connection เยอะก็ยิ่งเปลืองหรือไม่ ?
การจำกัดจำนวน connection ใน connection pool ก็ช่วยลดปัญหาได้
หรือการกำหนด idle_session_timeout ให้น้อยลง ก็ช่วยลดปัญหาได้
แต่ก็อาจจะเกิดปัญหาใหม่ตามมา !!
ในตัวอย่างนี้เป็น table เปล่า ๆ ยังไม่มีมีข้อมูล
ดังนั้นจำนวน table น่าจะต้องพึงระวังกันด้วย สำหรับการออกแบบ
และที่สำคัญใน cache นั้น มันมีทั้ง table, index, PK/FK, sequence และ type เป็นต้น
ซึ่งน่าจะเป็น root cause หนึ่งอีกด้วย ของ OOM !!
ผมคิดว่า
คงไม่มีใครสร้าง table เยอะ ๆ ในหนึ่ง database หรอกนะครับ
และในหนึ่ง table ก็ไม่มี column เยอะหรอกนะครับ
และข้อมูลในแต่ละ record คงไม่ใหญ่หรอกนะครับ
และคงไม่เก็บข้อมูลเยอะ ๆ แล้ว query มาใช้ไม่ถึง 10% หรอกนะครับ
อย่าลืมว่า เรากำลังแก้ไขปัญหา ไม่ใช่สร้างปัญหานะครับ
Reference websites
