การแบ่งฐานข้อมูลและการแบ่งพาร์ติชัน


166

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

ผู้เชี่ยวชาญที่ stackoverflow ช่วยฉันได้พื้นฐานใช่มั้ย

  • ความแตกต่างระหว่างคืออะไรshardingและแบ่งพาร์ทิชัน ?
  • มันเป็นความจริงว่า'ฐานข้อมูล sharded ทั้งหมดจะถูกแบ่งพาร์ติชันหลัก (มากกว่าโหนดที่แตกต่างกัน) แต่ฐานข้อมูลแบ่งพาร์ติชันทั้งหมดจะไม่จำเป็นต้อง sharded' ?

digitalocean.com/community/tutorials/…นี่อาจช่วยได้
mchawre

คำตอบ:


130

การแบ่งเป็นคำทั่วไปสำหรับการแบ่งข้อมูลข้ามตารางหรือฐานข้อมูล Sharding เป็นการแบ่งพาร์ติชั่นแบบหนึ่งประเภทซึ่งเป็นส่วนหนึ่งของการแบ่งพาร์ติชันแนวนอน

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

ตรรกะทั่วไปที่ใช้คีย์น้อยคือการใช้ตัวอักษรเพื่อแบ่งข้อมูล โฆษณาคืออินสแตนซ์ 1, EG เป็นอินสแตนซ์ 2 เป็นต้นข้อมูลลูกค้าเหมาะสมสำหรับสิ่งนี้ แต่จะมีการแสดงขนาดที่ไม่ถูกต้องในทุกกรณีหากการแบ่งพาร์ติชันไม่ได้คำนึงถึงว่าจดหมายบางฉบับมีความธรรมดามากกว่าตัวอื่น

เทคนิคทั่วไปอีกอย่างหนึ่งคือการใช้ระบบการซิงโครไนซ์คีย์หรือลอจิกที่รับรองคีย์ที่ไม่ซ้ำในอินสแตนซ์

ตัวอย่างที่รู้จักกันดีคุณสามารถศึกษาได้ว่า Instagram แก้ไขการแบ่งพาร์ติชันของพวกเขาอย่างไรในช่วงแรก ๆ (ดูลิงค์ด้านล่าง) พวกเขาเริ่มแบ่งพาร์ติชันบนเซิร์ฟเวอร์น้อยมากโดยใช้ Postgres เพื่อแบ่งข้อมูลจากการเริ่มต้น ฉันเชื่อว่ามันเป็นเศษลอจิคัลหลายพันชิ้นสำหรับชิ้นส่วนทางกายภาพเหล่านั้น อ่านงานเขียนยอดเยี่ยมจากปี 2012 ได้ที่นี่: Instagram Engineering - Sharding & IDs

ดูที่นี่เช่นกัน: http://www.quora.com/Whats-the-difference-between-sharding-and-partition


16
Sharding เป็นHP ประเภทหนึ่ง ไม่ใช่ HP
NoChance

1
ฉันคิดถูกแล้วว่าการแบ่งพาร์ติชันในแนวนอนหมายถึงการแบ่งแถวออกจากตารางไปเป็นตารางย่อยหลาย ๆ อัน (อาจอยู่ในสคีมาหรือฐานข้อมูลอินสแตนซ์เดียวกัน) ในขณะที่การแบ่งพาร์ทิชันแนวนอน หรือเป็นอินสแตนซ์ฐานข้อมูลแยกกันในเครื่องที่แยกต่างหาก หรือไม่?
Jonathan Hartley

48

ดูเหมือนว่าคำตอบทั้งสองคำถามของคุณ:

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

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

ที่มา: วิกิพีเดีย Shard

Sharding เป็นกระบวนการในการเก็บบันทึกข้อมูลในหลาย ๆ เครื่องและเป็นแนวทางของ MongoDB ในการตอบสนองความต้องการของการเติบโตของข้อมูล เมื่อขนาดของข้อมูลเพิ่มขึ้นเครื่องเดียวอาจไม่เพียงพอในการจัดเก็บข้อมูลหรือให้ปริมาณการอ่านและเขียนที่ยอมรับได้ Sharding แก้ปัญหาด้วยการไต่ระดับแนวนอน ด้วยการแบ่งส่วนคุณจะเพิ่มเครื่องจักรมากขึ้นเพื่อรองรับการเติบโตของข้อมูลและความต้องการในการอ่านและเขียน

ที่มา: MongoDB


41

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

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

https://en.wikipedia.org/wiki/Partition_(database)

Shardingเป็นประเภทของการแบ่งพาร์ติชันเช่นHorizontal Partitioning (HP)

นอกจากนี้ยังมีVertical Partitioning (VP) โดยที่คุณแบ่งตารางออกเป็นส่วนย่อย ๆ การนอร์มัลไลซ์ยังเกี่ยวข้องกับการแบ่งคอลัมน์ข้ามตารางนี้ แต่การแบ่งพาร์ติชันตามแนวตั้งนอกเหนือไปจากคอลัมน์นั้น

https://en.wikipedia.org/wiki/Shard_(database_architecture)

ฉันชอบคำตอบของ Tony Baco เกี่ยวกับ Quora ที่เขาทำให้คุณคิดในแง่ของสคีมา (แทนที่จะเป็นคอลัมน์และแถว) เขากล่าวว่า ...

"การแบ่งพาร์ติชันในแนวนอน " หรือการแบ่งส่วนกำลังจำลอง [คัดลอก] สคีมาแล้วหารข้อมูลตามคีย์ชาร์ด

"การแบ่งพาร์ติชันตามแนวตั้ง " เกี่ยวข้องกับการแบ่งสคีมา (และข้อมูลดำเนินต่อไปตามการขับขี่)

https://www.quora.com/Whats-the-difference-between-sharding-DB-tables-and-partitioning-them

คู่มือการแบ่งพาร์ติชันของฐานข้อมูลของออราเคิลมีตัวเลขที่ดี ฉันได้คัดลอกบางตอนของบทความ

https://docs.oracle.com/cd/B28359_01/server.111/b32024/partition.htm

เมื่อพาร์ทิชันตาราง

ต่อไปนี้เป็นคำแนะนำสำหรับการแบ่งพาร์ติชันตารางเมื่อ:

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

การตัดแต่งพาร์ติชัน

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

กลยุทธ์การแบ่งพาร์ติชัน

  • พิสัย
  • กัญชา
  • รายการ

คุณสามารถอ่านข้อความและเห็นภาพของพวกเขาซึ่งอธิบายทุกอย่างได้ดี

และท้ายที่สุดสิ่งสำคัญคือต้องเข้าใจว่าฐานข้อมูลนั้นต้องใช้ทรัพยากรอย่างมาก:

  • ซีพียู
  • ดิสก์
  • I / O
  • หน่วยความจำ

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

ในขณะที่กลยุทธ์อื่น ๆ จะใช้สถาปัตยกรรม "ไม่มีอะไรที่แชร์" ซึ่งส่วนจะอยู่ในหน่วยการคำนวณที่แยกและชัดเจน (โหนด) ซึ่งมี CPU, ดิสก์, I / O และหน่วยความจำ 100% ให้ข้อดีและความซับซ้อนเป็นของตัวเอง

https://en.wikipedia.org/wiki/Shared_nothing_architecture


"" การแบ่งพาร์ติชันแบบแนวนอน "หรือการแบ่งส่วนกำลังจำลอง [คัดลอก] สคีมาจากนั้นทำการแบ่งข้อมูลตามคีย์รหัส" - นี่คือการพูดซ้ำซาก
8bitjunkie

ดังนั้นจึงมีกระจกเงาและมันก็แยกส่วนดังนั้นนิรุกติศาสตร์
mckenzm

5

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

  1. 0.4 ล้านแถว (ตารางที่ 1), 0.6 ล้านแถว (ตารางที่ 2)

  2. 1 ล้านแถวและ 60 คอลัมน์ (ตารางที่ 1) และ 1 ล้านแถวและ 40 คอลัมน์ (ตารางที่ 2)

    อาจมีหลายกรณีเช่นนั้น

นี่เป็นการแบ่งพาร์ติชันทั่วไป

แต่Shardingอ้างถึงกรณีที่ 1 เฉพาะที่เราแบ่งข้อมูลตามแถว หากเราแบ่งตารางออกเป็นหลาย ๆ ตารางเราจำเป็นต้องรักษาสำเนา schema ที่คล้ายกันหลายชุดเนื่องจากตอนนี้เรามีหลายตาราง


1

การแบ่งส่วนในกรณีพิเศษของการแบ่งพาร์ติชันแนวนอนเมื่อพาร์ติชันครอบคลุมทั่วทั้งอินสแตนซ์ฐานข้อมูลหลายอินสแตนซ์ หากฐานข้อมูลถูกแบ่งออกก็หมายความว่าฐานข้อมูลถูกแบ่งพาร์ติชันตามคำจำกัดความ


1

เมื่อพูดถึงการแบ่งพาร์ติชันโปรดอย่าใช้คำซ้ำหรือจำลองแบบ การจำลองแบบเป็นแนวคิดที่แตกต่างและอยู่นอกขอบเขตของหน้านี้ เมื่อเราพูดถึงการแบ่งพาร์ติชั่นคำที่ดีกว่าจะถูกแบ่งและเมื่อเราพูดถึงการแชะ ในพาร์ติชัน (โดยปกติและโดยทั่วไปไม่เข้าใจเสมอ) แถวของชุดข้อมูลขนาดใหญ่จะแบ่งออกเป็นกลุ่มที่แยกจากกันสองกลุ่มขึ้นไป (ไม่แชร์แถวใด ๆ ) คุณสามารถเรียกพาร์ติชันแต่ละกลุ่มได้ กลุ่มเหล่านี้หรือพาร์ติชันทั้งหมดยังคงอยู่ภายใต้การควบคุมของอินสแตนซ์ RDMB หนึ่งครั้งและนี่คือตรรกะทั้งหมด ฐานของแต่ละกลุ่มอาจเป็นแฮชหรือช่วงหรืออื่น ๆ หากคุณมีข้อมูลสิบปีในตารางคุณสามารถจัดเก็บข้อมูลแต่ละปีในพาร์ติชันแยกต่างหากและสามารถทำได้โดยการตั้งค่าขอบเขตพาร์ติชันบนพื้นฐานของ คอลัมน์ที่ไม่ใช่นัล CREATE_DATE เมื่อคุณเคียวรี db ดังนั้นหากคุณระบุวันที่สร้างระหว่าง 01-01-1999 และ 31-12-2000 ดังนั้นจะมีเพียงพาร์ติชันสองตัวเท่านั้นที่จะได้รับผลกระทบและจะเป็นลำดับ ฉันทำเช่นเดียวกันกับ DB สำหรับพันล้านระเบียนและเวลา sql มาถึง 50 มิลลิวินาทีจาก 30 วินาทีโดยใช้ดัชนี ฯลฯ ทั้งหมด Sharding คือคุณโฮสต์แต่ละพาร์ติชันบนโหนด / เครื่องอื่น ตอนนี้การค้นหาภายในพาร์ทิชัน / เศษสามารถเกิดขึ้นพร้อมกัน


0

พาร์ทิชันแนวนอนเมื่อย้ายไปอยู่ที่อื่นเช่นฐานข้อมูล * กลายเป็นสะเก็ดฐานข้อมูล

อินสแตนซ์ฐานข้อมูลสามารถอยู่ในเครื่องเดียวกันหรือบนเครื่องอื่น

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