ดัชนีคอลัมน์แบบคลัสเตอร์และคีย์ต่างประเทศ


18

ฉันกำลังปรับแต่งคลังข้อมูลโดยใช้ดัชนี ฉันค่อนข้างใหม่กับ SQL Server 2014 Microsoft อธิบายต่อไปนี้:

"เราดูดัชนี columnstore ของคลัสเตอร์เป็นมาตรฐานสำหรับการจัดเก็บตารางข้อมูลคลังข้อมูลขนาดใหญ่และคาดว่าจะใช้ในสถานการณ์จำลองคลังข้อมูลส่วนใหญ่เนื่องจากดัชนี columnstore ของคลัสเตอร์สามารถอัปเดตได้เวิร์กโหลดของคุณสามารถทำการแทรกจำนวนมาก และลบการทำงาน " http://msdn.microsoft.com/en-us/library/gg492088.aspx

อย่างไรก็ตามหากคุณอ่านเพิ่มเติมในเอกสารคุณจะพบภายใต้ข้อ จำกัด และข้อ จำกัด :

"ไม่สามารถมีข้อ จำกัด ที่ไม่ซ้ำกันข้อ จำกัด ของคีย์หลักหรือข้อ จำกัด ของ Foreign Key"

ทำให้ฉันงงมาก! เป็นวิธีปฏิบัติที่ดี (ไม่บังคับ) ให้มีคีย์ต่างประเทศในคลังข้อมูลด้วยเหตุผลหลายประการ (ความสมบูรณ์ของข้อมูลความสัมพันธ์ที่มองเห็นได้สำหรับเลเยอร์ความหมาย ... )

ดังนั้นไมโครซอฟท์จึงสนับสนุนการจัดทำดัชนีคอลัมน์แบบจัดกลุ่มสำหรับสถานการณ์คลังข้อมูล แต่มันไม่สามารถจัดการกับความสัมพันธ์ที่สำคัญกับต่างประเทศได้!

ฉันถูกต้องหรือไม่ วิธีอื่นใดที่คุณจะแนะนำ ในอดีตที่ผ่านมาฉันใช้ดัชนี columnstore ที่ไม่ใช่คลัสเตอร์ในสถานการณ์ data warehouse โดยมีการปล่อยและสร้างใหม่สำหรับการโหลดข้อมูล อย่างไรก็ตาม SQL Server 2014 นั้นไม่ได้เพิ่มมูลค่าใหม่ให้กับคลังข้อมูล?


เมื่อคุณสมบัติครบคุณจะเห็นคุณลักษณะเหล่านี้ได้รับการสนับสนุนเพิ่มมากขึ้น (heck ในปี 2012 ดัชนีคอลัมน์ของคอลัมน์ถูกอ่านอย่างเดียว!) ในระหว่างนี้คุณจะได้รับข้อเสนอการแลกเปลี่ยน - ประสิทธิภาพที่ยอดเยี่ยมพร้อมข้อ จำกัด หรืออายุเท่าเดิม ฉันยังไม่เชื่อว่าพวกเขาตั้งใจที่จะหมายความว่าทุก ๆ ตารางใน DW ของคุณควรมีดัชนีคอลัมน์แบบกลุ่มและไม่มีตารางใดที่ควรมีข้อ จำกัด - อาจมีจำนวน จำกัด ของตารางใน DW ใด ๆ ที่จะทำให้คุณได้รับผลกระทบอย่างมาก เจ้าชู้.
Aaron Bertrand

3
ระวัง - มันสามารถจัดการกับการเข้าร่วม ความสัมพันธ์ FK นั้นไม่จำเป็นสำหรับการเข้าร่วม มันอยู่ที่นั่นเพื่อจัดการ Referential Integrity - ซึ่งดีที่มี แต่ในคลังข้อมูลสามารถละเว้น มีความเสี่ยงใช่ แต่ยังได้รับประสิทธิภาพเพิ่มขึ้นด้วย
TomTom

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

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

@AaronBertrand ในสถานการณ์ DWH ที่มีตารางความจริงที่มี foreign key ของดัชนี Clustered Columnstore ไม่ทำงาน ในทางตรงกันข้ามขนาดใหญ่กับ Microsoft คาดว่านี่เป็นมาตรฐานในการจัดเก็บตารางความเป็นจริงที่มีขนาดใหญ่ ฉันหวังว่าคุณจะพิสูจน์ฉันผิด ... เพราะฉันชอบ SQL Server
OverflowStack

คำตอบ:


13

คุณมีคำถามมากมายที่นี่:

ถาม: (การขาดกุญแจต่างประเทศ) ทำให้ฉันสับสนมาก! เป็นวิธีปฏิบัติที่ดี (ไม่ใช่ข้อบังคับ) เพื่อให้ Fk อยู่ใน DWH ด้วยเหตุผลหลายประการ (ความสมบูรณ์ของข้อมูลความสัมพันธ์ที่มองเห็นได้สำหรับเลเยอร์ความหมาย, .... )

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

ถาม: ดังนั้น MS จึงสนับสนุนดัชนีที่เก็บคอลัมน์แบบคลัสเตอร์สำหรับสถานการณ์ DWH อย่างไรก็ตามไม่สามารถจัดการความสัมพันธ์ FK ได้!

ตอบ: Microsoft ให้เครื่องมือแก่คุณ ขึ้นอยู่กับคุณว่าคุณใช้เครื่องมือเหล่านั้นอย่างไร

หากความท้าทายที่ยิ่งใหญ่ที่สุดของคุณคือการขาดความสมบูรณ์ของข้อมูลในคลังข้อมูลของคุณเครื่องมือที่คุณต้องการคือตารางทั่วไปที่มีคีย์ต่างประเทศ

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

ถาม: อย่างไรก็ตาม SQL 2014 กว่าเพิ่มไม่มีค่าใหม่ที่แท้จริงสำหรับ DWH ??

ตอบ: โชคดีที่คอลัมน์ของคลัสเตอร์ไม่ได้เป็นคุณสมบัติใหม่เพียงอย่างเดียวใน SQL Server 2014 ตัวอย่างเช่นตรวจสอบcardinality estimator ใหม่

ถาม: เหตุใดฉันจึงโกรธและขมขื่นกับวิธีการนำคุณลักษณะที่ฉันโปรดปรานไปใช้

A: คุณจับฉัน - คุณไม่ได้ถามคำถามนั้น - แต่ฉันจะตอบมันต่อไป ยินดีต้อนรับสู่โลกของซอฟต์แวร์บุคคลที่สามที่ไม่ใช่ทุกอย่างถูกสร้างขึ้นตามข้อกำหนดที่แน่นอนของคุณ ถ้าคุณรู้สึกหลงใหลเกี่ยวกับการเปลี่ยนแปลงที่คุณต้องการที่จะเห็นในผลิตภัณฑ์ Microsoft ตรวจสอบConnect.Microsoft.com นี่เป็นกระบวนการแสดงความคิดเห็นของพวกเขาที่คุณสามารถส่งการเปลี่ยนแปลงคนอื่นสามารถโหวตได้แล้วทีมผลิตภัณฑ์จะอ่านและบอกคุณว่าทำไมพวกเขาถึงไม่ใช้มัน บางครั้ง เวลาส่วนใหญ่ที่พวกเขาทำเครื่องหมายว่า "จะไม่แก้ไขทำงานบนเครื่องของฉัน" แต่เดี๋ยวก่อนบางครั้งคุณก็ได้รับคำตอบ


"ถูกต้องเป็นวิธีปฏิบัติที่ดีที่จะมีคีย์ต่างประเทศในคลังข้อมูล" -> SQLCAT - แนวทางปฏิบัติที่ดีที่สุด 10 อันดับแรกสำหรับการสร้างคลังข้อมูลเชิงสัมพันธ์ขนาดใหญ่ ... "สร้างดัชนีที่ไม่ได้ทำคลัสเตอร์สำหรับแต่ละคีย์ต่างประเทศ" -> ไม่มีอะไรเกี่ยวกับการบังคับใช้ความสัมพันธ์ FK ที่กล่าวถึงในลิงก์และผู้ที่ไม่ใช่ CI ซ้ำซ้อนเนื่องจากคอลัมน์ร้านค้าดังนั้นคุณจะเห็นว่าไม่จำเป็นต้องมี FK ในตารางข้อเท็จจริงคุณจะเห็นด้วยไหม สนใจในความคิดของคุณเกี่ยวกับเรื่องนี้
Adrian Torrie

1
... และสำหรับมิติข้อมูล: "หลีกเลี่ยงการบังคับใช้ความสัมพันธ์กับคีย์ต่างประเทศระหว่างข้อเท็จจริงและตารางมิติเพื่ออนุญาตให้โหลดข้อมูลได้เร็วขึ้นคุณสามารถสร้างข้อ จำกัด foreign key กับ NOCHECK เพื่อจัดทำเอกสารความสัมพันธ์ แต่ไม่บังคับใช้ แต่เปลี่ยนการค้นหาหรือดำเนินการตรวจสอบความสมบูรณ์ของข้อมูลที่แหล่งที่มาของข้อมูลที่"
เอเดรีย Torrie

6

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

อย่างไรก็ตาม SQL Server นั้นถูกใช้อย่างประสบความสำเร็จเมื่อ Foreign Keys เป็นเพียงแนวคิด (ซึ่งเรานำมาใช้ผ่านทริกเกอร์ในสมัยนั้น) ไม่ใช่การใช้งานจริงเช่นข้อ จำกัด Declarative Referential Integrity อยู่ที่นั่นอย่างน้อยก็โดย SQL Server 7.0 แต่ก็อ่อนแอกว่าการใช้งานในปัจจุบัน

เกี่ยวกับค่าของคอลัมน์ ColumnStore ที่ทำหน้าที่จัดทำดัชนีและแถวสามารถอัปเดตได้ คุณอาจพบว่าการสนทนานี้มีค่า: http://sqlwithmanoj.com/2014/07/24/maintaining-uniqueness-with-clustered-columnstore-index-sql-server-2014/

Manoj ชี้ให้เห็นว่ามีวิธีในการสร้างมุมมองที่จัดทำดัชนี / Materialized อยู่ด้านบนของตารางนี้ด้วยคีย์การจัดกลุ่มเป็น PK (คอลัมน์ที่ 1 ของตาราง / มุมมอง) แน่นอนว่าการตัดสินใจนั้นเหมาะสมกับคุณหรือไม่

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


2

คำถามนี้เกี่ยวข้องกับ SQL 2014 แต่ฉันต้องการให้ข้อมูลเพิ่มเติมในแง่ของการเปลี่ยนแปลงที่เกิดขึ้นใน SQL 2016 ไปยังดัชนี columnstore เนื่องจากอาจเป็นการยากที่จะแยกแยะข้อ จำกัด ในรุ่นต่าง ๆ และคำถามนี้ยังค่อนข้างสูงใน Google:

สำหรับ SQL 2016, Microsoft อธิบายวิธีการใช้ดัชนี btree nonclustered (ซึ่งตอนนี้สามารถเพิ่มเป็นดัชนีรองบนตาราง columnstore คลัสเตอร์) เพื่อบังคับใช้ข้อ จำกัด คีย์ต่างประเทศโดยมีการเพิ่มข้อ จำกัด ก่อนหน้าดัชนี columnstore: https: // docs .microsoft.com / en-US / SQL / เชิงสัมพันธ์ฐานข้อมูล / ดัชนี / columnstore ดัชนี-ออกแบบคำแนะนำ

Niko Neugebauer ยังมีบล็อกโพสต์เกี่ยวกับเรื่องนี้; เป็นไปได้จริงที่จะสร้างข้อ จำกัด ที่ไม่ซ้ำกัน / ต่างประเทศโดยตรงในตาราง columnstore (ฉันได้ใช้วิธีการนี้ในการทำงานของฉัน): http://www.nikoport.com/2015/09/15/columnstore-indexes-part-66- เพิ่มเติมคลัสเตอร์-columnstore-ปรับปรุงใน SQL เซิร์ฟเวอร์ 2016 /

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