ฐานข้อมูลเข้าร่วมเมื่อใดและเพราะเหตุใด


354

ฉันกำลังทำการวิจัยในฐานข้อมูลและฉันกำลังดูข้อ จำกัด บางประการของฐานข้อมูลเชิงสัมพันธ์

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

ยินดีต้อนรับประสบการณ์ส่วนตัว! หากคุณกำลังจะโพสต์ลิงก์ไปยังแหล่งข้อมูลโปรดหลีกเลี่ยง Wikipedia ฉันรู้ว่าจะหามันเจอแล้ว

ในความสัมพันธ์กับเรื่องนี้ฉันสงสัยเกี่ยวกับวิธีการที่ผิดปกติที่ใช้โดยฐานข้อมูลบริการคลาวด์เช่น BigTable และ SimpleDB ดูคำถามนี้


3
คุณกำลังมองหาผลประโยชน์ด้วยหรือไม่? ;)
— David Aldridge

ฉันกำลังมองหาวัตถุประสงค์ (หากมีสิ่งนั้น) เปรียบเทียบ Pro's, con's, what-have-you's
— Rik

วิธีการแสดงผลล่วงหน้าของคลาวด์คอมพิวติ้งนั้นมีความสามารถในการเดิมพันทุกวิถีทางเพื่อหลีกเลี่ยงปัญหา "การเข้าร่วมที่ผิดพลาด" Google มีสมุดปกขาวในระบบของตนเอง น่าสนใจทีเดียว - วิธีในการขยายการบังคับใช้กรณีพิเศษ
— Peter Wone

@PeterWone - สนใจที่จะให้การอ้างอิงถึงบางส่วนของเอกสารเหล่านั้นหรือไม่? ps เพื่อตอบคำถามในโปรไฟล์ของคุณ Android เป็นโอเพ่นซอร์ส - อย่างน้อยก็บางส่วนดังนั้น geeks จึงกระโดดขึ้นไปบน bandwagon เมื่อมองในแง่ของเทคนิคขั้นสูงโดยผู้ที่ไม่เคยอาบน้ำมาก่อนพวกเขาก็ตามเหมือนเข้าไปในอ้อมกอดที่เต็มไปด้วยเหงื่อของ Google! Betamax ทุกคน? ใกล้เคียงกับใจของฉัน (และรุ่น), MySQL ได้อย่างไร (โดยที่ไม่มีFOREGIN KEYFFS) กลายเป็น (และยังคง) DBMS "R" ที่เป็นที่นิยมมากที่สุดในโลกเมื่อมีการแข่งขันจาก PostgreSQL (ไม่มีรุ่น Windows ดั้งเดิม) และ Firebird (Opensourcing fiasco) หรือแม้แต่ SQLite
— Vérace

จำเป็นต้องพูดผมถือว่า PostgreSQL และ Firebird เป็นอย่างมากมายที่เหนือกว่ากับ MySQL สำหรับระบบหลายผู้ใช้และ SQLite เป็นตัวเอกในวงผู้ใช้คนเดียว SQLite จัดการไซต์ sqlite.org (400,00 ครั้งต่อวัน!)
— Vérace

คำตอบ:


470

ปฏิเสธการปรับปรุงประสิทธิภาพหรือไม่ ฟังดูน่าเชื่อถือ แต่ก็ไม่ถือน้ำ

Chris Date ผู้ร่วมงานกับ Dr Ted Codd เป็นผู้เสนอต้นแบบของโมเดลข้อมูลเชิงสัมพันธ์หมดความอดทนด้วยข้อโต้แย้งที่ผิดกับการปรับสภาพและทำลายระบบอย่างเป็นระบบโดยใช้วิธีการทางวิทยาศาสตร์: เขามีฐานข้อมูลขนาดใหญ่และทดสอบการยืนยันเหล่านี้

ผมคิดว่าเขาเขียนมันขึ้นมาในฐานข้อมูลเชิงสัมพันธ์เขียน 1988-1991แต่หนังสือเล่มนี้ต่อมาถูกรีดเป็นรุ่นที่หกของการรู้เบื้องต้นเกี่ยวกับระบบฐานข้อมูลซึ่งเป็นข้อความที่ชัดเจนเกี่ยวกับทฤษฎีฐานข้อมูลและการออกแบบในรุ่นที่แปดที่ผมเขียนและมีแนวโน้มที่จะยังคงอยู่ ในการพิมพ์มานานหลายทศวรรษ Chris Date เป็นผู้เชี่ยวชาญในด้านนี้เมื่อพวกเราส่วนใหญ่ยังคงวิ่งรอบเท้าเปล่า

เขาพบว่า:

  • บางคนถือเป็นกรณีพิเศษ
  • พวกเขาทั้งหมดไม่ชำระเพื่อการใช้งานทั่วไป
  • ทั้งหมดนั้นแย่ลงอย่างมากสำหรับกรณีพิเศษอื่น ๆ

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

การทำให้ผลลัพธ์เป็นจริงนั้นเกี่ยวข้องกับการอ่านดิสก์จำนวนมากซึ่งเป็นแง่มุมที่แพงที่สุดของการฝึกตามลำดับความสำคัญ ในทางกลับกันการเข้าร่วมจำเป็นต้องมีการดึงกุญแจเท่านั้น ในทางปฏิบัติไม่แม้แต่จะเรียกค่าคีย์: ค่าแฮชคีย์จะใช้สำหรับการเปรียบเทียบการเข้าร่วมลดค่าใช้จ่ายของการรวมหลายคอลัมน์และลดต้นทุนการรวมที่เกี่ยวข้องกับการเปรียบเทียบสตริงอย่างรุนแรง ไม่เพียง แต่จะเหมาะกับแคชมากขึ้นเท่านั้นยังมีการอ่านดิสก์ให้น้อยลง

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

การเพิ่มประสิทธิภาพประเภทนี้เป็นที่ยอมรับกันสามารถนำไปใช้กับฐานข้อมูล denormalised แต่ประเภทของคนที่ต้องการ denormalise schema มักจะไม่คิดเกี่ยวกับ cardinality เมื่อ (ถ้า) พวกเขาตั้งค่าดัชนี

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

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

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

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

สำหรับคุณทุกคนที่ทำงานกับระบบเรียกเก็บเงินหรือเครื่องปั่นไฟอีเมลขยะ (อัปยศที่คุณ) และตั้งมืออย่างไม่เกรงกลัวกับแป้นพิมพ์เพื่อบอกฉันว่าคุณรู้ดีว่า denormalisation นั้นเร็วกว่าขออภัย แต่คุณใช้ชีวิตในแบบพิเศษ กรณี - โดยเฉพาะกรณีที่คุณประมวลผลข้อมูลทั้งหมดตามลำดับ ไม่ใช่กรณีทั่วไปและคุณมีความชอบธรรมในกลยุทธ์ของคุณ

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

ฉันต้องการที่จะตอบสนอง

เข้าร่วมเป็นเพียงผลิตภัณฑ์คาร์ทีเซียนที่มีลิปกลอสบางส่วน

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

วิธีเดียวที่คุณจะได้รับเครื่องมือเพิ่มประสิทธิภาพในการผลิตผลิตภัณฑ์คาร์ทีเซียนคือการล้มเหลวในการจัดหาภาคแสดง: SELECT * FROM A,B


หมายเหตุ


David Aldridge ให้ข้อมูลเพิ่มเติมที่สำคัญบางอย่าง

แน่นอนว่ามีกลยุทธ์อื่น ๆ ที่หลากหลายนอกเหนือจากดัชนีและการสแกนตารางและเครื่องมือเพิ่มประสิทธิภาพที่ทันสมัยจะมีค่าใช้จ่ายทั้งหมดก่อนที่จะสร้างแผนการดำเนินการ

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

ฉันเคยฉลาดกว่าเครื่องมือเพิ่มประสิทธิภาพ MSSQL ที่เปลี่ยนสองรุ่นที่ผ่านมา ตอนนี้มันทั่วไปสอนฉัน ในความเป็นจริงมันเป็นระบบผู้เชี่ยวชาญที่รวบรวมภูมิปัญญาทั้งหมดของคนที่ฉลาดมาก ๆ ในโดเมนที่ปิดอย่างพอเพียงว่าระบบที่ใช้กฎนั้นมีประสิทธิภาพ


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

เหตุผลที่ฉันตอบกลับอย่างโหดเหี้ยมก็คือคำแถลงดังที่กล่าวไว้นั้น

เข้าร่วมเป็นผลิตภัณฑ์คาร์ทีเซียน ...

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

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


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


บางครั้ง denormalisation เป็นความคิดที่ดี

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

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

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

จุดสำคัญที่นี่เป็นที่นอกเหนือจากการปรับปรุงเป็นระยะคลังข้อมูลที่มีการอ่านเท่านั้น วาทกรรมนี้ทำให้สงสัยคำถามของการปรับปรุงความผิดปกติ

อย่าทำผิดพลาดในการทำให้ฐานข้อมูล OLTP ของคุณเสื่อมสภาพ (ฐานข้อมูลที่มีการป้อนข้อมูลเกิดขึ้น) อาจเร็วกว่าสำหรับการเรียกเก็บเงิน แต่ถ้าคุณทำเช่นนั้นคุณจะได้รับความผิดปกติในการอัปเดต เคยลอง Reader's Digest แล้วหยุดส่งของหรือเปล่า

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


ปัญหา ADO.NET ที่มีชนิดไม่ตรงกัน

สมมติว่าคุณมีตาราง SQL Server ที่มีคอลัมน์ที่จัดทำดัชนีประเภท varchar และคุณใช้ AddWithValue เพื่อส่งผ่านพารามิเตอร์ที่ จำกัด การสืบค้นในคอลัมน์นี้ สตริง C # เป็น Unicode ดังนั้นประเภทพารามิเตอร์ที่อนุมานจะเป็น NVARCHAR ซึ่งไม่ตรงกับ VARCHAR

VARCHAR to NVARCHAR เป็นการแปลงที่กว้างขึ้นดังนั้นมันจึงเกิดขึ้นโดยปริยาย - แต่บอกลาการทำดัชนีและขอให้โชคดีว่าทำไม


"นับจำนวนครั้งที่พบดิสก์" (Rick James)

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

หาก schema "normalized" ทำให้JOINsดิสก์มีจำนวนมาก แต่สกีมา "denormalized" ที่เทียบเท่าจะไม่ต้องกดดิสก์จากนั้น denormalization จะชนะการแข่งขันด้านประสิทธิภาพ

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


7
Sonme ของข้อความเหล่านี้เฉพาะ DBMS เฉพาะใช่มั้ย เช่น. "มีความสัมพันธ์น้อยกว่า 200 แถว"
— David Aldridge

2
การใช้กุญแจตัวแทน (หรือไม่) มีอิทธิพลต่อสิ่งเหล่านี้อย่างมีนัยสำคัญหรือไม่?
— David Plumpton

3
EF Codd ที่ยอดเยี่ยมนั้นรับผิดชอบต่อโมเดลเชิงสัมพันธ์ แต่เพียงผู้เดียว CJ Date และ H Darwen เมื่อเร็ว ๆ นี้เป็นทั้งคนโง่ที่ไม่เข้าใจ RM และให้ข้อมูลมากมายเกี่ยวกับ "วิธีการปรับปรุง" RM ซึ่งทั้งหมดสามารถถูกไล่ออกได้เพราะเราไม่สามารถแก้ไขสิ่งที่ไม่เข้าใจได้ . พวกเขาทำหน้าที่เพียงเพื่อทำลายความเกี่ยวข้องของ RM โดยการแนะนำว่ามีบางสิ่งที่ "หายไป"
— PerformanceDBA

7
อย่าลืมว่าฐานข้อมูล NoSQL จำนวนมากเป็นฐานข้อมูลเดียวกันกับที่เราทิ้งไปเมื่อ 40 ปีก่อน คนหนุ่มสาวมักจะคิดว่าพวกเขาค้นพบสิ่งใหม่ ๆ Fabian Pascal: dbdebunk.com/2014/02/thinking-logically-sql-nosql-and.html
— N West

3
ก้าวร้าว. มันเป็นบัญชีที่ดี แต่ความก้าวร้าวและความก้าวร้าวไม่ได้เพิ่มเนื้อหาหรือคุณค่าของเนื้อหา
— MrMesees

46

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

ไม่ว่าในกรณีใดค่าใช้จ่ายในการเข้าร่วมขึ้นอยู่กับประเภทและปัจจัยอื่น ๆ ไม่จำเป็นต้องมีราคาแพงเลย - ตัวอย่างบางส่วน

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

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


ฉันคิดว่ามันลงไปที่ "หากมีข้อสงสัยให้ถาม DBA ของคุณ" ฐานข้อมูลที่ทันสมัยเป็นสัตว์ที่ซับซ้อนและต้องมีการศึกษาเพื่อทำความเข้าใจ ฉันเพิ่งใช้ Oracle มาตั้งแต่ปี 1996 และเป็นงานประจำที่ติดตามคุณสมบัติใหม่ ๆ SQLserver นั้นมีมาอย่างมากมายตั้งแต่ปี 2005 มันไม่ใช่กล่องดำ!
— Guy

2
อืมในประสบการณ์ต่ำต้อยของฉันมี DBA มากเกินไปที่นั่นที่ไม่เคยได้ยินการเข้าร่วมแฮชหรือคิดว่าพวกเขาเป็นสิ่งที่ไม่ดีในระดับสากล
— David Aldridge

28

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

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

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


1
@joel การสนทนาก็เป็นจริงเช่นกัน การรวมชุดข้อมูลขนาดใหญ่อาจมีราคาแพงและบางครั้งก็จำเป็น แต่คุณไม่ต้องการทำบ่อยเกินไปเว้นแต่ก) คุณสามารถจัดการ IO และ RAM ที่ต้องการและข) คุณไม่ได้ทำบ่อยเกินไป พิจารณามุมมองที่เป็นรูปธรรม, ระบบการรายงาน, รายงานแบบเรียลไทม์เทียบกับ CoB
— Guy

11

คอขวดสวยมากอยู่เสมอดิสก์ I / O เสมอและโดยเฉพาะอย่างยิ่งมากขึ้น - ดิสก์สุ่ม I / O (โดยการเปรียบเทียบการอ่านตามลำดับค่อนข้างเร็วและสามารถแคชด้วยกลยุทธ์การอ่านล่วงหน้า)

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

ตารางที่มีความผิดปกติเพียงตัวเดียวมีปัญหาที่คล้ายกัน - แถวมีขนาดใหญ่และไม่พอดีกับหน้าข้อมูลเดียว หากคุณต้องการแถวที่อยู่ไกลจากแถวอื่น (และขนาดแถวใหญ่ทำให้แยกออกไปไกลกว่า) จากนั้นคุณจะมี I / O แบบสุ่มมากขึ้น อีกครั้งการสแกนตารางอาจถูกบังคับให้หลีกเลี่ยงสิ่งนี้ แต่ในเวลานี้การสแกนตารางของคุณต้องอ่านข้อมูลเพิ่มเติมเนื่องจากขนาดแถวใหญ่ เพิ่มไปที่ข้อเท็จจริงที่ว่าคุณกำลังคัดลอกข้อมูลจากสถานที่เดียวไปยังสถานที่หลายแห่งและ RDBMS นั้นมีมากมายให้อ่าน (และแคช)

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

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

  • การเข้าร่วมแบบวนซ้ำนั้นถูกสำหรับชุดข้อมูลขนาดเล็ก (อย่างน้อย 1) ตัว
  • การเข้าร่วมผสานต้องใช้ทั้งสองชุดข้อมูลก่อน หากคุณเข้าร่วมในคอลัมน์ที่จัดทำดัชนีไว้ดัชนีจะถูกจัดเรียงไว้แล้วและไม่จำเป็นต้องดำเนินการใด ๆ เพิ่มเติม มิฉะนั้นจะมี CPU และหน่วยความจำโอเวอร์เฮดในการเรียงลำดับ
  • การเข้าร่วมแฮชต้องใช้ทั้งหน่วยความจำ (เพื่อเก็บ hashtable) และ CPU (เพื่อสร้างแฮช) สิ่งนี้ค่อนข้างรวดเร็วเมื่อเทียบกับดิสก์ I / O อย่างไรก็ตามหากมี RAM ไม่เพียงพอในการจัดเก็บ hashtable เซิร์ฟเวอร์ SQL จะใช้ tempdb เพื่อเก็บชิ้นส่วนของ hashtable และแถวที่พบแล้วประมวลผลเฉพาะส่วนของ hashtable ในแต่ละครั้ง เหมือนกับทุกสิ่งดิสก์นี่ค่อนข้างช้า

ในกรณีที่เหมาะสมที่สุดสิ่งเหล่านี้ทำให้ไม่มีดิสก์ I / O - และอื่น ๆ นั้นมีเพียงเล็กน้อยจากมุมมองด้านประสิทธิภาพ

ที่แย่ที่สุด - จริง ๆ แล้วมันควรจะเร็วกว่าที่จะอ่านข้อมูลเชิงตรรกะจำนวนเท่ากันจาก x เข้าร่วมตารางเนื่องจากมันมาจากตาราง denormalized เดียวเพราะอ่านดิสก์ที่เล็กกว่า หากต้องการอ่านข้อมูลทางกายภาพจำนวนเท่ากันอาจมีค่าใช้จ่ายเล็กน้อย

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


การลดการค้นหาแบบสุ่ม: เป็นจุดที่ดีแม้ว่าคอนโทรลเลอร์ RAID ที่ดีที่มีแคชขนาดใหญ่จะทำการอ่าน / เขียนโดยใช้ลิฟท์
— Peter Wone

3

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

สำหรับบางฐานข้อมูลไม่สำคัญตัวอย่างเช่น MS SQL จะทราบลำดับการรวมที่เหมาะสมเกือบตลอดเวลา สำหรับบางคน (เช่น IBM Informix) คำสั่งนั้นสร้างความแตกต่าง


1
โดยทั่วไปแล้วเครื่องมือเพิ่มประสิทธิภาพการสืบค้นที่ดีจะไม่ได้รับผลกระทบตามลำดับที่การรวมหรือตารางมีการระบุไว้และจะทำการกำหนดวิธีที่มีประสิทธิภาพมากที่สุดในการดำเนินการเข้าร่วม
— David Aldridge

5
MySQL, Oracle, SQL Server, Sybase, postgreSQL เป็นต้น ไม่สนใจลำดับของการเข้าร่วม ผมเคยทำงานกับ DB2 และมันก็เพื่อความรู้ของฉันไม่ได้สนใจสิ่งที่สั่งซื้อที่คุณใส่ไว้ในนี้ไม่ได้เป็นคำแนะนำที่เป็นประโยชน์ในกรณีทั่วไป.
— แมตต์ Rogish

การจัดกลุ่ม MySQL โดยใช้เอ็นจิ้น NDB (กรณีที่เป็นที่ยอมรับและมีเพียงนักพัฒนาขั้นสูงเท่านั้นที่จะเข้าใกล้ NDB) ไม่เดาคำสั่งการเข้าร่วมอย่างถูกต้องดังนั้นคุณต้องเพิ่มคำสั่ง "USE INDEX" ลงในแบบสอบถามที่เข้าร่วมส่วนใหญ่ ไร้ประสิทธิภาพ MySQL เอกสารครอบคลุม
— joelhardi

@iiya การทำความเข้าใจว่าเครื่องมือเพิ่มประสิทธิภาพจะเลือกอะไรสำคัญกว่างบทั่วไปหรือ "ตำนาน" เกี่ยวกับการสั่งซื้อตาราง อย่าพึ่งพาการเล่นโวหารเฉพาะใน SQL ของคุณเนื่องจากพฤติกรรมมักเปลี่ยนไปเมื่อมีการอัพเกรด RDBMS Oracle มีการเปลี่ยนแปลงพฤติกรรมหลายครั้งตั้งแต่ v7
— Guy

1
@Matt ฉันได้เห็น Oracle 9i ทำการปรับแต่งที่แตกต่างกันมากและมีแผนแบบสอบถามเพียงแค่ปรับลำดับการเข้าร่วม อาจจะมีการเปลี่ยนแปลงจากรุ่น 10i เป็นต้นไปหรือไม่
— Camilo Díaz Repka

0

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

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

การถกเถียงเรื่องการปรับสภาพและการทำให้เป็นปกติจะไม่จบลงเพราะปัญหามีมากมาย มีปัญหามากมายที่วิธีแก้ปัญหาตามธรรมชาติต้องการทั้งสองวิธี

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


-8

อธิบายอย่างละเอียดถึงสิ่งที่คนอื่นพูด

เข้าร่วมเป็นเพียงผลิตภัณฑ์คาร์ทีเซียนที่มีลิปกลอสบางส่วน {1,2,3,4} X {1,2,3} จะให้ 12 ชุดค่าผสม (nXn = n ^ 2) ชุดที่คำนวณนี้ทำหน้าที่เป็นข้อมูลอ้างอิงเกี่ยวกับเงื่อนไขที่ใช้ DBMS ใช้เงื่อนไข (เช่นที่ทั้งซ้ายและขวาเป็น 2 หรือ 3) เพื่อให้เงื่อนไขการจับคู่กับเรา ที่จริงแล้วมันได้รับการปรับให้เหมาะสมที่สุด แต่ปัญหาก็เหมือนกัน การเปลี่ยนแปลงขนาดของชุดจะเพิ่มขนาดผลลัพธ์เป็นทวีคูณ จำนวนหน่วยความจำและรอบ cpu ที่ใช้หมดทั้งหมดจะได้รับผลกระทบในรูปของเลขชี้กำลัง

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


3
-1: โพสต์นี้เป็นตัวอย่างที่ดีว่าทำไมคุณถึงปล่อยให้ DBMS ทำการเชื่อมต่อเพราะผู้ออกแบบ DBMS คิดถึงปัญหาเหล่านี้ตลอดเวลาและหาวิธีที่มีประสิทธิภาพมากกว่าในการทำมากกว่าวิธี compsci 101
— David Aldridge

2
@ David: เห็นด้วย โปรแกรมเมอร์ตัวเพิ่มประสิทธิภาพ DBMS เป็นคุกกี้สมาร์ท
— Matt Rogish

คำตอบนี้ไม่ถูกต้อง หากแบบสอบถามของคุณถูกดำเนินการกับฐานข้อมูลที่ทำดัชนีเป็นมาตรฐานและมีตัวกรองหรือเงื่อนไขการเข้าร่วมใด ๆ เครื่องมือเพิ่มประสิทธิภาพจะค้นหาวิธีที่จะหลีกเลี่ยงผลิตภัณฑ์คาร์ทีเซียนและลดการใช้หน่วยความจำและรอบ CPU หากคุณตั้งใจจะเลือกผลิตภัณฑ์คาร์ทีเซียนจริง ๆ คุณจะใช้หน่วยความจำเดียวกันในฐานข้อมูลปกติหรือฐานข้อมูลปกติ
— rileymcdowell
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.