เซิร์ฟเวอร์ mysql สามารถเลือกได้กี่ตัวต่อวินาที

ฉันเขียนแผนธุรกิจและต้องจำลองต้นทุนเมื่อเว็บไซต์ของฉันเข้าถึงได้จากผู้เข้าชมที่ไม่ซ้ำกัน 500,000 คน

• ผู้เยี่ยมชม: 500.000
• จำนวนหน้าที่มีการเปิด: 1,500,000
• จำนวนหน้าที่มีการเปิด Spider: 500,000
• จำนวนหน้าที่มีการเปิดทั้งหมด: 2,000,000

แต่ละหน้ามี 50 คำค้นหา + -

• ข้อความค้นหาต่อวัน: 100 ล้าน
• ต่อชั่วโมง: 4 ล้าน
• ต่อนาที: 70,000
• ต่อวินาที: 1,200
• สูงสุด: 3,000

ทำการคำนวณนี้ฉันต้องการ 3,000 คิวรีที่สอง ... เซิร์ฟเวอร์ประเภทใดที่สามารถจัดการได้?

ปัญหาคือ: จริง ๆ แล้วเว็บไซต์ของฉันมีการเข้าชม 2,000 วันและมี - + 150/200 ข้อความค้นหา / วินาที ... เริ่มจากจุดนี้ฉันจะได้รับข้อความค้นหา 50,000 ข้อความ / วินาที

ฉันต้องการเซิร์ฟเวอร์จำนวนมากในคลัสเตอร์หรือการจำลองแบบที่จัดการงานนี้

ฉันเคยทำงานให้กับ บริษัท อีคอมเมิร์ซด้วยเว็บไซต์ที่มีการเข้าชมหลายล้านครั้งต่อวัน เรามี DELL PE 1750 หนึ่งตัวพร้อมซีพียูหลัก 2 ตัวและ RAM 2GB ขนาดฐานข้อมูลประมาณ 4 กิกะไบต์. ในช่วงเวลาเร่งด่วนเซิร์ฟเวอร์นี้จัดการได้ถึง 50k + ข้อความค้นหาต่อวินาที

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

จากประสบการณ์นั้นฉันสามารถบอกคุณได้ว่าผลกระทบสูงสุดเกิดจากดัชนีที่ขาดหายไปดัชนีผิดและการออกแบบฐานข้อมูลไม่ดี (เช่นฟิลด์สตริงยาวเป็นคีย์หลักและไร้สาระคล้ายกัน)

ทุกอย่างขึ้นอยู่กับความซับซ้อนของการสืบค้นและจำนวนหน่วยความจำที่เซิร์ฟเวอร์มีและความรวดเร็วของดิสก์

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

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

เลือกง่ายในคอลัมน์ที่จัดทำดัชนีค่อนข้างสัตว์ที่แตกต่างจากคู่ของเข้าร่วมตามคนที่ไม่ได้จัดทำดัชนี ... และแน่นอนสิ่งที่เปลี่ยนแปลงมากถ้าตารางที่เกี่ยวข้องมี 1K บันทึกหรือ 1M

นอกจากนี้:

• การกำหนดค่าฮาร์ดแวร์ปัจจุบันของคุณคืออะไร
• เซิร์ฟเวอร์ของคุณใช้พลังงานเท่าใด (CPU, RAM, Disk I / O) ภายใต้โหลดปัจจุบัน

ดังที่อิกนาชิโอกล่าวไว้คุณอาจต้องการดูแคช ในหน่วยเซนติเมตรหรือแม้กระทั่งด้านหน้าของสแต็ก 50+ ข้อความค้นหาสำหรับทุก ๆ หน้า (ทุก ๆ !) มีจำนวนมากอย่างแท้จริง

ตัดสินจากความคิดเห็นของคุณปัจจัยที่ใหญ่ที่สุดคือขนาดชุดข้อมูลของคุณหรืออย่างน้อยขนาดชุดข้อมูล "ร้อน" 3,000qps หรือแม้กระทั่ง 8,000qps บนเซิร์ฟเวอร์ 16-core ไม่ได้เป็นปัญหาตราบใดที่เซิร์ฟเวอร์ไม่ค่อยต้องไปที่ดิสก์เพื่อตอบสนองการค้นหา เมื่อชุดข้อมูลที่ใช้งานเกินจำนวนหน่วยความจำที่ InnoDB ใช้ในการแคชประสิทธิภาพของคุณจะลดลงอย่างรวดเร็ว

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

มีหลายสิ่งมากเกินไปที่สามารถส่งผลต่อข้อความค้นหาของคุณต่อวินาทีได้โปรดอย่าเชื่อถือข้อมูลของฉันโดยไม่ทำการทดสอบตัวเอง ฉันโพสต์ผลการทดสอบความเร็วของฉันที่นี่เพื่อช่วยให้ใครบางคนประเมิน qps กับฐานข้อมูล mysql และเครื่องปัจจุบัน (2018-09) ในการทดสอบของฉันขนาดข้อมูลน้อยกว่าหน่วยความจำเซิร์ฟเวอร์ (ที่ลด IO ลงอย่างมากและเพิ่มประสิทธิภาพได้มาก)

ฉันใช้หน่วยความจำ 3.75GB หนึ่ง cpu, ssd 100GB, gcp cloud mysql เช่นเซิร์ฟเวอร์และรับ:

• ลูกค้า 1 รายอ่านหนึ่งตารางฟุตหนึ่งตารางเมตร: 799 ตารางเมตร / วินาที
• ลูกค้า 50 รายอ่านได้หนึ่งแถวจาก sql หนึ่งแถว: 6403 sql / วินาที
• ลูกค้า 50 รายเขียนหนึ่งตาราง sql: 4341 แถวเขียน, qps 4341 sql / วินาที
• ลูกค้า 1 รายเขียน 30k แถวต่อ sql: 92109 แถวที่เขียน