SQL ออกแบบตารางขนาดใหญ่

ฉันมีคำถามทั่วไปเกี่ยวกับการออกแบบตาราง SQL Server 2008 ขณะนี้เรามีตารางที่มีมากกว่า 600GB และเติบโตที่ประมาณ 3GB ต่อวัน ตารางนี้มีตัวบ่งชี้ที่เหมาะสม แต่กำลังกลายเป็น hangup ที่สำคัญเมื่อเรียกใช้คิวรีและเนื่องจากขนาดของมัน คำถามคือฉันควรแบ่งตารางออกเป็นหลาย ๆ ตารางตามปีและเดือน (ซึ่งจะเหมาะสมกับแผนกอื่น ๆ ที่แยกชุดข้อมูลขนาดใหญ่ของพวกเขา) หรือเราควรใช้ประโยชน์จากการแบ่งพาร์ติชันที่สร้างไว้ใน SQL Server ดูเหมือนว่าการใช้การแบ่งพาร์ติชันจะต้องมีการเปลี่ยนแปลงรหัสน้อย จากสิ่งที่ฉันอ่านเมื่อทำการแบ่งพาร์ติชั่นคุณยังคงสืบค้นเฉพาะหนึ่งตารางและเซิร์ฟเวอร์จะจัดการวิธีรับข้อมูล หากเราไปหลายเส้นทางเราจะต้องจัดการกับการดึงข้อมูลจากหลายตาราง

"ตารางนี้มีดัชนีที่เหมาะสม แต่กำลังกลายเป็น Hangup สำคัญเมื่อเรียกใช้แบบสอบถาม"

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

"และเพราะขนาดของมัน"

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

"ดูเหมือนว่าการใช้การแบ่งพาร์ติชันจะต้องมีการเปลี่ยนแปลงรหัสน้อย"

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

ฉันได้เขียนเพิ่มเติมเกี่ยวกับข้อผิดพลาดของการแบ่งที่นี่:

http://www.brentozar.com/archive/2008/06/sql-server-partitioning-not-the-answer-to-everything/

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

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

ในกรณีที่ลักษณะของข้อมูลของคุณแตกต่างกันไปในแต่ละเดือนแต่ละปีมุมมองที่แบ่งพาร์ติชันก็สามารถช่วยได้เช่นกัน ลองนึกภาพผู้ค้าปลีกที่เปลี่ยนสายผลิตภัณฑ์อย่างต่อเนื่องเช่นนั้นมีความสอดคล้องกันเล็กน้อยใน Product.ProductId มีการใช้งานในแต่ละปี ด้วยตารางคำสั่งซื้อ / คำสั่งรายละเอียดเดียวดังนั้นจึงมีฮิสโตแกรมสถิติเดียวสถิติจะเสนอเพียงเล็กน้อยสำหรับเครื่องมือเพิ่มประสิทธิภาพการสืบค้น ตารางต่อปี (Order_2010, Order_2011, OrderLine_2010, OrderLine_2011) แบ่งพาร์ติชันตามเดือนและรวมกับมุมมองที่แบ่งพาร์ติชัน (Order, OrderLine) จะให้สถิติที่ละเอียดและมีประโยชน์กับตัวเพิ่มประสิทธิภาพ

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

Kimberly Trippได้ตีพิมพ์คำแนะนำจำนวนมากและเอกสารทางเทคนิคเกี่ยวกับการแบ่งพาร์ติชันซึ่งโดยทั่วไปถือว่าเป็นการอ่านที่จำเป็นในหัวข้อ Kendra Littleมีเนื้อหาที่ดีและรายการอ้างอิงที่เป็นประโยชน์ของบทความอื่น

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

หากคุณมีกระบวนการไม่เหมาะ แต่ไม่ใช่เรื่องผิดปกติในการส่งข้อมูลสำรองผ่านเครือข่ายคุณอาจต้องดูเวลาในการกู้คืน 3 ชั่วโมงสำหรับ 600GB ปัจจุบันของคุณ ในหนึ่งปีเมื่อคุณละเมิด 1.5TB คุณมีปัญหา

ดังที่คุณพูดคุณมีสองตัวเลือกที่นี่:

1. ใช้ประโยชน์จากหลาย ๆ ตาราง
2. ใช้ประโยชน์จากการแบ่งพาร์ติชัน

ด้วย 1 คุณสามารถสร้าง VIEW ที่รวมตารางทั้งหมดเข้าด้วยกันและเพียงอัปเดตเพื่อรวมตารางที่สร้างขึ้นใหม่ ฉันคิดว่านี่เป็นวิธีเลียนแบบการแบ่งพาร์ติชัน ข้อดีของวิธีนี้รวมถึงไม่ต้องการ Enterprise Edition ของ SQL Server

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

หากคุณมี Enterprise Edition ฉันจะให้การแบ่งพาร์ติชันอย่างแน่นอน แม้จะดูซับซ้อนแค่ไหน แต่ก็ไม่ได้แย่ขนาดนั้น หากไม่มีการแบ่งพาร์ติชันจะไม่ใช่ตัวเลือกสำหรับคุณ

การสร้างตารางที่แบ่งพาร์ติชัน

ปรับเปลี่ยนตาราง Partitioned

การออกแบบพาร์ติชันเพื่อจัดการชุดย่อยของข้อมูล

หวังว่าจะช่วยได้

ด้าน

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

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