.Tar.gz: Есть ли связь между временем сжатия и распаковки?

361
radschapur

Я сжимаю резервную копию mongodb (~ 500 ГБ) в архив .tar.gz, который занимает время в масштабе часов. Я пытаюсь восстановить эту базу данных на разных машинах для целей тестирования, и мне хотелось бы получить оценку того, сколько времени это займет для каждой машины.

У меня вопрос: можно ли как-нибудь оценить время, которое потребуется для распаковки архива, исходя из того, сколько времени заняло сжатие?

Спасибо

1
Некоторые [тесты] (https://www.rootusers.com/gzip-vs-bzip2-vs-xz-performance-comparison/). Но различия в аппаратном обеспечении между исходными и целевыми машинами могут сильно повлиять на результат xenoid 7 лет назад 1
Интересные результаты, спасибо за ссылку. Большинство машин, с которыми я имею дело, имеют похожее оборудование, поэтому у меня все еще есть идея. Меня больше всего беспокоит декомпрессия, поэтому мне кажется, что gzip - лучший вариант для меня, поскольку декомпрессия примерно в 10 раз быстрее, чем сжатие. radschapur 7 лет назад 1
Я ожидаю, что дисковый ввод-вывод будет узким местом в обоих процессах. Запись, как правило, происходит быстрее, чем чтение, потому что буферизация означает, что записывающему устройству не нужно ждать диска. Barmar 7 лет назад 1

2 ответа на вопрос

0
Stennie

Я не знаю стандартного соотношения сжатия и распаковки, поскольку оно действительно зависит от ваших данных и ресурсов сервера. Предполагая, что все другие ресурсы равны, распаковка обычно происходит быстрее, так как требуется меньше вычислительной работы. Ваша оценка наихудшего случая может совпадать с начальным временем сжатия.

Однако для легкой победы я бы порекомендовал использовать pigzпараллельную реализацию, в gzipкоторой используются преимущества нескольких процессоров и ядер. Если у вас нет только одного доступного ядра, pigzследует значительно сократить время как сжатия, так и распаковки.

Пример использования с tar:

tar -c --use-compress-program=pigz -f data.tgz /path/to/data

Дополнительные примеры см. В разделе StackOverflow: использование многоядерного режима для сжатия / распаковки tar + gzip / bzip .

Спасибо за информацию. Я использовал pigz для сжатия. К сожалению, я собираюсь сжать базу данных только один раз, чтобы реплицировать ее на многие другие серверы, поэтому декомпрессия является главной задачей. Пигз, кажется, не предлагает много улучшений там. radschapur 7 лет назад 0
@radschapur Возможно, `bzip2` и` pbzip2` (параллельный bzip) - лучший вариант? Формат `bzip` кажется более подходящим для параллельной распаковки в обсуждении на: https://github.com/madler/pigz/issues/36. Stennie 7 лет назад 0
0
TOOGAM

На одной и той же машине нет определенного соотношения, и использование нескольких машин (разных типов) может оказать определенное влияние. Сжатие и распаковка активно включают хранение данных (например, «жесткий диск» или «SSD»), процессор и другие компоненты, такие как память.

Как чрезмерное обобщение, распаковка происходит довольно быстро и даже может быть быстрее, чем копирование несжатого объема данных. Сжатие также может быть таким же быстрым, и для чего-то вроде сжатия RLE это может быть. Для zip и gzip обычные реализации медленнее, чем декомпрессия, и вы часто можете выжать еще 5% -15% эффективности сжатия, если вы выбираете более агрессивные варианты сжатия, которые могут занимать в 2-4 раза больше времени.

Разница в значительной степени заключается в том, что сжатие включает в себя некоторое тестирование (иногда называемое «догадкой»), а некоторые тесты бесплодны. Напротив, декомпрессия, как правило, просто следует заранее установленному процессу, так что это происходит относительно быстрее.

Похожие вопросы