У меня есть несколько тысяч изображений в папках, которые я хочу заархивировать на внешний диск. При поиске сжатий я наткнулся на возможность установить уровень сжатия "сохранить", что означает, что данные не сжимаются.
Есть ли преимущество в этом, вместо того, чтобы просто оставлять файлы в несжатом виде в папках Windows? Помогает ли это с производительностью вообще для HDD?
Предполагая, что вы можете время от времени получать доступ к отдельным файлам с внешнего диска (скажем, это фотографии из путешествий), нет смысла сжимать их в один архив.
Это не относится к вашему случаю, но в целом есть несколько преимуществ использования метода сжатия «store» для группировки нескольких файлов в один архив для архивирования или передачи по сети:
Хранение несжимаемых данных в архиве не поможет с производительностью жесткого диска, за исключением, в основном, незначительных вещей, таких как ОС, требующая проверки прав доступа к отдельным файлам, по сравнению с одним разрешением для всего архива, занимающего немного больше времени и т.д.
Есть ли преимущество в этом, вместо того, чтобы просто оставлять файлы в несжатом виде в папках Windows?
Да.
Как отмечается в ответе Келтари , людям может быть легче работать с одним файлом, чем со многими. На практике, на самом деле, если у человека есть куча файлов, он часто может просто поместить файлы в одну папку, а затем выполнить файловые операции (например, копировать) над папкой. Общая концепция файла архива, содержащего файлы, и концепция каталога / папки, содержащей файлы, очень похожи. Фактически, эти концепции настолько похожи, что поддержка Microsoft для ZIP-файлов, встроенных в графический интерфейс WinXP (и более новых) и некоторых систем Win9x с добавленным определенным кодом, получила название "Сжатые папки Microsoft" в графическом интерфейсе Microsoft.
Пример: когда я использую SquirrelMail, почтовое веб-приложение, я могу загрузить файл. Я могу загрузить несколько файлов, по одному за раз. Я не могу просто выбрать кучу файлов и загрузить пакет. Если у меня есть 30 файлов для загрузки, я могу просто попросить 7-Zip сжать файлы, используя "хранилище", чтобы я не тратил кучу времени, пытаясь сжать данные много (если я знаю, что данные не сжимаются), и тогда я могу просто загрузить один (сжатый) файл в SquirrelMail.
Иногда некоторые расширения файлов (например, .exe) могут быть запрещены, в то время как архивы могут быть разрешены (брандмауэрами, защитой от вредоносного ПО, используемой почтовым клиентом и т.д.)
Тем не менее, могут быть и другие преимущества, помимо очевидной "простоты использования" с некоторым программным обеспечением. Если формат файлового архива содержит хэш целостности файла для сжатых данных, то при обращении к данным можно проверить целостность файла. Это может привести к обнаружению ошибок, которые могут не быть обнаружены, если формат файлового архива не использовался.
Конечно, теоретически файловая система может содержать метаданные, в которых хранится хэш файла. Разница здесь в том, что файловые системы обычно не содержат данных такого типа, в отличие от архивов. Таким образом, даже если файловые системы могут иметь эти данные, они, как правило, не имеют (по крайней мере, традиционно для многих старых типов файловых систем).
Еще одна причина, по которой метод "хранения" обычно реализуется архивным программным обеспечением, заключается в том, что его очень легко программировать. Таким образом, есть небольшой недостаток в том, чтобы сделать его доступным вариантом.
Если резервное копирование данных, то архив обычно будет содержать метку времени, которая может быть простым способом отметить время, когда включенные файлы старше, чем. Каталоги / папки могут не иметь одинаковые временные метки. Или они могли бы. С различными типами файловых систем (например, NTFS против exFAT против Ext3 против Btrfs против ISO9660) и различными операционными системами, реализующими эти файловые системы, и иногда с типами файловых систем, имеющих несколько дат (создание / изменение / доступ), люди могут не склонны доверять что дата каталога фактически отражает, когда содержимое обновлялось (вместо некоторого другого значения, например, когда каталог был создан, переименован или изменились разрешения, но не обязательно изменение данных). Временная метка архивного файла, особенно если это время является частью имени файла, обычно заслуживает доверия.
Помогает ли это с производительностью вообще для HDD?
Надеюсь, что нет. В конце концов, такие хранимые файлы обычно имеют накладные расходы (по некоторым данным, называемым "заголовком"), поэтому архивированные данные часто будут немного медленнее, а не быстрее. Однако могут существовать исключения: это может быть быстрее.
Иногда какой-то код может найти файл, что займет много времени (возможно, потому что он в основном сортирует большое количество файлов). После выполнения файловой операции (копирование / удаление / что угодно), поиск следующего файла займет много времени. Таких проблем часто можно избежать, используя программное обеспечение, включая драйверы файловой системы, которые оптимизированы для таких ситуаций. Однако в других случаях такие ситуации были известны. Копирование одного большого файла часто не будет иметь одинаковую стоимость. (Опять же, по крайней мере, исторически, иногда работа с большим файлом может иметь значительные затраты, которые могут быть еще большими.)
Самое большое преимущество использования хранилища, а не сжатия, заключается в том, что хранение происходит быстрее. Это связано с тем, что требуется время для выполнения вычислений, необходимых для сжатия данных.
Большая часть этого восприятия была основана на более старых технологиях. На самом деле сжатие может сэкономить время, если процессор работает достаточно быстро (чтобы сжатие данных не занимало много времени) и если данные сжаты достаточно, чтобы на диск можно было записывать / читать с диска меньше данных. Быстрое сжатие ЦП больших данных плюс медленная запись сжатых данных может быть быстрее, чем медленная запись несжатых данных.
Могут быть и другие факторы, такие как меньшее использование ("износ") более хрупкого оборудования (например, жестких дисков).
Скорость сжатия (и хранения сжатых данных) или хранения (несжатых данных) зависит от: скорости сжатия, эффективности сжатия (насколько меньше становятся данные после сжатия) и скорости записи / чтение большего количества данных. Результаты, как правило, меняются со временем, в зависимости от разницы в скорости процессора, эффективности алгоритма (разные алгоритмы и, возможно, разные опции, используемые для этих алгоритмов) и скорости хранения.
Как правило, декомпрессия часто выполняется намного быстрее, чем сжатие (потому что она просто воссоздает данные на основе известных результатов и не требует большого количества исследований / предположений), поэтому, если вам нужно записать данные один раз, а затем прочитать их много раз сжатие очень часто стоит. В других случаях многие люди не находят преимущества в использовании сжатия.
Поскольку мощность процессора значительно выше, чем в исторические времена, магазин, кажется, привыкнет меньше. (Люди часто терпят затраты по крайней мере на минимальные / быстрые формы сжатия.) Тем не менее, архивные программы (например, 7-Zip) часто хотят поддерживать "хранилище", чтобы люди могли по-прежнему получать доступ (извлекать / изменять) к архивам, использующим технику хранилища, и потому что это могло бы быть полезно для некоторых людей (в старых системах) и поскольку это может быть полезно для других задач (быстрое создание комбинации данных, не тратя время на попытки сжать данные, которые вряд ли будут хорошо сжаты), а также потому, что хранение является простым процессом, поэтому стимулов для его удаления практически нет, опция имеет тенденцию оставаться доступной.
Я предполагаю, что вы спрашиваете о zip-архиваторе.
Установка уровня сжатия для хранения, позволяет поместить все файлы в один архив (файл), но не сжимать его.
Использование архива действительно дает некоторые преимущества. Это облегчает управление пользовательскими файлами. Вы хотите переместить / скопировать / сделать резервную копию этих файлов? Гораздо проще переместить один файл, чем несколько тысяч. Проще говоря, меньше легче управлять, чем больше для человека.
Кроме того, когда дело доходит до сжатия тысяч файлов изображений, вы можете получить небольшое сжатие, если файлы.JPG или любой другой тип уже сжатого файла. Вы бы потратили много времени на их сжатие в единый архив, сэкономив при этом немного места.
Это не предлагает много в способ производительности. Да, один файл быстрее проиндексировать, чем несколько тысяч. Однако индексация происходит не часто, а нескольких тысяч файлов не много.
Несжатые архивы с меньшей вероятностью будут полностью разрушены в случае повреждения данных. Как я уже писал в существующем ответе, 7zip может извлечь все файлы из архива, даже если контрольные суммы для некоторых не совпадают. Разумеется, данные, хранящиеся в поврежденном месте, все равно будут уничтожены, но остальная часть файла, содержащего поврежденный прогон, все еще подлежит восстановлению.
Например, если вы использовали старый метод сжатия LZW, все данные файла после поврежденного раздела было бы невозможно восстановить. Даже если бы нулевым был только один байт, словарь декомпрессора не совпадал бы со словарем компрессора, и все, что появилось после ошибки, было бы мусором. (Скорее всего, декомпрессор сломается.) Другие алгоритмы сжатия могут быть в меньшей степени чувствительны к повреждению, но спасти несжатый архив даже вручную можно тривиально.
На самом деле у архивов есть еще одно преимущество перед "обычными" папками. Если вам случится поломка вашего диска или любая другая причина использовать низкоуровневое средство восстановления файлов (например, TestDisk+PhotoRec), вы будете рады восстановить "связные" архивы вместо испорченных файлов, не обращая внимания на структуру папок.
только добавляя к другим ответам. Если несколько элементов файла поместятся в один и тот же "кластер" (количество блоков, в которое записывается файловая система), он будет использовать меньше дискового пространства.
Каждый элемент файла хранится в отдельных кластерах в системах FAT и NTFS. Если файл занимает только 1,2 кластера, он будет использовать 2 кластера. Если сгруппированный файл занимает 120,2 кластера, для его хранения потребуется 121 кластер. Кластеры файловой системы.
Если элементы сгруппированы как один архив, база данных, zip, образ диска и сохранены как один файл, этот один файл будет занимать кластеры, чтобы сохранить его в меньшем количестве потерянного пространства при группировании в один файл.
Каждый файл будет иметь небольшое количество потерянного пространства, один огромный файл также будет иметь только одно небольшое количество потерянного пространства.
Чтобы лучше и проще обнаружить это пространство использования кластера, (в окнах) задайте свойства для набора файлов или папок и просмотрите "размер" и "размер на диске". Размер на диске представляет собой общее пространство кластера, необходимое для хранения. файлы, включая потерянное пространство. Чем меньше размер кластера, тем меньше отходов.
С другой стороны, меньшие размеры кластеров, как правило, медленнее для больших данных. зависит от того, как вы устанавливаете размер кластера, или от того, какой размер вы указали для размера / типа данных, которые будут храниться в этом разделе.
В большинстве сценариев с распространенными на сегодняшний день данными, данные уже используют некоторые формы сжатия. Менее целесообразно сжимать и создавать "зависимые" элементы архива, которые с использованием сжатия или нет сложнее восстановить части и фрагменты.
Пример Попытка исправить поврежденную базу данных с ошибкой 2%, vrses восстанавливает 98% ваших файлов как отдельные элементы. (восстановление базы данных может быть грязным или иметь программное обеспечение для этой цели).
Если данные не предназначены для конкретного архивирования (это метод резервного копирования) или для простой передачи через Интернет, упакованы для распространения или если данные могут быть сильно сжаты, обычно лучше хранить отдельные элементы файла, а не упакованные сгруппированными или дополнительно сжатый или даже зашифрованный, если это не обязательно. Меньше сложностей (зависимостей), меньше программного обеспечения и работы, необходимой для упаковки и распаковки, лучший / более простой шанс восстановления его частей при сбое.
Давайте возьмем пример использования процедур сравнения для 1000 меньших файловых элементов или 1 огромного архива. скажем, ваша процедура сравнения говорит, что есть 3 бита данных, которые являются неверными на любом из них. В одном случае у вас есть 3 плохих файла из 1000, в сгруппированном случае у вас есть 1000 файлов в группе, что-то не так с этим :-)
Полное необоснованное добавление каких-либо осложнений к данным не помогает пользователю понять, что там, резервное копирование в другие источники, гарантировать, что оно никогда не было повреждено, или попытаться восстановить то, что из него можно восстановить, если что-то не получается.
Один непрерывный блок любых последовательных данных (сначала необходимо выполнить полную дефрагментацию) быстрее обеспечивает доступ к этим данным на жестком диске. Любые дополнительные процедуры, которые должен пройти компьютер, различаются по работе, необходимой для их выполнения, и по возможности, насколько это может быть быстрее.
Сжимаемые файлы могут потенциально (намного) считываться быстрее, с необходимостью распаковки, даже если для этого требуется гораздо больше работы.
Файлы, которые не имеют большого дополнительного уменьшения размера (уже сжаты), просто будут выполнять больше работы и будут более сложными. Это будет зависеть только от того, куда вы хотите отправиться сегодня, если это будет выгодно для вас, учитывая, что это также может быть больше работы и меньше доступа / визуального для пользователя.
Доступ к базам данных, архивам, образам дисков и другим огромным блокам объединенных небольших данных, сжатых или нет, может осуществляться быстрее, последовательно, а также с использованием процессов ЦП, предназначенных для работы со многими небольшими элементами более эффективным или более быстрым (используя работу) способом. Где бы мы были без баз данных? некоторые вещи будут ужасно медленными и неорганизованными путаницами.
Вывод: IMO Если нет серьезной необходимости сжимать или шифровать или группировать, или упаковывать, если нет необходимости в распределении, или в способе архивирования и резервного копирования в качестве другой копии, уже сжатые данные должны иметь меньше сложностей, а не больше. Экономия места должна быть уменьшена с правильным размером кластера. Скорость должна быть уменьшена при правильной дефрагментации. Всякий раз, когда есть повреждение или необходимость восстановить данные, или даже понять это, может быть лучше, если это просто.
Для бизнеса, а также для доступа к Интернету и базам данных, упаковки и распространения используемые методы являются отличными, быстрыми, полезными и управляемыми.
Для обычных пользователей, хранящих свои уже сжатые фотографии и видео, вместо этого именно резервные копии и несколько копий этих данных всегда будут важнее, чем просто упаковать их для скорости или даже для экономии дискового пространства.
Поэтому сделайте резервную копию, прежде чем беспокоиться о том, что это будет немного быстрее.
