Чи може таргетування файлів покращити стиснення?


9

Чи може націлювання на пучок файлів разом покращити стиснення зі стандартними інструментами, наприклад, gzip, bzip2, xz?

Я давно вважав, що це так, але ніколи цього не перевіряв. Якщо у нас є 2 копії одного і того ж 20 Мбіт-файлу випадкових байтів, націлених разом, розумна програма стиснення, яка розуміє це, може стиснути весь тарбол майже до 20 Мбіт.

Я просто спробував цей експеримент, використовуючи gzip, bzip2 та xz для стиснення 1) файлу випадкових байтів, 2) тарболу з двох копій цього файлу та 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 випадкового файлу можна стиснути навпіл.
Праксеоліт

"Випадковий" вміст файлу є проблемою. Вони нестислимі. Скористайтеся двома різними великими текстовими файлами, щоб отримати краще уявлення. Тут пов'язана ідея "нормалізована різниця стиснення". Ви можете поглянути на ims.cuhk.edu.hk/~cis/2005.4/01.pdf, щоб побачити, з якими проблемами ви можете зіткнутися під час такого тестування.
Брюс Едігер

Відповіді:


11

Ви проти "блочного розміру" компресора. Більшість програм стиснення розбиває вхід на блоки та стискає кожен блок. Здається, що розмір блоку bzip досягає лише 900 Кб, тому він не побачить жодного шаблону, який займе більше 900 К байт.

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" знайде до 32 Мб шаблонів, а "xz -9" - до 64 Мб. Але будьте обережні, скільки оперативної пам'яті потрібно, щоб виконати стиснення (і декомпресію) ...


1
Так, xz -8 дійсно зменшує тарбол і кота в тесті до 21М.
Праксеоліт

1
Тут є більше, ніж просто розмір блоку. Але повна історія - це не те, що можна пояснити в кількох параграфах на ПП.
lcd047

1
@Praxeolitic Курс на стиснення даних може допомогти.
lcd047

1
@ lcd047 Стиснення - це величезна тема, але питання тут було просто "чому не вдалося цього стиснути", і відповідь, тому що стиснення працює на повторюваних шаблонах, і шаблон, який він хотів, щоб він знайшов більше часу, ніж повторювався будь-який інструмент.
даних

1
Я також думаю, що корисно знати, що "-9" на більшості компресорів командного рядка не означає "намагатися більше знайти шаблони", це означає "розглянути більші пробіли шаблону".
даних

2

Випадкове вміст файлу ви вибрали не є хорошим приклад - пресоване tarfiles буде більше , ніж оригінали. Ви побачите те саме з файлами у вже стискаються форматах (наприклад, багато форматів зображень / аудіо / відео).

Але розміщення декількох файлів із вмістом, що стискається, як правило, створює менший загальний розмір tarfile, ніж при націлюванні їх окремо, особливо коли вміст схожий (наприклад, журнали з однієї програми). Причина полягає в тому, що деякі дані компенсації стиснення за кожним файлом (наприклад, масиви шаблонів для деяких алгоритмів стиснення) можуть бути спільними для всіх файлів у одному і тому ж tarfile.



@kos Це залежить від використовуваного алгоритму та даних. Цитовані 33% - це дуже особливий випадок. За допомогою gzip та bzip2 я вимірював 1000 випадково генерованих файлів 1 Мб, збільшення на <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-го методу, оскільки він стискає кожен файл на льоту, навіть якщо він не може дати малий тарбол.

Наприклад, в нашому резервному режимі резервного копіювання ми зазвичай створюємо резервне копіювання 4 000 000 файлів на загальну суму близько 2 ТБ. Тож перший метод набагато швидший і не потребує додаткових 2 ТБ диска.


Не -zстискає архів (тобто дьоготь)? Зазвичай це вихідне ім'я файлу, що czfзакінчується .tar.gz, щоб підкреслити це.
Jari Keinänen
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.