เชี่ยวชาญประสิทธิภาพฐานข้อมูล: เทคนิคการตรวจสอบและเพิ่มประสิทธิภาพอย่างเป็นปฏิบัติ

สิ่งสำคัญคือต้องมองภาพรวมของสถาปัตยกรรมแอปพลิเคชัน ไม่ใช่แค่ด้านเฉพาะเจาะจง และเข้าใจว่าส่วนต่างๆ เชื่อมต่อกันอย่างไร การสังเกตการณ์ (Observability) มาก่อน ตามด้วยการตรวจสอบ (Monitoring)

ในบทความนี้ เราจะเจาะลึกส่วนของฐานข้อมูลในสถาปัตยกรรมของคุณ เพื่อแสดงวิธีการตรวจสอบและเพิ่มประสิทธิภาพฐานข้อมูล หลักการส่วนใหญ่สามารถนำไปใช้ได้ ไม่ว่าคุณจะใช้เทคโนโลยีใดก็ตาม หรือต้องการตรวจสอบและเพิ่มประสิทธิภาพสำหรับ PostgreSQL, MongoDB หรือฐานข้อมูลอื่นๆ

ทำไมต้องตรวจสอบประสิทธิภาพฐานข้อมูล?

สมมติว่าคิวรี่ทำงานช้ามาก และแอปของคุณต้องรอผลลัพธ์ ทำให้ผู้ใช้ปลายทางหรือส่วนหนึ่งของแอปหยุดทำงาน

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

เป้าหมายของคุณคือค้นหาต้นเหตุของปัญหาก่อนที่สิ่งต่างๆ จะเริ่มผิดปกติในส่วนอื่นของแอป

ขั้นตอนต่อไปคือใช้การตรวจสอบแบบเชิงรุกเพื่อเพิ่มประสิทธิภาพสถาปัตยกรรมและดูว่าสามารถทำให้เร็วขึ้นได้อย่างไร แต่เรากำลังข้ามไปข้างหน้าเกินไป มาเริ่มจากขั้นตอนที่ 1 กัน:

ขั้นตอนที่ 1: การวัดค่า (Instrumenting) ประสิทธิภาพฐานข้อมูล

การตรวจสอบฐานข้อมูลเริ่มต้นจากการรับรองว่าคุณวัดสิ่งที่ถูกต้อง:

• ข้อผิดพลาด (Errors)
• ประสิทธิภาพ (Performance)

• ค่าเฉลี่ยและเปอร์เซ็นไทล์ที่ 90 ของระยะเวลาคิวรี่ (duration)
• Throughput รวม - ให้วิธีอีกอย่างในการตั้งค่า Trigger/Flag เมื่อ Throughput มีปัญหา

โชคดีที่ข้อมูลเหล่านี้ได้รับการรวบรวมไว้แล้ว: ซอฟต์แวร์ APM ของคุณน่าจะให้คุณกำหนดสิ่งที่ต้องการ Instrument และวัดได้ หากคุณใช้ AppSignal การรวบรวมและรวมข้อมูลจะเกิดขึ้นโดยอัตโนมัติ โดยไม่ต้องตั้งค่ามากนัก เราทำงานหนักแทนคุณแล้ว!

ขั้นตอนที่ 2: จุดเริ่มต้น - ค้นหาคิวรี่ที่มีผลกระทบสูง

เมื่อคุณ Instrument แอปแล้วและข้อมูลจริงเริ่มเข้ามา รูปแบบต่างๆ จะเริ่มปรากฏขึ้น ใน AppSignal เราสร้างหน้าจอสำหรับ API Request ที่ช้าที่สุด และคิวรี่ที่ช้าที่สุด ภายใต้เมนู 'Improve' ในการนำทาง:

หน้าจอนี้จะให้จุดเริ่มต้นที่ดีสำหรับการเพิ่มประสิทธิภาพ โดยค่าเริ่มต้น คิวรี่ที่ช้าจะถูกจัดเรียงตามผลกระทบ (Impact) นั่นคือคิวรี่ที่คุณทำบ่อยที่สุด Impact คำนวณจาก Throughput x เวลาคิวรี่เฉลี่ย

การสลับระหว่างการจัดเรียงเหล่านี้จะให้ความเข้าใจเกี่ยวกับคิวรี่ที่มีปริมาณมากที่สุด คิวรี่ที่ช้าที่สุด (แต่อาจเป็น Background Job ที่รันครั้งเดียวต่อคืนซึ่งคุณสามารถเพิกเฉยได้) และคิวรี่ที่มีผลกระทบมากที่สุด

ขั้นตอนพิเศษ: แก้ไขคิวรี่บางรายการเป็นรายตัว

ตอนนี้คุณสามารถค้นหาคิวรี่บางรายการเพื่อดำเนินการแก้ไขได้

หากคุณคลิกที่คิวรี่ที่ช้า คุณจะเห็นรายละเอียดทั้งหมดทางด้านขวา ตั้งแต่ Throughput และ Response Time ของคิวรี่ ไปจนถึงชื่อคิวรี่เอง:

วางเมาส์เหนือ Response Time ที่จุดสูงสุด แล้วคุณสามารถซูมเข้าไปได้โดยคลิกที่ตัวเลือก 'what happened here' คุณจะเห็นข้อผิดพลาดที่เกิดขึ้นในช่วงเวลานั้น ในตัวอย่างนั้น และสิ่งที่เกิดขึ้นบน Host

เราทำให้มองเห็นได้ชัดเจนสำหรับ Anti-pattern หนึ่งที่เป็นที่รู้จักดี: N+1 Anti-pattern เกิดขึ้นเมื่อคิวรี่ถูก Execute สำหรับทุกผลลัพธ์ของคิวรี่ก่อนหน้า

จำนวนคิวรี่คือ N + 1 โดย N คือจำนวนคิวรี่สำหรับผลลัพธ์ของคิวรี่แรก หากคิวรี่แรกมีผลลัพธ์ 1 รายการ N+1 = 2 หากมี 1,000 ผลลัพธ์ N+1 = 1,001 คิวรี่ บูม!

หากคิวรี่ทำตาม N+1 Anti-pattern นั่นคือโชคดี - พวกเขาถูกติดป้ายกำกับที่นี่เพื่อให้คุณค้นหาได้ง่าย:

เราจะไม่กล่าวถึงวิธีแก้ไขที่นี่ - เราเขียนบล็อกโพสต์แยกเกี่ยวกับ N+1 Queries ไว้แล้ว

ดีแล้ว สมมติว่าเราแก้ไขบางสิ่งที่แย่ๆ แล้ว และขณะที่เราแก้ไข เราสังเกตเห็นเวลาที่เกิดขึ้นและ Response Time ที่แย่ที่สุด

ขั้นตอนที่ 3: การค้นหา การตัดสินใจรูปแบบ - อะไรผิดปกติ?

การตรวจสอบมักเกี่ยวกับการมองดูเมื่อสิ่งต่างๆ ผิดปกติ แต่ส่วนหนึ่งของความซับซ้อนคือการกำหนดว่าอะไรควรถือว่า 'ผิดปกติ' สำหรับ Setup ของคุณ นอกจากนี้ คุณชอบที่จะได้รับการแจ้งเตือนจากปัญหาที่แก้ตัวเองได้ ไปกว่าการพลาดปัญหาที่ไม่แก้ตัวเอง?

มา看看 Throughput และ Duration ของคิวรี่เฉลี่ย คุณสามารถตั้งค่าได้ในซอฟต์แวร์ APM หากคุณใช้ AppSignal ตรวจสอบ Node.js และใช้ PostgreSQL เป็นฐานข้อมูล เราสร้าง Dashboard พร้อม Metric สำคัญให้โดยอัตโนมัติ

Dashboard node-postgres จะแสดงข้อมูลแบบนี้:

หากคุณต้องการตั้งค่านี้สำหรับแอปของคุณ นี่คือข้อมูลเพิ่มเติม

เมื่อคุณสลับระหว่างช่วงเวลาต่างๆ คุณจะเห็น Peak สั้นๆ ที่หายไปในค่าเฉลี่ยของชั่วโมง และ Peak ที่คงอยู่สูงเมื่อซูมออกไปยังช่วงเวลาที่ยาวขึ้น

จากประสบการณ์ของเราที่เห็นหน้าจอคิวรี่ช้าที่สุด เราตอนนี้มีความเข้าใจเกี่ยวกับผู้กระทำผิดหลักและเวลาที่ Peak

Peak สั้นๆ บางอย่างใน Throughput อาจไม่เป็นไร - Host อาจรัน Process อื่นที่ทำให้คิวรี่ช้า ตัวอย่างเช่น

คุณจะต้องการซูมเข้าไปในคิวรี่ที่ใช้เวลานานอย่างต่อเนื่อง หรือ Throughput ที่ Peak การดูเปอร์เซ็นไทล์ที่ 95 เทียบกับค่าเฉลี่ย จะบอกได้ว่าคิวรี่ที่ช้ากว่านั้นถูกประสบโดยทุกคน หรือเพียงกลุ่มย่อย ซึ่งบางครั้งช่วยชี้ทางให้คุณรู้ว่าควรแก้ไขอะไร

ขั้นตอนที่ 4: อะไรควรให้คุณ ทำคุณไม่หลับ?

เรามักแนะนำให้เริ่มจากด้านที่มีเสียงรบกวน: ตั้ง Trigger แจ้งเตือนบน Channel ที่ไม่ปลุกคุณขึ้นมา เช่น Email หรือ Slack แทนที่จะเป็น PagerDuty

สร้าง Custom Metrics Trigger บน Metric "event_duration" และเลือก Mean Field เพื่อรับ Alert เกี่ยวกับเวลาคิวรี่เฉลี่ยในแอป เลือกเปอร์เซ็นไทล์ที่ 90 หรือ 95 เพื่อรับ Alert สำหรับคิวรี่ที่ช้าที่สุดที่แอปเจอ

จากนั้นกำหนด Tag "group" และ "namespace" สำหรับประเภท Event ที่คุณต้องการให้แจ้งเตือน และใน Namespace ไหน ตัวอย่างเช่น "active_record" (Rails) หรือ "postgres" (Node.js) หรือ "ecto" (Elixir) สำหรับ Group และ "web" หรือ "background" สำหรับ Namespace:

หลังจากหนึ่งสัปดาห์ คุณจะเริ่มเห็นรูปแบบและได้ไอเดียว่ากรณีไหนต้องการความสนใจ และกรณีไหนมักแก้ตัวเอง

จากนั้นคุณสามารถปรับ Trigger ให้รบกวนน้อยลง และเพิ่ม Channel สำหรับเมื่อคุณต้องการถูกปลุกขึ้นมาจาก Alert เฉพาะเจาะจง

ขั้นตอนที่ 5: เสร็จสิ้นการตั้งค่าการตรวจสอบฐานข้อมูล

ตอนนี้ ในทฤษฎี เราควรมี Setup การตรวจสอบที่ดี: ข้อมูลที่ถูกต้องเข้ามา เราตั้ง Trigger เพื่อเตือนเราก่อนที่สิ่งร้ายจะเกิด และเราพบผู้กระทำผิดขนาดใหญ่บางราย ควรจะเสร็จแล้วใช่ไหม?

ในความเป็นจริง การใช้งานแอปของคุณอาจเติบโตและสร้าง Bottleneck ใหม่ หรือการเปลี่ยนแปลงโค้ดอาจส่งผลต่อฐานข้อมูล ทำให้ Duration เพิ่มขึ้น หรือ Field เฉพาะที่มี Payload ใหญ่จะ Trigger สิ่งใดสิ่งหนึ่ง แม้คุณจะมีประสบการณ์มากน้อยเพียงใด ปัญหาและ Bottleneck ใหม่จะเกิดขึ้น

แต่คุณสามารถสบายใจได้ว่า ด้วย Setup ที่เหมาะสม คุณจะได้รับการเตือนและรู้วิธีเจาะลึกสถาปัตยกรรมเพื่อแก้ไขปัญหาเหล่านี้

และอาจคุณจะพบความสุขในการปรับปรุงคิวรี่ 'Impactful' ขนาดใหญ่ ก่อนที่สกรูอื่นๆ จะหลุดออกไป นั่นคือสิ่งที่เราชอบที่สุด - นั่นและ Stroopwafels

ลอง AppSignal รับ Stroopwafels ฟรี 🍪

พูดถึง Stroopwafels เราส่งไปทั่วโลก ลองใช้ซอฟต์แวร์ APM ของ AppSignal สำหรับ Ruby, Elixir และ Node.js หากคุณสมัครทดลองใช้ฟรีและติดต่อเรา เราจะส่งกล่อง Stroopwafels ให้ฟรี!