นี่คือกึ่งสมมุติและเนื่องจากฉันไม่เคยมีประสบการณ์ในการจัดการกับตารางฐานข้อมูลขนาดใหญ่ฉันจึงไม่ทราบว่ามันน่ากลัวด้วยเหตุผลบางประการ ตามสถานการณ์:
ลองนึกภาพแอปพลิเคชันบนเว็บ - สมมติว่าซอฟต์แวร์บัญชีซึ่งมีลูกค้า 20,000 รายและลูกค้าแต่ละรายมีรายการมากกว่า 1,000 รายการในตาราง นั่นคือ 20 ล้านแถวซึ่งฉันรู้ว่าสามารถชะลอการค้นหาที่ซับซ้อนได้อย่างแน่นอน
ในกรณีเช่นนี้การสร้างตารางใหม่ในฐานข้อมูลสำหรับไคลเอ็นต์แต่ละเครื่องเหมาะสมหรือไม่ ฐานข้อมูลมีปฏิกิริยาอย่างไรกับการมีตารางขนาด 20k (หรือมากกว่านั้น)?
คำตอบ:
โดยทั่วไปแล้วไม่มันไม่มีเหตุผลที่จะมีตาราง (ฉันคิดว่าคุณหมายถึงฐานข้อมูลจริงที่นี่) ต่อลูกค้า 20 ล้านแถวค่อนข้างเล็กสำหรับตารางฐานข้อมูล ความเร็วในการค้นหาที่ไม่น่าจะเป็นปัญหาตราบใดที่ฐานข้อมูลนั้นได้รับการปรับอย่างเหมาะสม (จัดทำดัชนี) และแบบสอบถามจะรวมกันอย่างถูกต้อง สิ่งที่เป็นประโยชน์คุณคิดว่าคุณจะได้รับจากการแยกพวกเขาจะถูกชดเชยด้วยความซับซ้อนเพิ่มเติมของการจัดการฐานข้อมูล 20,000 ราย ตัวอย่างเช่นจะเกิดอะไรขึ้นเมื่อคุณต้องการเปลี่ยนโครงสร้างตาราง ตอนนี้คุณต้องทำ 20,000 ครั้ง!
กรณีที่เลวร้ายยิ่งกว่านั้นหากคุณพบว่าขนาดฐานข้อมูลกำลังเป็นปัญหาคุณสามารถแยกขนาดออกเป็นฐานข้อมูลแยกต่างหากในภายหลัง
ฟังดูเหมือนเป็นไอเดียที่ไม่ดี
อย่าพยายามที่จะเอาชนะฐานข้อมูลด้วยการสร้างที่แปลกใหม่เช่นนี้ เอ็นจิ้นฐานข้อมูลได้รับการออกแบบพร้อมการปรับแต่งมากมายเพื่อรองรับชุดข้อมูลขนาดใหญ่ ตัวอย่างเช่นสิ่งที่คุณกำลังอธิบายเสียงใกล้เคียงกับความพยายามในการใช้ดัชนีด้วยตนเอง เพียงใช้ดัชนีที่จัดทำโดย DB Engine พวกมันจะถูกนำไปใช้งานได้ดีกว่าที่คุณคาดว่าจะสามารถทำได้ด้วยตัวคุณเองและไม่จำเป็นต้องบำรุงรักษามากนัก
นอกจากนี้ยังเป็นกฎทั่วไปของหัวแม่มือ ฉันขอแนะนำไม่ให้สร้างฐานข้อมูลในลักษณะที่ต้องมีการจัดการหรือสร้างโครงสร้างฐานข้อมูล (ตารางเขตข้อมูล) ระหว่างการใช้งานแอปพลิเคชันตามปกติ มันทำให้การเพิ่มประสิทธิภาพสำหรับหมีและมักจะบังคับให้คุณให้สิทธิ์แก่ผู้ใช้มากเกินไปในการทำงานประจำที่อาจสร้างช่องโหว่ด้านความปลอดภัย
นี่คือบทความที่ฉันมักจะกระตุ้นให้คนอ่านเมื่อพวกเขาถามคำถามนี้:
http://datacharmer.blogspot.com/2009/03/normalization-and-smoking.html
IMHO ตารางเดียวไม่ควรมีปัญหาดังนั้นอย่าสร้างปัญหาที่ไม่มีอยู่ - มีหลายสิ่งที่คุณสามารถทำได้เพื่อช่วยในการแสดง คุณสามารถแบ่งพาร์ติชันตารางเดียวเป็นหลาย ๆ ไฟล์ตาม clientID หรือฟิลด์ date เพื่อช่วยในการ IO db ของคุณไม่จำเป็นต้องติดตามเพิ่มประสิทธิภาพและแคชงบ SQL ที่แตกต่างกัน 20,000 คำสำหรับทุกข้อความค้นหาที่คุณต้องการ คุณสามารถสร้างดัชนีโดยรหัสลูกค้า ลูกค้า 20K สามารถชำระค่าฮาร์ดแวร์ได้จำนวนมาก
สำหรับตารางประเภทนี้สามารถใช้ NoSQL type db ได้
ด้วยไคลเอนต์ 20K ฐานข้อมูลอาจไม่ใช่จุดอ่อนที่สุดของคุณดังนั้นทำไมจึงแนะนำความซับซ้อนนี้มาก
นั่นเป็นวิธีที่ไม่ดีจริงๆ
แบ่งพาร์ติชันตารางในแนวตั้งเซิร์ฟเวอร์ฐานข้อมูล 2 เซิร์ฟเวอร์หนึ่งเซิร์ฟเวอร์สำหรับรหัสผู้ใช้แปลกและอีกเซิร์ฟเวอร์ควรทำงานได้ดี (ข้อมูลไม่เกี่ยวข้องกันระหว่างผู้ใช้)
จัดเรียงข้อมูลตาม user_id และหากเป็นไปไม่ได้จะได้รับดิสก์ RAM หรือ SSD จำนวนมาก