วิธีตรวจสอบและเพิ่มประสิทธิภาพฐานข้อมูลของคุณ:คู่มือปฏิบัติ

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

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

เหตุใดจึงต้องตรวจสอบประสิทธิภาพของฐานข้อมูล

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

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

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

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

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

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

• ข้อผิดพลาด

• ประสิทธิภาพ

• ค่าเฉลี่ยและเปอร์เซ็นไทล์ที่ 90 ระยะเวลา

• ปริมาณงานทั้งหมด - เป็นอีกวิธีหนึ่งในการตั้งค่าทริกเกอร์/แฟล็กเมื่อทรูพุตเป็นปัญหา

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

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

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

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

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

ขั้นตอนด้านข้างด่วน:แก้ไขการสืบค้นข้อมูลบางรายการ

ตอนนี้คุณสามารถค้นหาคำค้นหาเพื่อเจาะลึกการแก้ไขได้

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

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

เราได้ทำให้มองเห็นได้ชัดเจนสำหรับรูปแบบการต่อต้านหนึ่งรูปแบบ:N+1 รูปแบบ N+1anti เกิดขึ้นเมื่อดำเนินการค้นหาสำหรับทุกผลลัพธ์ของการสืบค้นก่อนหน้า

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

หากข้อความค้นหาเป็นไปตามรูปแบบการต่อต้าน N+1 นั่นเป็นอุบัติเหตุที่น่ายินดี - มีการติดป้ายกำกับไว้ที่นี่ คุณจึงสามารถค้นหาได้อย่างรวดเร็ว:

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

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

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

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

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

แดชบอร์ด node-postgres จะแสดงข้อมูลดังนี้:

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

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

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

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

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

ขั้นตอนที่ 4:สิ่งที่ควร เก็บ ปลุกคุณตอนกลางคืนไหม

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

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

จากนั้นกำหนดค่าแท็ก "กลุ่ม" และ "เนมสเปซ" สำหรับประเภทของเหตุการณ์ที่คุณต้องการรับการแจ้งเตือนและเนมสเปซใด ตัวอย่างเช่น "active_record" (Rails) หรือ "postgres" (Node.js) หรือ "ecto" (Elixir) สำหรับกลุ่ม และ "web" หรือ "background" สำหรับเนมสเปซ:

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

จากนั้นคุณสามารถปรับทริกเกอร์ให้มีเสียงรบกวนน้อยลงและเพิ่มช่องสัญญาณเมื่อคุณต้องการให้ปลุกด้วยการแจ้งเตือนที่เฉพาะเจาะจง

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

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

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

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

และบางทีคุณอาจพบความสุขในการปรับปรุงข้อความค้นหาที่ 'ส่งผลกระทบ' ครั้งใหญ่ก่อนที่สกรูตัวอื่นๆ จะหลุดออกมา เป็นสิ่งที่เรารักมากที่สุด นั่นคือ และสโตรปวาเฟลส์

ลองใช้ AppSignal รับ Stroopwafels 🍪

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