บางวรรณกรรมเกี่ยวกับการบีบอัดข้อมูล SQL Server ฉันอ่านว่าค่าใช้จ่ายในการเขียนเพิ่มขึ้นประมาณสี่เท่าตามปกติ ดูเหมือนว่านี่เป็นข้อเสียเปรียบหลักของการบีบอัดข้อมูลซึ่งหมายความว่าสำหรับฐานข้อมูลการเก็บถาวรแบบอ่านอย่างเดียวประสิทธิภาพจะดีขึ้นด้วยการใช้การบีบอัดข้อมูลที่เต็มหน้า 100%
- ข้อความข้างต้นเป็นจริงหรือไม่
"การเปลี่ยนแปลง" หลักระหว่างการบีบอัดข้อมูลกับอะไร (สำหรับการอ่าน)
- "CPU + x%"
- "IO -y%"?
- หน้าแยกเกิดขึ้น?
- การใช้งาน tempdb?
- การใช้ RAM?
- และสำหรับการเขียน?
สำหรับวัตถุประสงค์ของคำถามนี้คุณสามารถ จำกัด บริบทเป็นการบีบอัดระดับหน้าของฐานข้อมูลขนาดใหญ่(> 1TB)แต่ยินดีต้อนรับความคิดเห็นเพิ่มเติมเสมอ
อ้างอิง:
บล็อก SQL Server Storage Engine (สถานการณ์สมมติ DW แสดงให้เห็นว่าการบีบอัดมีประโยชน์มาก)
การบีบอัดข้อมูล: กลยุทธ์การวางแผนกำลังการผลิตและวิธีปฏิบัติที่ดีที่สุด
วิธีการที่มีรายละเอียดมากขึ้นในการตัดสินใจว่าจะบีบอัดอะไรเกี่ยวข้องกับการวิเคราะห์คุณสมบัติเวิร์กโหลดสำหรับแต่ละตารางและดัชนี มันขึ้นอยู่กับสองตัวชี้วัดต่อไปนี้:
U: เปอร์เซ็นต์ของการดำเนินการอัปเดตบนตารางดัชนีหรือพาร์ติชันเฉพาะเมื่อเทียบกับการดำเนินการทั้งหมดบนวัตถุนั้น ยิ่งค่าของ U ต่ำลง (นั่นคือตารางดัชนีหรือพาร์ติชันถูกอัพเดตนาน ๆ ครั้ง) ผู้สมัครที่ดีกว่าสำหรับการบีบอัดหน้า
S: เปอร์เซ็นต์ของการดำเนินการสแกนบนตารางดัชนีหรือพาร์ติชันสัมพันธ์กับการดำเนินการทั้งหมดบนวัตถุนั้น ยิ่งค่าของ S สูงขึ้น (นั่นคือตารางดัชนีหรือพาร์ติชั่นส่วนใหญ่จะถูกสแกน) ยิ่งมีการสแกนมากเท่าไรก็จะยิ่งเหมาะสมสำหรับการบีบอัดเพจ
ทั้งสองข้อข้างต้นแสดงให้เห็นอย่างเอนเอียงไปสู่การแนะนำการบีบอัดหน้าสำหรับฐานข้อมูลแบบ DW (การดำเนินการแบบอ่านอย่างละเอียด / เอกสิทธิ์และมีข้อมูลขนาดใหญ่)