ความจุของตารางสูงสุดใน SQL Server 2008

ฉันมีแอปพลิเคชันที่แทรกมากกว่า 1 พันล้านแถวต่อปีลงในตาราง ตารางนี้มีบางส่วนvarcharและbigintคอลัมน์และหนึ่งคอลัมน์หยดเช่นกัน

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

ขนาดไฟล์ข้อมูลที่กล่าวถึงในลิงค์นั้นอ้างถึงกลุ่มไฟล์ข้อมูลตารางหรือไม่?

sql-server-2008

— GAP
แหล่งที่มา

@marc_s ขอบคุณสำหรับการจับที่ อย่าลังเลที่จะเข้าร่วมกับเราในThe Heapซึ่งเราได้นำความสนใจเหล่านี้มารวมกัน

— JNK

ขนาดสูงสุดของแต่ละแถวคือเท่าใด

— Nick Chammas

คำตอบ:

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

หากคุณต้องการที่จะสูงกว่า 16TB คุณต้องมีหลายไฟล์ (ขั้นตอนง่าย ๆ )

— usr
แหล่งที่มา

ฉันคิดว่าสิ่งนี้สามารถทำได้โดยการแบ่งตารางและมีการแบ่งพาร์ติชันเพื่อใช้กลุ่มไฟล์ต่าง ๆ ถ้าฉันถูกต้อง?

— GAP

นั่นไม่จำเป็นแม้แต่ เพียงเพิ่มไฟล์ใหม่ (ไปยังกลุ่มไฟล์ที่มีอยู่) SQL Server จะเริ่มเติมไฟล์ทั้งหมดอย่างเท่าเทียมกัน หากไฟล์หนึ่งไม่สามารถเติบโตได้อีกต่อไปมันก็จะขยายไฟล์อื่น ๆ

— usr

ตารางใน SQL Server 2008 สามารถจัดการระเบียนจำนวนมากและเป็น @usr กล่าวว่าขึ้นอยู่กับพื้นที่ว่างในดิสก์ แต่ขอแนะนำว่าถ้าตารางของคุณมีแถวมากและมันช่วยในการเจริญเติบโตที่คุณใช้พาร์ติชันตาราง http://technet.microsoft co.th / en-US / ห้องสมุด / dd578580 (v = sql.100) .aspx

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

ข้อมูลเพิ่มเติมเกี่ยวกับมัน

http://msdn.microsoft.com/en-us/library/ms190787.aspx

และวิธีการใช้งาน http://blog.sqlauthority.com/2008/01/25/sql-server-2005-database-table-partitioning-tutorial-how-to-horizontal-partition-database-table/

— AmmarR
แหล่งที่มา

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

— JNK

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

— AmmarR

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

— JNK

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

— GAP

วิธีการใด ๆ ที่คุณใช้นั้นมีวิธีปฏิบัติที่ดีที่สุดที่สามารถทำให้ดีหรือไม่ดีฉันหมายความว่าถ้าคุณมีตารางจำนวนมากแบบสอบถามของคุณจะซับซ้อนและยากที่จะรักษาถ้าคุณมีตารางหนึ่งตารางและใช้การแบ่งพาร์ติชันตาราง sql edition ของคุณควรเป็น enterprise ฯลฯ การมีไฟล์ข้อมูลจำนวนมากเป็นสิ่งที่แนะนำสำหรับการปฏิบัติการ IO ที่ดีขึ้น แต่มันก็มีแนวทางปฏิบัติที่ดีที่สุดสำหรับประสิทธิภาพของ sql นั้นไม่มีทางตรงไปข้างหน้า ...

— AmmarR

บางทีมุมมองแบบพาร์ติชันอาจใช้งานได้

จากการใช้บทความ MSDN Partitioned View :

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

ฉันไม่แน่ใจว่ามันแตกต่างจากตารางการแบ่งที่ AmmarR ให้ข้อมูลเกี่ยวกับคำตอบของเขา

— อดัม Porad
แหล่งที่มา