คีย์หลัก 5+ คอลัมน์ไม่ดีสำหรับตารางขนาดใหญ่ (100 ล้าน+) หรือไม่


12

ฉันกำลังอ่านเกี่ยวกับปัญหา DB ของชีวิตจริงและโครงการหนึ่งมี 100 ล้านแถวรวมตารางที่มีคอลัมน์ 5 คอลัมน์เป็นหลัก ฉันคิดว่านี่เป็นสิ่งที่ไม่ดี แต่ทุกคนสามารถบอกฉันได้ว่าทำไม

ตารางนั้นเป็นตารางการรวบรวม / การรวมขนาดเล็กดังนั้น 5 คอลัมน์จึงเป็นเช่น (วัน, market_id, product_id ... ) ตอนแรกฉันคิดว่าคีย์หลัก 5 คอลัมน์ไม่เหมาะ แต่ยิ่งฉันคิดฉันก็ไม่สามารถคิดหาเหตุผลที่ดีได้

นี่เป็นการสนทนาช่วงดึกกับวิศวกรของ บริษัท ครึ่งหนึ่ง มีคนพูดถึงเรื่องนี้ว่าเป็นการออกแบบที่ไม่ดีวิศวกรอาวุโสคนหนึ่งเห็นด้วย แต่ก็ไม่มีใครโดดขึ้นไปเลย ดังนั้นพยายามค้นคว้าเรื่องด้วยตัวเอง!


เป็นการดีที่คุณต้องการให้ PK มีขนาดค่อนข้างเล็ก - ใช้หน่วยความจำน้อยลง ด้วย PK 5 คอลัมน์มันจะมีค่าประมาณอย่างน้อยโดยอัตโนมัติ 5 INTs - เมื่อ 1 INT (auto_increment) อาจทำแทน
Vérace

คำตอบ:


9

มีปัญหาด้านประสิทธิภาพการทำงานกับคีย์หลักที่ซับซ้อนมาก และมันอาจไม่ได้รับการปกป้องจากการซ้ำซ้อนเช่นเดียวกับคีย์หลักที่เรียบง่าย

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

ฐานข้อมูลการรายงานบางตัวเลียนแบบรูปแบบของ schema ดาวแม้ว่าจะไม่ได้ออกแบบมาอย่างชัดเจนก็ตาม

100 ล้าน + แถวไม่ใหญ่เกินไปสำหรับตารางข้อเท็จจริงโดยเฉพาะกับข้อมูลขนาดใหญ่ในปัจจุบัน


2

ตารางที่ต้องสงสัยคือตารางการยกเลิก / การรวม

ถ้าอย่างนั้นก็ไม่เป็นไรหรอกมันคือ "สิทธิ"

dayและมันมีกลิ่นเหมือนตารางสรุปเพราะมันเริ่มต้นด้วย

คุณมีดัชนีรองบ้างไหม? โปรดทราบว่าหากคุณใช้ InnoDB คอลัมน์หลักที่เหลือจะถูกตรึงไว้ที่ส่วนท้ายของดัชนีรอง นี่ไม่ใช่ปัญหาอีกต่อไป

100M แถวเป็นจำนวนมากสำหรับการยกเลิก ดูเหมือนว่าตารางนั้นละเอียดเกินไป นั่นคือบางทีถ้า (date, a, b, c, d) คุณควรมี rollups 4 อันที่มี PKs เช่น (date, a, b, c), (date, b, c, d), (date, c, d, a), (วันที่, d, a, b) (หรือชุดค่าผสมที่เหมาะสม) ฉันทำอย่างนั้นแต่ละแถวอาจมีเพียง 10M แถวเท่านั้นจึงทำให้รายงานยังเร็วขึ้นในขณะที่มีความยืดหยุ่นในรายงานเกือบเท่ากัน

หรืออาจเปลี่ยนเป็น (สัปดาห์, a, b, c, d) อาจนำไปสู่แถว 14M เท่านั้น (อาจเป็นไปได้มากกว่านี้)

ใช้พาร์ติชั่เพื่ออำนวยความสะดวกการตัดแต่งกิ่ง --- การส่งผ่านข้อมูลความเร็วสูง --- เคล็ดลับคลังข้อมูล --- ตารางสรุป สรุปเทคนิคต่าง ๆ ที่ฉันได้พัฒนาในโครงการ DW หลายโครงการ ในขณะที่คุณอาจสรุปแต่ละโครงการจะแตกต่างกัน จำนวนสรุปตารางทั่วไป (ในประสบการณ์ของฉัน) คือ 3-7 เป้าหมายในการสรุปคือ 10 แถวข้อเท็จจริง -> 1 แถวสรุป (นั่นอาจเป็น 'ค่ามัธยฐาน') ในกรณีที่หายากฉันสรุปตารางสรุป ในกรณีที่หายากอื่นฉันแบ่งตารางสรุปให้มีผลดี โดยปกติแล้วตารางสรุปมีขนาดเล็กเพียงพอดังนั้นจึงเร็วพอสำหรับการเข้าถึงโดยตรงจาก UI


1

ที่จริงแล้วการมี PK พร้อมกับ 5+ คอลัมน์นั้นไม่ได้เลวร้ายไปเสีย

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

มันจะไม่ดีเมื่อคุณใช้ PK โดย FK อื่นจริงเพราะคุณต้องมีข้อมูลของคอลัมน์ทั้งหมด 5+ ทั้งในตารางปัจจุบันและที่อ้างอิงจาก อีกครั้งมันจะเพิ่มการจัดเก็บมากขึ้น!

ประสิทธิภาพการทำงานจะไม่ดีเมื่อใช้ PK เป็นดัชนี - อนุญาตให้อยู่ภายในตารางหรือใช้ร่วมกับ FK เพียงอย่างเดียวในฐานะที่เป็น PK-Key ที่ใหญ่กว่าที่มี 5+ คอลัมน์จะใช้พื้นที่มากขึ้นดังนั้นรายการที่น้อยลงจะ พอดีภายในหน้าและต่อจากนี้ไปหน้าจะต้องอ่านเพื่อวิเคราะห์ดัชนี

ที่กล่าวว่า - อาจมีเหตุผลที่ดีสำหรับการทำเช่นนั้นจริง ๆ เสมอเช่นเช่นตารางความจริง ดังนั้นคำตอบที่ดีที่สุดน่าจะเป็นจริงในกรณีส่วนใหญ่: ขึ้นอยู่กับ!

ขอแสดงความนับถือเดนนิส


-2

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

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

สรุปสั้น ๆ คีย์หลักซิน ธ ติก (การเพิ่มอัตโนมัติ guid, .. ) นั้นง่ายต่อการบำรุงรักษาคัดลอก ...

ดังนั้นฉันจึงพิจารณากุญแจหลักซินดิเคทและอีกหนึ่งคีย์สำหรับ 5 คอลัมน์ที่คุณพูดถึง

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

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.