У меня есть тонна относительных небольших файлов данных, но они занимают около 50 ГБ, и мне нужно, чтобы они были перенесены на другую машину. Я пытался придумать наиболее эффективный способ сделать это.
Мысли, которые у меня были, заключались в том, чтобы сжать все это, затем rsync и распаковать, полагаться на rsync -z для сжатия, gzip, затем использовать rsync -z. Я не уверен, что было бы наиболее эффективно, поскольку я не уверен, как именно реализован rsync -z. Есть идеи, какой вариант будет самым быстрым?
Вы не можете «сжать все это», так как gzip сжимает только один файл, вы можете создать tar-файл и сжать его, чтобы «сжать все это», но вы потеряете возможность rsync копировать только измененный файл.
Итак, вопрос: лучше ли хранить файл, который мне нужен, в rsync gziped или полагаться на параметр -z rsync.
Ответ, вероятно, заключается в том, что вы не хотите, чтобы файл распаковывался на вашем сервере? Думаю, да, поэтому я не понимаю, как вам удалось сжать файл перед выполнением rsync.
Может быть, вам не нужна возможность rsync для копирования только измененного файла? В этом случае зачем использовать rsync вместо scp файла tar.gz, содержащего ваши данные?
В любом случае, чтобы ответить на вопрос, rsync gzip будет немного менее эффективным, чем gziping файл с помощью gzip. Зачем ? поскольку rsync будет сжимать данные по частям, поэтому меньший набор данных будет использоваться для создания таблицы, которую gzip использует для сжатия, больший набор данных (gzip будет использовать весь файл сразу) даст лучшую таблицу сжатия. Но в большинстве случаев разница будет очень и очень небольшой, но в очень редких случаях разница может быть более важной (если у вас очень большой файл с очень длинными частями, которые много раз повторяются в файле, но далеко друг от друга) (Это очень упрощенный пример)
Если вы копируете данные только один раз, rsync сам по себе не принесет большого успеха. Если вам нравится gzip (или tar + gzip, поскольку у вас много файлов), вы можете попробовать что-то вроде:
tar -cz /home/me/source/directory | ssh target tar -xz --directory /home/you/target/directory
Это даст сжатие, которое вы ищете, и просто скопируйте напрямую, без использования rsync.
@radius, мелочь о том, как gzip работает - gzip представляет собой блочный алгоритм сжатия, причем довольно простой. В таблицу сжатия не входит весь файл - только каждый блок. Другие алгоритмы могут использовать все содержимое файла, и есть несколько, которые используют содержимое нескольких блоков или даже блоков переменного размера. Один интересный пример: lrzip, того же автора, что и rsync!
Итак, в итоге, используя rsync -z скорее всего даст тем же сжатие как gzipв первую очередь - а если вы делаете дифференциальную передачу, лучше из-за rsyncАлгоритм сравнения.
Тем не менее, я думаю, что можно найти этот регулярный scp легко бьет rsync для недифференциальных переводов - потому что это будет иметь гораздо меньше накладных расходов, чем rsyncалгоритм (который будет использовать scp все равно под капотом!)
Если ваша сеть делает стать узким местом, тогда вы захотите использовать сжатие на проводе.
Если ваш диски являются узким местом, поэтому лучше всего использовать потоковую передачу в сжатый файл. (например, netcat с одной машины на другую, поток в gzip -c)
Обычно, если скорость является ключевым фактором, предварительное сжатие существующего файла является расточительным.
TIMTOWTDI, YMMV, IANAL и т. Д.
В соответствии с этот парень просто может быть быстрее использовать rsync -z, хотя я предполагаю, что это было бы так же эффективно, как сжатие каждого файла перед передачей. Это должно быть быстрее, чем сжатие потока tar, как предлагают другие.
На странице руководства:
Note that this option typically achieves better compression
ratios than can be achieved by using a compressing remote shell
or a compressing transport because it takes advantage of the
implicit information in the matching data blocks that are not
explicitly sent over the connection.
Поскольку и scp сжатого файла, и rsync будут занимать очень похожее время передачи, «наиболее эффективным способом сделать это» будет сжатие на лету, а не сжатие и передача.
В дополнение к «стойкости» другие соображения включают:
rsync можно легко перезапустить, если не все файлы будут перенесены.
rsync можно использовать для обслуживания файлов на удаленном компьютере.
local tar или gzip требует локального пространства.
Соображения по использованию порта как для целевой машины, так и для брандмауэров: 1) scp использует порт 22 (по умолчанию), что может быть неприемлемо. 2) порт 873 пользователей rsync (по умолчанию)
Я не уверен, почему радиус ожидает, что исходный плакат НЕ хочет хранить разархивированные файлы.