การแบ่งพาร์ติชันตารางช่วยได้อย่างไร


28

ฉันมีปัญหาในการคว้าความคิดของข้อดีและข้อเสียของการแบ่งตาราง ฉันกำลังจะเริ่มทำงานในโครงการซึ่งจะมี 8 ตารางและหนึ่งในนั้นจะเป็นตารางข้อมูลหลักที่จะเก็บบันทึก 180-260 ล้าน เนื่องจากมันจะถูกทำดัชนีตารางอย่างถูกต้องดังนั้นฉันคิดว่าการ จำกัด ระเบียนของตารางไว้ที่ 20 ล้านด้วยวิธีนี้ฉันจะต้องสร้างตาราง 9-13

แต่ฉันไม่แน่ใจว่ามันจะปรับปรุงประสิทธิภาพได้อย่างไรเพราะพวกเขาจะนั่งอยู่บนเครื่องเดียวกัน (32GB RAM)?

ฉันใช้ MySQL และตารางจะเป็น MyISAM และตารางใหญ่จะมีดัชนีในฟิลด์ id และไม่มีความซับซ้อนเพิ่มเติมเช่นการค้นหาข้อความแบบเต็มเป็นต้น

โปรดแสดงการแบ่งตารางเทียบกับการแบ่งพาร์ติชันฐานข้อมูลด้วย


โปรดอธิบายประเภทของการค้นหาที่จัดทำดัชนีไว้ที่จะดำเนินการกับตารางอื่นที่ไม่ใช่ id มันจะบอกคุณเกี่ยวกับประเภทของการแบ่งพาร์ติชันที่จะทำ
RolandoMySQLDBA

มันจะเป็นเพียง ID
Rick James

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

1
นี่ คือความรู้สึกของฉัน 5 ปีหลังจากเริ่มหัวข้อนี้
Rick James

คำตอบ:


32

ต่อไปนี้เป็นเพียงการพูดจาวิกลจริตและเพ้อ ...

หากคุณปล่อยให้ข้อมูลทั้งหมดไว้ในตารางเดียว (ไม่มีการแบ่งพาร์ติชัน) คุณจะมีเวลาค้นหา O (บันทึก n) โดยใช้ปุ่ม ลองหาดัชนีที่แย่ที่สุดในโลกต้นไม้ไบนารี โหนดต้นไม้แต่ละโหนดมีคีย์เดียว ต้นไม้ไบนารีที่สมดุลอย่างสมบูรณ์กับโหนดต้นไม้ 268,435,455 (2 ^ 28 - 1) จะมีความสูง 28 ถ้าคุณแบ่งต้นไม้ไบนารีนี้เป็นต้นไม้แยก 16 ต้นคุณจะได้รับ 16 ต้นไม้ 16,777,215 (2 ^ 24 - 1) แผนภูมิต้นไม้สำหรับความสูง 24 เส้นทางการค้นหาจะลดลง 4 โหนดลดความสูง 14.2857% หากเวลาค้นหาเป็นไมโครวินาทีเวลาในการค้นหาที่ลดลง 14.2857% จะไม่สามารถเพิกเฉยได้

ในโลกแห่งความเป็นจริงดัชนี BTREE จะมี treenode ที่มีปุ่มหลายปุ่ม การค้นหา BTREE แต่ละครั้งจะทำการค้นหาแบบไบนารีภายในหน้าเว็บด้วยความเป็นไปได้ที่เหมาะสมในหน้าอื่น ตัวอย่างเช่นหากแต่ละหน้า BTREE มี 1024 ปุ่มความสูงของต้นไม้ 3 หรือ 4 จะเป็นบรรทัดฐานความสูงต้นไม้สั้นแน่นอน

โปรดสังเกตว่าการแบ่งส่วนของตารางไม่ลดความสูงของ BTREE ซึ่งมีขนาดเล็กอยู่แล้ว ด้วยการแบ่งแถว 260 ล้านแถวมีความเป็นไปได้สูงที่จะมีหลาย BTREE ที่มีความสูงเท่ากัน การค้นหาคีย์อาจผ่านเพจ BTREE รูททั้งหมดทุกครั้ง เพียงอันเดียวเท่านั้นที่จะเติมเต็มเส้นทางของช่วงการค้นหาที่ต้องการ

ตอนนี้ขยายตัวในสิ่งนี้ พาร์ติชันทั้งหมดมีอยู่ในเครื่องเดียวกัน หากคุณไม่มีดิสก์แยกสำหรับแต่ละพาร์ติชันคุณจะมีดิสก์ I / O และแกนหมุนเป็นคอขวดอัตโนมัตินอกประสิทธิภาพการค้นหาพาร์ติชัน

ในกรณีนี้การแบ่งพาร์ทิชันด้วยฐานข้อมูลจะไม่ซื้ออะไรเลยถ้า id เป็นคีย์การค้นหาเดียวที่ถูกใช้งาน

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

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


16

200 ล้านแถวอยู่ในช่วงที่คุณจะได้ประโยชน์จากการแบ่งตาราง ขึ้นอยู่กับใบสมัครของคุณคุณสามารถเดิมพันผลประโยชน์บางส่วนที่ระบุด้านล่าง:

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

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

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

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

สำหรับวัตถุประสงค์ในการแบ่งพาร์ติชันของ OP นั้นไม่น่าจะได้รับประโยชน์ด้านประสิทธิภาพมากนักสำหรับการดำเนินการค้นหา แต่อาจมีประโยชน์สำหรับการจัดการระบบ หากมีความต้องการที่สำคัญใด ๆ ในการรายงานการรวมข้ามข้อมูลจำนวนมากดังนั้นรูปแบบการแบ่งพาร์ติชั่นที่เหมาะสมอาจช่วยได้


1

การแบ่งพาร์ติชั่นอนุญาตให้ทำการวนซ้ำพร้อมกันโดยพาร์ติชั่นถ้าดัชนีทั้งหมดของคุณถูกแบ่งพาร์ติชัน ถ้าไม่พาร์ติชันยังคงมีขนาดเล็กกว่ามากและใช้พื้นที่ทำงานน้อยลงในการเริ่มต้นใหม่ และภายใน DBMS "ดี" ใด ๆ สามารถทำสิ่งต่าง ๆ พร้อมกับตารางแบ่งพาร์ติชัน มีแนวโน้มว่าจะไม่รวม MySQL หรือ MyISAM แม้ว่า ....


MySQL ไม่มีการประมวลผลแบบขนานแม้ว่าจะเกี่ยวข้องกับการแบ่งพาร์ติชันก็ตาม ดัชนี MySQL มีเพียงพาร์ติชั่นเดียว; ดังนั้นUNIQUEและFOREIGN KEYจะไม่สามารถใช้งานได้จริงในตารางที่แบ่งพาร์ติชัน การแบ่งพาร์ติชันบน MyISAM กับ InnoDB - ไม่ต่างกับส่วนที่กล่าวถึงในหัวข้อนี้
Rick James
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.