คำถามติดแท็ก compression

ชื่อที่กำหนดให้กับกระบวนการเข้ารหัสข้อมูลซึ่งใช้จำนวนบิตน้อยกว่าเมื่อเทียบกับการแสดงต้นฉบับ

4
มีการดึงข้อมูลจาก SQL Server ที่ถูกบีบอัดเพื่อส่งข้อมูลหรือไม่?
ดึงข้อมูลจาก Microsoft SQL Server ถูกบีบอัดหรือไม่ หากสิ่งนี้ถูกควบคุมโดยสตริงการเชื่อมต่อมีวิธีง่าย ๆ ที่จะบอกได้หรือไม่ว่าแอพใดกำลังใช้งานอยู่ ฉันกำลังตรวจสอบเครื่องมือวิเคราะห์และปริมาณข้อมูลอาจใช้เวลาสักครู่เพื่อส่งผ่านเครือข่ายของเรา ฉันสงสัยว่าฉันควรคาดหวังว่าประสิทธิภาพจะเพิ่มขึ้นหรือไม่ถ้าเราดึงข้อมูลจากแหล่งข้อมูลที่บีบอัดบนเซิร์ฟเวอร์ระยะไกลเดียวกัน ตราบใดที่เราอยู่ในหัวข้อฉันอยากรู้อยากเห็น: มีการส่งข้อมูลในรูปแบบไบนารีหรือ ASCII หรือไม่? ตัวอย่างเช่นหากค่า12345ถูกสอบถามจากINTคอลัมน์จะมีการส่งค่าเป็นห้าไบต์ 0x31, 0x32, 0x33, 0x34, 0x34, 0x35; สองไบต์ที่จำเป็นสำหรับค่านั้น หรือสี่ไบต์ตามต้องการสำหรับคอลัมน์? เพื่อความชัดเจนฉันเข้าใจว่ามีตัวเลือกเกี่ยวกับการจัดเก็บข้อมูลด้วยการบีบอัดและสำรองข้อมูล ฉันถามเกี่ยวกับวิธีการส่งข้อมูล

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

2
ทางเลือกอื่นในการบีบอัด NVARCHAR (MAX)?
ฉันกำลังพยายามบีบอัดตารางที่มีNVARCHAR(MAX)เขตข้อมูล น่าเสียดายที่rowการpageบีบอัดข้อมูลไม่มีผลกระทบต่อความปรารถนา (บันทึกเพียง ~ 100/200 MB สำหรับตาราง 20 GB) นอกจากนี้ฉันไม่สามารถใช้การบีบอัดที่เก็บคอลัมน์และที่เก็บคอลัมน์ได้เนื่องจากพวกเขาไม่สนับสนุนการบีบอัดNVARCHAR(MAX)ฟิลด์ มีใครบอกได้ไหมว่าฉันมีทางเลือกอื่น ๆ ที่นี่? ฉันเดาด้วยrowและการpageบีบอัดไม่มีผลเพราะเนื้อหาของNVARCHAR(MAX)คอลัมน์นั้นไม่เหมือนใคร

1
ดัชนีที่บีบอัด SQL Server ยังคงถูกบีบอัดในการสร้างใหม่โดยไม่ระบุการบีบอัดข้อมูลหรือไม่
หลังจากสร้างดัชนี SQL Server อีกครั้งโดยใช้การบีบอัดหน้า ( ALTER INDEX IX1 REBUILD PARTITION = ALL WITH (DATA_COMPRESSION = PAGE)) ให้ทำการสร้างใหม่ในภายหลัง (ตามที่สคริปต์การบำรุงรักษาบางรายการผ่านเกณฑ์การแตกแฟรกเมนต์) จำเป็นต้องระบุการบีบอัดข้อมูลอีกครั้งหรือไม่ มิฉะนั้นดัชนีจะแตกอย่างมีประสิทธิภาพหรือไม่

2
มีวิธีการกำหนดไฟล์ที่แน่นอนที่มีหน่วยการจัดสรรในกลุ่มไฟล์ของหลายไฟล์หรือไม่?
ฉันหวังว่าจะได้รับมุมมองที่ละเอียดว่าไฟล์ฐานข้อมูลใดมีหน่วยการจัดสรรใดสำหรับ HoBT ต่างๆ (ทั้งที่อยู่ในแนวเดียวกันและไม่ได้อยู่ในแนวเดียวกัน) ในฐานข้อมูล แบบสอบถามที่ฉันใช้อยู่เสมอ (ดูด้านล่าง) ให้บริการฉันได้ดีจนกระทั่งเราเริ่มสร้างไฟล์ข้อมูลหลายไฟล์ต่อกลุ่มไฟล์และฉันสามารถที่จะหาวิธีที่จะได้รับรายละเอียดเป็นระดับกลุ่มไฟล์ select SchemaName = sh.name, TableName = t.name, IndexName = i.name, PartitionNumber = p.partition_number, IndexID = i.index_id, IndexDataspaceID = i.data_space_id, AllocUnitDataspaceID = au.data_space_id, PartitionRows = p.rows from sys.allocation_units au join sys.partitions p on au.container_id = p.partition_id join sys.indexes i on i.object_id = p.object_id …


1
บีบอัดฐานข้อมูล PostgreSQL
ฉันมีฐานข้อมูล PostgreSQL ขนาดใหญ่ที่มีขนาดใหญ่กว่า 500GB ซึ่งใหญ่เกินไป อย่างไรก็ตามมีการบีบอัดฐานข้อมูลลงในขนาดที่สามารถจัดการได้มากขึ้นหรือไม่? ฉันพยายามทำเช่นนี้กับ SquashFS และฐานข้อมูลที่บีบอัดลงไปที่ 177GB แต่ PostgreSQL ต้องการให้ฐานข้อมูลที่มีการเข้าถึงการเขียนและระบบ Squashed เป็นแบบอ่านอย่างเดียว ผู้ใช้ฐานข้อมูลที่มีประสบการณ์มากขึ้นมีข้อเสนอแนะใด ๆ เพื่อบรรลุเป้าหมายนี้หรือไม่? ฐานข้อมูลเก็บข้อมูล GIS สำหรับดาวเคราะห์และจะใช้ภายในระบบที่ปรับใช้ ขณะนี้มันตั้งอยู่บน 1TB SSD แต่ฉันพยายามหลีกเลี่ยงการตบในฮาร์ดไดรฟ์เพิ่มเติมเพียงเพื่อรองรับฐานข้อมูลขนาดใหญ่ ฐานข้อมูลทำงานได้ตามที่ต้องการโดยไม่มีปัญหาฉันเพียงต้องการบีบอัดให้มีขนาดที่จัดการได้มากขึ้นและหลีกเลี่ยงการวางลงในไดรฟ์อื่น

2
ค้นหาขนาดที่ไม่บีบอัดของตารางทั้งหมดในฐานข้อมูล
ใน Dynamics AX มีกลไกการแคชซึ่งสามารถกำหนดตารางให้โหลดลงในหน่วยความจำและแคชได้ แคชนี้ จำกัด จำนวน KB ไว้เพื่อป้องกันปัญหาหน่วยความจำ การตั้งค่าที่ฉันกำลังพูดถึงถูกเรียกentiretablecacheและโหลดทั้งตารางในหน่วยความจำทันทีที่มีการร้องขอบันทึกเดียว จนถึงเมื่อเร็ว ๆ นี้เราใช้สคริปต์บางตัวเพื่อตรวจสอบขนาดของตารางที่มีการตั้งค่านี้เพื่อดูว่าขนาดตารางเกินขีด จำกัด นี้หรือไม่ อย่างไรก็ตามตอนนี้การบีบอัดเริ่มเข้ามาเล่นและสิ่งต่าง ๆ เช่นsp_spaceusedหรือsys.allocation_unitsดูเหมือนจะรายงานพื้นที่ที่ใช้จริงโดยข้อมูลที่บีบอัด เห็นได้ชัดว่าแอ็พพลิเคชันเซิร์ฟเวอร์ทำงานกับข้อมูลที่ไม่มีการบีบอัดดังนั้นขนาดข้อมูลบนดิสก์ใน SQL Server นั้นไม่เกี่ยวข้อง ฉันต้องการขนาดจริงข้อมูลที่ไม่มีการบีบอัดจะมี ฉันรู้เกี่ยวกับsp_estimate_data_compression_savingsแต่อย่างที่ชื่อบอกนี่เป็นเพียงการประมาณ ฉันต้องการมีขนาดที่ถูกต้องที่สุด วิธีเดียวที่ฉันคิดได้ก็คือ SQL แบบไดนามิกที่ซับซ้อนที่สร้างตารางที่ไม่มีการบีบอัดด้วยโครงสร้างเดียวกับตารางที่ถูกบีบอัดแทรกข้อมูลที่บีบอัดในตารางเงานั้นแล้วตรวจสอบขนาดของตารางเงานั้น จำเป็นต้องพูดว่านี่เป็นบิตที่น่าเบื่อและใช้เวลาสักครู่ในการรันบนฐานข้อมูลหลายร้อย GB Powershell อาจเป็นตัวเลือก แต่ฉันไม่ต้องการวนซ้ำทุกตารางเพื่อดำเนินการselect *กับพวกเขาเพื่อตรวจสอบขนาดในสคริปต์เนื่องจากอาจทำให้แคชล้นและอาจใช้เวลานานเกินไป กล่าวโดยย่อฉันต้องการวิธีเพิ่มขนาดสำหรับแต่ละตารางเนื่องจากจะไม่มีการบีบอัดและมีการแตกแฟรกเมนต์ออกมาจากสมการที่นำเสนอไปยังแอปพลิเคชันหากเป็นไปได้ ฉันเปิดกว้างกับแนวทางที่แตกต่างกัน T-SQL เป็นที่ต้องการมากกว่า แต่ฉันไม่ได้ต่อต้าน Powershell หรือวิธีการสร้างสรรค์อื่น ๆ สมมติว่าบัฟเฟอร์ในแอปพลิเคชันคือขนาดของข้อมูล bigint มักมีขนาดเท่ากับ bigint เสมอและประเภทข้อมูลอักขระคือ 2 ไบต์ต่ออักขระ (unicode) …

1
ประโยชน์ของ Barracuda และการบีบอัด
ฉันได้อ่านเกี่ยวกับรูปแบบไฟล์ของ MySQL Antelope และ Barracuda เมื่อไม่นานมานี้และฉันสงสัยว่าฉันจะได้รับประโยชน์จากการมี Barracuda และการบีบอัดข้อมูลหรือไม่ เซิร์ฟเวอร์ของฉันใช้แอนทีโลปอยู่เพราะเป็นค่าเริ่มต้นของ MySQL ฉันมีปัญหากับหน่วยความจำหลายครั้งเนื่องจากฐานข้อมูลขนาดใหญ่ที่ฉันมี ฐานข้อมูลของฉันเพิ่มขึ้นทุกวัน ดูเหมือนว่าการบีบอัดจะให้ประโยชน์กับคนไม่กี่คนเช่น: http://www.mysqlperformanceblog.com/2008/04/23/real-life-use-case-for-barracuda-innodb-file-format/ ฉันเข้าใจว่าหน่วยความจำและพื้นที่ดิสก์สามารถลดลงได้ แต่ฉันไม่แน่ใจว่าฉันเข้าใจสิ่งนี้หรือไม่ (อ้างอิงจากบทความ): "~ 5% โหลด CPU ตามด้านบน (จาก 80-100% ส่วนใหญ่รอ I / O) 0.01 เวลาค้นหาเฉลี่ยวินาทีโดยคีย์หลัก (จาก 1-20 วินาทีก่อนการแปลง) " ฉันคิดว่าสองสิ่งนี้จะไม่ดีขึ้นเพราะถ้าข้อมูลถูกบีบอัดเซิร์ฟเวอร์ต้องคลายการบีบอัดเพื่อรับข้อมูลต้นฉบับอีกครั้งดังนั้นจึงไม่เหมาะสมที่การใช้งาน CPU จะเพิ่มขึ้นใช่ไหม สิ่งนี้มีประโยชน์กับคุณในแอปพลิเคชันแบบอ่าน / เขียนหรือไม่ คุณจะแนะนำให้ฉันเปลี่ยนเป็น Barracuda และการบีบอัดไหม คุณตระหนักถึงปัญหาของ Barracuda หรือไม่? ดูเหมือนว่าคำตอบของคำถามต่อไปนี้จะกล่าวถึงปัญหาบางอย่าง แต่เนื่องจากมาจาก 2011 ฉันจะบอกว่าได้รับการแก้ไขแล้วในตอนนี้: …

4
ทางเลือกในการสำรองข้อมูลเครือข่าย
ในสภาพแวดล้อมของเราเรามีเซิร์ฟเวอร์บางตัวที่อยู่ในกลุ่ม Always On Availability และบางเซิร์ฟเวอร์เป็นแบบสแตนด์อโลน ปกติแล้วเราจะสำรองข้อมูลไปยังเครือข่ายที่ใช้ร่วมกัน แต่เมื่อไม่นานมานี้เราได้สังเกตเห็นว่าเมื่อฐานข้อมูลมีขนาดใหญ่ขึ้นเรื่อย ๆ เวลาที่ใช้ก็นานขึ้นซึ่งจะทำให้เครือข่ายทั้งหมดช้าลง สคริปต์ของ Ola hallengren กำลังถูกใช้กับการบีบอัดและยังแยกไฟล์สำรองข้อมูล ฉันกำลังทำการสำรองข้อมูล "เต็มรูปแบบ" ทุกวันเท่านั้น การสำรองข้อมูลจะไปที่ไดรฟ์เครือข่ายแบ่งปัน EMC isilon ฉันไม่เคยพอใจกับ EMC DD Boost ทางเลือกเดียวคือทำการสำรองข้อมูลในเครื่องแล้วคัดลอกไปยังเครือข่ายเดียวกัน มีวิธีที่มีประสิทธิภาพนอกเหนือจากข้างต้นหรือไม่

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

1
ค่าใช้จ่ายของแถวเมื่อใช้การบีบอัดหน้า?
ฉันสร้างตารางที่มี 650 คอลัมน์ (19,4) คอลัมน์ เมื่อฉันเปิดการบีบอัดหน้าโดยเรียกใช้ ALTER TABLE fct.MyTable REBUILD WITH (DATA_COMPRESSION = PAGE); ฉันเข้าใจ ข่าวสารเกี่ยวกับ 1975, ระดับ 16, สถานะ 1 ดัชนี 'PK_Mytable' ความยาวแถวเกินความยาวสูงสุดที่อนุญาตได้ของ '8060' ไบต์ แต่ 650 ครั้ง 9 ไบต์มีเพียง 5850 ไบต์ซึ่งค่อนข้างไกลจากขีด จำกัด ที่ระบุไว้ที่ 8060 ไบต์ เซิร์ฟเวอร์กำลังเรียกใช้ Windows 2012 r2 ด้วย SQL Server 2016 SP1 CU2 ค่าใช้จ่ายของแถวเมื่อใช้การบีบอัดหน้า? นี่คือรหัสเพื่อแสดงสิ่งที่ฉันหมายถึง: /* …

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

1
อะไรคือความแตกต่างระหว่างการบีบอัดข้อมูลบน PK กับบนโต๊ะ?
การบีบอัดข้อมูลสามารถตั้งค่าบนโต๊ะ: CREATE TABLE dbo.SomeTable( SomeId [bigint] NOT NULL, OtherId [bigint] NOT NULL, IsActive [bit] NOT NULL, CONSTRAINT [PK_Some] PRIMARY KEY CLUSTERED ( SomeId Desc ) ) ON SomePartitionScheme(SomeId) WITH (DATA_COMPRESSION=PAGE) และสามารถกำหนดได้บนคีย์หลัก: CREATE TABLE dbo.SomeTable( SomeId [bigint] NOT NULL, OtherId [bigint] NOT NULL, IsActive [bit] NOT NULL, CONSTRAINT [PK_Some] PRIMARY KEY …

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

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