tarring ไฟล์สามารถปรับปรุงการบีบอัดได้หรือไม่?


9

การรวมกลุ่มของไฟล์เข้าด้วยกันสามารถปรับปรุงการบีบอัดด้วยเครื่องมือมาตรฐานเช่น gzip, bzip2, xz ได้หรือไม่?

ฉันคิดมานานแล้วว่าเป็นกรณีนี้ แต่ไม่เคยทดสอบเลย หากเรามีไฟล์ขนาด 20Mb เดียวกันซึ่งสุ่มจากไบต์สุ่มรวมกัน 2 ชุดโปรแกรมบีบอัดที่ชาญฉลาดซึ่งรู้ว่าสิ่งนี้สามารถบีบอัดทั้งลูก Tarball ลงจนเกือบ 20Mb

ฉันเพิ่งลองการทดลองนี้โดยใช้ gzip, bzip2 และ xz เพื่อบีบอัด 1) ไฟล์สุ่มไบต์, 2) tarball ของไฟล์สองสำเนาและ 3) แมวของไฟล์สองชุด ในทุกกรณีการบีบอัดไม่ได้ลดขนาดไฟล์ สิ่งนี้คาดว่าสำหรับกรณีที่ 1 แต่สำหรับกรณีที่ 2 และ 3 ผลลัพธ์ที่ดีที่สุดคือไฟล์ 40Mb สามารถหดได้เกือบ 20Mb นั่นเป็นความเข้าใจที่ยากสำหรับโปรแกรมบีบอัดที่จะมองเห็นโดยเฉพาะอย่างยิ่งเนื่องจากความซ้ำซ้อนอยู่ไกลดังนั้นฉันไม่คาดหวังผลลัพธ์ที่สมบูรณ์แบบ แต่ฉันยังคงคิดว่าจะมีการบีบอัดบางอย่าง

ทดสอบ:

dd if=/dev/urandom of=random1.txt bs=1M count=20
cp random1.txt random2.txt
cat random1.txt random2.txt > random_cat.txt
tar -cf randoms.tar random1.txt random2.txt
gzip -k random* &
bzip2 -k random* &
xz -k random* &
wait
du -sh random*

ผลลัพธ์:

20+0 records in
20+0 records out
20971520 bytes (21 MB) copied, 1.40937 s, 14.9 MB/s
[1]   Done                    gzip -k random*
[2]-  Done                    bzip2 -k random*
[3]+  Done                    xz -k random*
20M random1.txt
21M random1.txt.bz2
21M random1.txt.gz
21M random1.txt.xz
20M random2.txt
21M random2.txt.bz2
21M random2.txt.gz
21M random2.txt.xz
40M random_cat.txt
41M random_cat.txt.bz2
41M random_cat.txt.gz
41M random_cat.txt.xz
41M randoms.tar
41M randoms.tar.bz2
41M randoms.tar.gz
41M randoms.tar.xz

นี่เป็นสิ่งที่ฉันควรคาดหวังหรือไม่

มีวิธีปรับปรุงการบีบอัดที่นี่หรือไม่?


กรณีทดสอบของคุณเป็นตัวอย่างที่ไม่ดี ลองทำการทดสอบของคุณกับไดเรกทอรีแฟ้มข้อความ ~ 100 (จริง)
lcd047

ทำไมเป็นตัวอย่างที่ไม่ดี เรารู้ว่าจะคาดหวังอะไร ไม่สามารถบีบอัดไฟล์สุ่มและ 2 จากไฟล์สุ่มสามารถบีบอัดได้ครึ่งหนึ่ง
Praxeolitic

เนื้อหาไฟล์ "สุ่ม" เป็นปัญหา พวกมันอัดไม่ได้ ใช้ไฟล์ข้อความขนาดใหญ่สองไฟล์เพื่อให้ได้แนวคิดที่ดีขึ้น แนวคิดที่เกี่ยวข้องที่นี่คือ "ความแตกต่างการบีบอัดปกติ" คุณอาจดูที่ims.cuhk.edu.hk/~cis/2005.4/01.pdfเพื่อดูว่าคุณพบปัญหาประเภทใดในการทดสอบประเภทนี้
Bruce Ediger

คำตอบ:


11

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

http://www.bzip.org/1.0.3/html/memory-management.html

gzip ดูเหมือนจะใช้บล็อก 32K

ด้วย xz คุณกำลังโชคดี! จากหน้าคน:

   Preset   DictSize   CompCPU   CompMem   DecMem
     -0     256 KiB       0        3 MiB    1 MiB
     -1       1 MiB       1        9 MiB    2 MiB
     -2       2 MiB       2       17 MiB    3 MiB
     -3       4 MiB       3       32 MiB    5 MiB
     -4       4 MiB       4       48 MiB    5 MiB
     -5       8 MiB       5       94 MiB    9 MiB
     -6       8 MiB       6       94 MiB    9 MiB
     -7      16 MiB       6      186 MiB   17 MiB
     -8      32 MiB       6      370 MiB   33 MiB
     -9      64 MiB       6      674 MiB   65 MiB

ดังนั้น "xz -8" จะพบกับรูปแบบสูงสุด 32MB และรูปแบบ "xz -9" สูงสุด 64MB แต่ระวังว่าต้องใช้หน่วยความจำเท่าใดในการบีบอัด (และขยายไฟล์) ...


1
ใช่ xz -8 ย่อ tarball และ cat ในการทดสอบเป็น 21M
Praxeolitic

1
มันมีมากกว่าขนาดบล็อก แต่เรื่องราวทั้งหมดไม่ใช่สิ่งที่สามารถอธิบายได้ในไม่กี่ย่อหน้าใน SE
lcd047

1
@Praxeolitic หลักสูตรการบีบอัดข้อมูลอาจช่วยได้
lcd047

1
@ lcd047 การบีบอัดเป็นหัวข้อใหญ่ แต่คำถามนี่ก็คือ "ทำไมการบีบอัดนี้ไม่ได้" และคำตอบก็คือการบีบอัดทำงานในรูปแบบการทำซ้ำและรูปแบบที่เขาต้องการให้มันใช้เวลานานกว่า reoccur เครื่องมือใด ๆ ที่กำลังมองหา
dataless

1
ฉันคิดว่ามันมีประโยชน์ที่จะรู้ว่า "-9" ในคอมมานด์คอมเพรสเซอร์ส่วนใหญ่ไม่ได้หมายความว่า "ลองหารูปแบบยากขึ้น" ซึ่งก็หมายถึง "พิจารณาเว้นช่องว่างรูปแบบขนาดใหญ่"
dataless

2

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

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



@kos สิ่งนี้ขึ้นอยู่กับอัลกอริทึมที่ใช้และข้อมูล อ้างถึง 33% สำหรับกรณีที่พิเศษมาก ด้วย gzip และ bzip2 ฉันวัดไฟล์ได้ 1,000 ไฟล์ที่สร้างแบบสุ่ม 1MB เพิ่มขึ้น <1% ในทุกไฟล์
jofel

2

ตามที่ระบุไว้แล้ว:

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

กรณีทดสอบที่ดีกว่านี้อาจเป็น:

cd /var/tmp
tar -zcf test1.tar /usr
tar -cf test2.tar /usr
gzip test2.tar
ls -h

(หมายเหตุ: หวังว่าจะไม่มีตัวยึดใต้/usr!)

คุณสามารถใช้tar -jcfสำหรับการบีบอัด xz แทน

ตอนนี้ถ้าtest2.tar.gzเล็กกว่า test1.tar.gz การทดสอบก็จะสำเร็จ (เช่นการทดสอบไฟล์แล้วการบีบอัดจะดีกว่าการบีบอัดและการทดสอบ) ฉันเดาว่ามันจะเป็นจำนวนมาก (เช่นหลายพันไฟล์) ข้อเสียคือมันอาจจะใช้เวลานานกว่าในการดำเนินการเช่นเดียวกับที่ต้องใช้พื้นที่ดิสก์มากขึ้นเนื่องจากมันจะต้องสร้างไฟล์ tar ทั้งหมดก่อนแล้วจึงบีบอัด นั่นเป็นเหตุผลที่มักจะใช้วิธีที่ 1 แทนเนื่องจากบีบอัดแต่ละไฟล์ทันทีแม้ว่ามันจะไม่ให้ tarball ขนาดเล็กก็ตาม

ตัวอย่างเช่นในการสำรองข้อมูลนอกสถานที่ของเราโดยทั่วไปเราจะทำการสำรองข้อมูล 4,000,000 ไฟล์รวมเป็นประมาณ 2TB ดังนั้นวิธีแรกนั้นเร็วกว่าและไม่ต้องการดิสก์ 2TB เพิ่มเติม


ไม่-zบีบอัดไฟล์เก็บถาวร (เช่น tar) หรือไม่ โดยปกติชื่อไฟล์ที่ส่งออกด้วยczfลงท้ายด้วย. tar.gz เพื่อเน้นนี้
Jari Keinänen
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.