การวางแผนความจุสำหรับฐานข้อมูล

หมายเหตุ: โพสต์นี้ได้รับแรงบันดาลใจจากโพสต์ล่าสุดของ Julia Evans เกี่ยวกับการวางแผนกำลังการผลิต

RDBMS

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

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

ชาร์ดิง

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

หากคุณเป็นบริษัทใหม่ คุณอาจไม่ต้องการ functional sharding ในวันที่ 1 แต่ถ้าคุณหวังว่า (และฉันสงสัยว่าคุณทำ) จะเติบโต อย่ารวมตัวเองด้วย ORM โอเพ่นซอร์สที่ไม่อนุญาตให้คุณแยกออก ข้อมูลของคุณบนพื้นฐานการทำงาน คะแนนโบนัสหากคุณไม่ได้เริ่มต้นบริษัทด้วยข้อมูลเชิงสัมพันธ์ทั้งหมดในสคีมาเดียว

ความสามารถในการแยกอ่านและเขียน

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

มาสู่กระบวนการคิดของการวางแผนความจุจริง…คลัสเตอร์ฐานข้อมูลไม่ต่อเนื่อง ฉันควรทำอย่างไร

กำหนดคอขวดของระบบ

• คุณมีปัญหาคอขวดในการเขียนหรืออ่านหรือไม่?
• ปัญหาแสดงเป็น CPU สูงหรือไม่
• มันแสดงเป็นความจุ IO หรือไม่?
• มันเพิ่มความล่าช้าในการจำลองโดยไม่มีผู้กระทำผิดในการอ่านที่ชัดเจนหรือไม่?
• มันล็อค?
• ฉันจะรู้ได้อย่างไรว่ามันคืออะไร?

แต่ละรายการนี้สามารถโพสต์ได้ด้วยตัวเอง ประเด็นที่ฉันกำลังพยายามทำคือ คุณต้องทำความคุ้นเคยกับระบบของคุณและตัววัดเฉพาะของ DB เพื่อให้สามารถค้นหาได้ว่าส่วนใดที่เป็นคอขวด

คุณต้องมีพื้นฐาน

ตรวจสอบให้แน่ใจเสมอว่าคุณมีตัวชี้วัดระบบพื้นฐานที่พร้อมให้แสดงเป็นภาพอย่างน้อยสองสามสัปดาห์ก่อน เครื่องมือมากมายให้สิ่งนี้ (Cacti, Munin, Graphite…ฯลฯ) เมื่อคุณรู้แล้วว่าเมตริกระบบใดที่คุณผูกไว้เป็นส่วนใหญ่ คุณจะต้องสร้างค่าพื้นฐานและค่าสูงสุด มิฉะนั้น การพิจารณาว่าปัญหาปัจจุบันของคุณเป็นแอปพลิเคชันใหม่ที่มีจุดบกพร่องหรือไม่ เทียบกับการเติบโตที่แท้จริง จะมีโอกาสเกิดข้อผิดพลาดมากกว่าที่คุณต้องการ

อย่างไรก็ตาม เมตริกเซิร์ฟเวอร์พื้นฐานสามารถทำได้จนถึงตอนนี้ ในบางจุดคุณจะพบว่าคุณต้องการเมตริกตามบริบทด้วย ประสิทธิภาพการสืบค้นข้อมูลและประสิทธิภาพการรับรู้ด้านแอปจะบอกคุณว่าแอปพลิเคชันมองเห็นอะไรเป็นเวลาตอบสนองต่อการสืบค้น มีเครื่องมือมากมายในการติดตามบริบทนี้อย่างหนักหน่วง บางตัวเป็นโอเพ่นซอร์สเช่นเครื่องวัดความเร็วลมและเครื่องมือเชิงพาณิชย์เช่น Vivid Cortex (เราใช้สิ่งเหล่านี้ที่ SendGrid ดูเราพูดถึงมันที่นี่) แม้แต่การติดตามตัวชี้วัดเหล่านี้จากมุมมองของแอพและโยนเป็นตัวชี้วัด statsd จะเป็นขั้นตอนแรกที่ดี แต่ก่อนอื่น คุณต้องชินกับความจริงที่ว่าสิ่งที่แอปของคุณรับรู้คือสิ่งที่ลูกค้าของคุณรับรู้ และต้องหาทางรู้ให้ได้ก่อน

เรียนรู้รูปแบบการเข้าชมธุรกิจของคุณ

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

กำหนดอัตราส่วนของจำนวนทราฟฟิกดิบที่สัมพันธ์กับความสามารถในการใช้งาน

นี่เป็นคำตอบง่ายๆ ว่า “ถ้าเราไม่ได้ทำการเพิ่มประสิทธิภาพโค้ด เราสามารถให้บริการอีเมล/การขาย/ผู้ใช้ออนไลน์/อะไรก็ตาม” กับอินสแตนซ์ฐานข้อมูลที่เรามีตอนนี้ได้กี่ฉบับ

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

ฉันจำเป็นต้องซื้อเครื่องจักรเพิ่มหรือไม่

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

คุณทำอย่างนั้นได้อย่างไร? คุณต้องทำความคุ้นเคยกับคำถามของคุณ ขั้นตอนแรกสำหรับสิ่งนั้นคือการผสมผสานระหว่าง innotop บันทึกช้า และ pt-query-digest ของ Percona Toolkit คุณสามารถทำให้สิ่งนี้เป็นอัตโนมัติโดยจัดส่งบันทึกฐานข้อมูลไปยังตำแหน่งศูนย์กลางและทำให้ส่วนไดเจสต์เป็นอัตโนมัติ

แต่นั่นไม่ใช่ภาพรวมเช่นกัน บันทึกที่ช้าจะเน้นประสิทธิภาพหากคุณลดขีดจำกัดมากเกินไป หากคุณใช้การสุ่มตัวอย่างแบบเลือกสรรได้น้อยกว่า คุณจะต้องตรวจหาการสนทนาทั้งหมดระหว่างแอปพลิเคชันและที่เก็บข้อมูล ในดินแดนโอเพ่นซอร์ส คุณสามารถใช้พื้นฐานอย่าง tcpdump หรือคุณสามารถใช้ผลิตภัณฑ์ที่โฮสต์ เช่น Datadog, New Relic หรือ VividCortex

ทำการโทร

การวางแผนกำลังการผลิตอาจเป็นวิทยาศาสตร์ 90% และศิลปะ 10% แต่นั่นไม่ได้หมายความว่าเราไม่ควรพยายามสร้างภาพให้มากที่สุดเท่าที่เราจะทำได้ 10% ในฐานะวิศวกร บางครั้งเราสามารถแก้ไข 10% ที่ขาดหายไป และไม่ทราบว่าหากเราทำงานนั้น 90% อาจทำให้เราเข้าใจถึงความสมบูรณ์ของสแต็กได้ดีขึ้น ใช้เวลาอย่างมีประสิทธิภาพมากขึ้นในการปรับประสิทธิภาพให้เหมาะสม และความสามารถในการวางแผน เพิ่มขึ้นอย่างระมัดระวังซึ่งจะส่งผลให้ผลตอบแทนการลงทุนสำหรับผลิตภัณฑ์ของเราดีขึ้นมาก