ฐานข้อมูล MySQL เริ่มต้นที่จุดใดเสียประสิทธิภาพ?
ฉันมีสิ่งที่ฉันเชื่อว่าเป็นฐานข้อมูลขนาดใหญ่ที่มีระเบียนประมาณ 15 ล้านรายการซึ่งใช้เวลาเกือบ 2GB จากตัวเลขเหล่านี้มีแรงจูงใจให้ฉันล้างข้อมูลออกหรือไม่หรือฉันปลอดภัยที่จะอนุญาตให้ปรับขนาดต่อไปอีกสองสามปี
คำตอบ:
ขนาดฐานข้อมูลจริงไม่สำคัญ จำนวนระเบียนไม่สำคัญ
จากประสบการณ์ของฉันปัญหาที่ใหญ่ที่สุดที่คุณกำลังจะเรียกใช้ไม่ใช่ขนาด แต่จำนวนคิวรีที่คุณสามารถจัดการได้ในแต่ละครั้ง เป็นไปได้มากที่คุณจะต้องย้ายไปที่การตั้งค่าหลัก / สลาฟเพื่อให้เคียวรีการอ่านสามารถรันกับทาสและเคียวรีการเขียนรันกับต้นแบบ อย่างไรก็ตามหากคุณยังไม่พร้อมสำหรับสิ่งนี้คุณสามารถปรับแต่งดัชนีของคุณสำหรับการสืบค้นที่คุณใช้เพื่อเพิ่มความเร็วในเวลาตอบสนอง นอกจากนี้ยังมีการปรับแต่งมากมายที่คุณสามารถทำได้กับเครือข่ายสแต็คและเคอร์เนลใน Linux ที่จะช่วย
ฉันมีจำนวนเพิ่มขึ้นถึง 10GB ด้วยจำนวนการเชื่อมต่อที่พอเหมาะและจัดการคำขอได้ดี
ฉันจะมุ่งเน้นที่ดัชนีของคุณก่อนจากนั้นให้ผู้ดูแลเซิร์ฟเวอร์ดูระบบปฏิบัติการของคุณและหากสิ่งที่ไม่ได้ช่วยอาจถึงเวลาที่จะต้องใช้การกำหนดค่าหลัก / ทาส
โดยทั่วไปแล้วนี่เป็นปัญหาที่ละเอียดอ่อนมากและไม่น่ารำคาญเลย ผมแนะนำให้คุณอ่านmysqlperformanceblog.comและHigh Performance MySQL ฉันคิดว่าไม่มีคำตอบทั่วไปสำหรับเรื่องนี้
ฉันกำลังทำงานในโครงการที่มีฐานข้อมูล MySQL ที่มีข้อมูลเกือบ 1TB ปัจจัยความยืดหยุ่นที่สำคัญที่สุดคือ RAM หากดัชนีของตารางของคุณพอดีกับหน่วยความจำและข้อความค้นหาของคุณได้รับการปรับแต่งอย่างเหมาะสมคุณสามารถให้บริการคำขอในปริมาณที่เหมาะสมด้วยเครื่องเฉลี่ย
จำนวนระเบียนมีความสำคัญขึ้นอยู่กับลักษณะตารางของคุณ เป็นความแตกต่างที่จะมีเขตข้อมูล varchar จำนวนมากหรือมีเพียงสองสาม ints หรือ longs
ขนาดฟิสิคัลของฐานข้อมูลมีความสำคัญเช่นลองคิดถึงการสำรองข้อมูล ขึ้นอยู่กับเอ็นจิ้นของคุณไฟล์ db แบบฟิสิคัลของคุณจะเพิ่มขึ้น แต่อย่าย่อขนาดลงเช่น innodb ดังนั้นการลบแถวจำนวนมากไม่ช่วยลดขนาดไฟล์จริงของคุณ
มีปัญหามากมายในเรื่องนี้และในหลาย ๆ กรณีมารอยู่ในรายละเอียด
ขนาดฐานข้อมูลไม่ก็ตาม หากคุณมีมากกว่าหนึ่งตารางที่มีมากกว่าหนึ่งล้านระเบียนแล้วประสิทธิภาพจะเริ่มลดลงแน่นอน จำนวนของระเบียนที่ไม่แน่นอนส่งผลกระทบต่อประสิทธิภาพการทำงาน: MySQL ได้ช้ากับตารางที่มีขนาดใหญ่ หากคุณมีข้อมูลถึงหนึ่งล้านรายการคุณจะได้รับปัญหาประสิทธิภาพหากดัชนีไม่ถูกต้อง (ตัวอย่างเช่นไม่มีดัชนีสำหรับฟิลด์ใน "คำสั่ง WHERE" หรือ "ON เงื่อนไข" เข้าร่วม) หากคุณทำสถิติถึง 10 ล้านครั้งคุณจะเริ่มพบปัญหาด้านประสิทธิภาพแม้ว่าคุณจะมีดัชนีทั้งหมดแล้ว การอัพเกรดฮาร์ดแวร์ - การเพิ่มหน่วยความจำมากขึ้นและพลังประมวลผลที่มากขึ้นโดยเฉพาะอย่างยิ่งหน่วยความจำมักจะช่วยลดปัญหาที่ร้ายแรงที่สุดด้วยการเพิ่มประสิทธิภาพอีกครั้งอย่างน้อยในระดับหนึ่ง ตัวอย่างเช่น37 สัญญาณจาก 32 GB RAM เป็น 128GB ของ RAMสำหรับเซิร์ฟเวอร์ฐานข้อมูล Basecamp
ฉันจะมุ่งเน้นไปที่ดัชนีของคุณเป็นอันดับแรกกว่าให้ผู้ดูแลเซิร์ฟเวอร์ดูระบบปฏิบัติการของคุณและหากสิ่งที่ไม่ได้ช่วยอาจเป็นเวลาสำหรับการกำหนดค่าหลัก / ทาส
นั่นเป็นเรื่องจริง สิ่งอื่นที่ใช้งานได้คือเพียงลดปริมาณข้อมูลที่ทำงานซ้ำ ๆ หากคุณมี "ข้อมูลเก่า" และ "ข้อมูลใหม่" และ 99% ของแบบสอบถามของคุณทำงานกับข้อมูลใหม่เพียงแค่ย้ายข้อมูลเก่าทั้งหมดไปยังตารางอื่น - และอย่ามองมัน;)
2GB และประมาณ 15M เร็กคอร์ดเป็นฐานข้อมูลขนาดเล็กมาก - ฉันรันที่ใหญ่กว่าบน pentium III (!) และทุกอย่างยังคงทำงานได้ค่อนข้างเร็ว .. หากคุณช้าก็เป็นปัญหาการออกแบบฐานข้อมูล / แอปพลิเคชันไม่ใช่ mysql หนึ่ง.
มันไม่มีประโยชน์ที่จะพูดถึง "ประสิทธิภาพของฐานข้อมูล", "ประสิทธิภาพการค้นหา" เป็นคำที่ดีกว่าที่นี่ และคำตอบคือ: ขึ้นอยู่กับการสืบค้นข้อมูลที่ทำงานบนดัชนีฮาร์ดแวร์ ฯลฯ คุณสามารถทราบได้ว่าจะสแกนแถวกี่แถวและดัชนีใดที่จะใช้กับไวยากรณ์ EXPLAIN
2GB ไม่นับเป็นฐานข้อมูล "ใหญ่" จริง ๆ แต่มีขนาดกลางมากกว่า
ขณะนี้ฉันกำลังจัดการฐานข้อมูล MySQL บนโครงสร้างพื้นฐานคลาวด์ของ Amazon ที่เพิ่มขึ้นเป็น 160 GB ประสิทธิภาพของคำค้นหาดี สิ่งที่กลายเป็นฝันร้ายคือการสำรองข้อมูลการคืนค่าการเพิ่มทาสหรือสิ่งอื่นใดที่เกี่ยวข้องกับชุดข้อมูลทั้งหมดหรือแม้แต่ DDL ในตารางขนาดใหญ่ การได้รับการนำเข้าที่สะอาดของไฟล์ดัมพ์นั้นเป็นปัญหา เพื่อให้กระบวนการมีเสถียรภาพเพียงพอที่จะทำให้เป็นอัตโนมัติตัวเลือกต่าง ๆ ที่จำเป็นในการจัดลำดับความสำคัญของความเสถียรเหนือประสิทธิภาพ หากเราต้องกู้คืนจากความเสียหายโดยใช้การสำรองข้อมูล SQL เราจะหยุดทำงานหลายวัน
การปรับขนาด SQL ในแนวนอนนั้นค่อนข้างเจ็บปวดและในกรณีส่วนใหญ่นำไปสู่การใช้งานในลักษณะที่คุณอาจไม่ได้ตั้งใจเมื่อคุณเลือกที่จะใส่ข้อมูลของคุณใน SQL ตั้งแต่แรก Shards, อ่านทาส, multi-master, และอื่น ๆ , พวกเขาทั้งหมดเป็นโซลูชั่นที่น่าอับอายจริงๆที่เพิ่มความซับซ้อนให้กับทุกสิ่งที่คุณเคยทำกับฐานข้อมูลและไม่ใช่หนึ่งในนั้นแก้ปัญหา; เพียงบรรเทามันในบางวิธี ฉันขอแนะนำอย่างยิ่งให้มองการย้ายข้อมูลบางส่วนของคุณออกจาก MySQL (หรือ SQL ใด ๆ จริงๆ) เมื่อคุณเริ่มเข้าใกล้ชุดข้อมูลขนาดที่สิ่งเหล่านี้กลายเป็นปัญหา
ระวังตัวเชื่อมที่ซับซ้อนด้วย ความซับซ้อนของการทำธุรกรรมอาจเป็นปัจจัยใหญ่นอกเหนือจากปริมาณธุรกรรม
การปรับโครงสร้างการสืบค้นที่หนักหนาสาหัสบางครั้งการเพิ่มประสิทธิภาพครั้งใหญ่
ฉันเคยถูกเรียกให้ดู mysql ที่ "หยุดทำงาน" ฉันค้นพบว่าไฟล์ฐานข้อมูลอยู่ในไฟล์ Network Appliance ที่ติดตั้งด้วย NFS2 และมีขนาดไฟล์สูงสุด 2GB และแน่นอนว่าตารางที่หยุดการยอมรับการทำธุรกรรมนั้นมีขนาด 2GB บนดิสก์ แต่สำหรับเส้นโค้งการแสดงฉันบอกว่ามันทำงานเหมือนแชมป์จนกระทั่งมันไม่ทำงานเลย! ประสบการณ์นี้ให้บริการสำหรับฉันเสมอเป็นเครื่องเตือนใจที่ดีว่ามีมิติด้านบนและด้านล่างที่คุณสงสัยตามธรรมชาติอยู่เสมอ
ประเด็นที่ต้องพิจารณาก็คือจุดประสงค์ของระบบและข้อมูลในแต่ละวัน
ตัวอย่างเช่นสำหรับระบบที่มีการตรวจสอบ GPS ของรถยนต์ไม่ใช่ข้อมูลการค้นหาที่เกี่ยวข้องจากตำแหน่งของรถในเดือนก่อนหน้า
ดังนั้นข้อมูลสามารถส่งผ่านไปยังตารางประวัติอื่น ๆ เพื่อขอคำปรึกษาที่เป็นไปได้และลดเวลาดำเนินการของแบบสอบถามแบบวันต่อวัน
ประสิทธิภาพสามารถลดลงในไม่กี่พันแถวหากฐานข้อมูลไม่ได้ออกแบบอย่างเหมาะสม
หากคุณมีดัชนีที่เหมาะสมให้ใช้เอ็นจินที่เหมาะสม (อย่าใช้ MyISAM ที่คาดว่าจะมี DML หลายตัว) ใช้การแบ่งพาร์ติชันจัดสรรหน่วยความจำที่ถูกต้องขึ้นอยู่กับการใช้งานและแน่นอนว่ามีการกำหนดค่าเซิร์ฟเวอร์ที่ดี MySQL สามารถจัดการข้อมูลได้
มีวิธีการปรับปรุงประสิทธิภาพของฐานข้อมูลอยู่เสมอ
ขึ้นอยู่กับการสอบถามและการตรวจสอบของคุณ
ตัวอย่างเช่นฉันทำงานกับตารางของยา 100,000 รายการซึ่งมีชื่อสามัญคอลัมน์ที่มีมากกว่า 15 อักขระสำหรับแต่ละยาเสพติดในตารางนั้นฉันใส่แบบสอบถามเพื่อเปรียบเทียบชื่อสามัญของยาระหว่างสองตารางแบบสอบถามใช้เวลา ใช้เวลาในการทำงานนานขึ้นเช่นเดียวกันหากคุณเปรียบเทียบยาเสพติดโดยใช้ดัชนียาเสพติดโดยใช้คอลัมน์ id (ดังที่กล่าวข้างต้น) จะใช้เวลาเพียงไม่กี่วินาที
ขนาดฐานข้อมูลสำคัญในเรื่องของจำนวนไบต์และจำนวนแถวของตาราง คุณจะสังเกตเห็นความแตกต่างของประสิทธิภาพอย่างมากระหว่างฐานข้อมูลแบบเบาและแบบหยด เมื่อแอปพลิเคชันของฉันติดขัดเพราะฉันใส่อิมเมจไบนารีลงในฟิลด์แทนที่จะเก็บภาพไว้ในไฟล์บนดิสก์และใส่เฉพาะชื่อไฟล์ในฐานข้อมูล การทำซ้ำแถวจำนวนมากในทางกลับกันนั้นไม่ได้ฟรี
ไม่ไม่สำคัญหรอก ความเร็ว MySQL มีประมาณ 7 ล้านแถวต่อวินาที ดังนั้นคุณสามารถปรับขนาดได้เล็กน้อย
ประสิทธิภาพของแบบสอบถามส่วนใหญ่ขึ้นอยู่กับจำนวนระเบียนที่ต้องการสแกนดัชนีมีบทบาทสูงและขนาดข้อมูลดัชนีเป็นสัดส่วนกับจำนวนแถวและจำนวนดัชนี
ข้อความค้นหาที่มีเงื่อนไขฟิลด์ที่ทำดัชนีพร้อมกับค่าเต็มจะถูกส่งกลับใน 1ms โดยทั่วไป แต่ starts_with, IN, Between, มีเงื่อนไขที่ชัดเจนอาจใช้เวลามากขึ้นในการสแกนมากกว่า
นอกจากนี้คุณจะต้องเผชิญกับปัญหาการบำรุงรักษามากมายด้วย DDL เช่น ALTER, DROP จะช้าและยากขึ้นกับการรับส่งข้อมูลสดมากขึ้นแม้จะเพิ่มดัชนีหรือคอลัมน์ใหม่
โดยทั่วไปจะแนะนำให้จัดกลุ่มฐานข้อมูลเป็นกลุ่มตามที่ต้องการ (500GB จะเป็นเกณฑ์มาตรฐานทั่วไปตามที่กล่าวโดยผู้อื่นขึ้นอยู่กับปัจจัยหลายอย่างและอาจแตกต่างกันไปตามกรณีการใช้งาน) วิธีที่ทำให้แยกได้ดีขึ้น กลุ่ม (เหมาะกว่าในกรณีของ B2B)