Хранение и обслуживание множества сжатых архивов с общим базовым содержимым

У меня есть веб-сервер с множеством сжатых архивных файлов (zip-файлов), доступных для скачивания. Я хотел бы значительно сократить объем дискового пространства, которое эти архивы занимают на сервере.

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

Эти архивы на самом деле являются файлами JAR, но детали сжатия, как я полагаю, не имеют значения. Но это объясняет, что обслуживание этих архивов в определенном сжатом формате не подлежит обсуждению: это основная цель сервера.

Само по себе для меня не проблема установить дифференциальное хранилище для содержимого этих архивов, что значительно сократит объем диска, занимаемый набором архивов. Существует множество способов сделать это, используя дельта-кодирование или сжатую файловую систему, которая понимает совместное использование (например, I думаю, что btrfs понимает совместное использование блоков, или я мог бы использовать моментальные снимки, чтобы обеспечить его соблюдение).

Вопрос в том, как создать сжатые ZIP-файлы из этих файлов? Мой сервер имеет очень небольшую вычислительную мощность, определенно недостаточную для воссоздания JAR-файлов на лету из контента для совместного использования блоков.

Есть ли программный способ выставить общий контент на несжатом уровне на сжатый уровень? Легко переводимый в zip инкрементный сжатый формат?

Должен ли я искать решение для кэширования в сочетании с созданием JAR-файлов на лету? Это, по крайней мере, облегчило бы вычислительную боль при создании наиболее востребованных JAR-файлов.

Существует специализированное оборудование это может очень быстро создавать почтовые индексы, но я бы предпочел избежать расходов. Это также не очень масштабируемое решение, так как количество запросов к серверу растет.


person Francois G    schedule 27.03.2013    source источник


Ответы (2)


Если разница в 1% размазана по всем записям во всех jar-файлах, то мало что можно сделать без многократного повторного сжатия.

Если, с другой стороны, разница в 1% сосредоточена в нескольких процентах записей в банках, при этом большинство записей в банках остаются неизменными, тогда есть надежда. Вы можете хранить все отдельные записи jar в их собственных файлах jar на сервере, и для каждого файла jar, который вы хотите обслуживать, просто сохраните список этих отдельных файлов записей jar для объединения. Было бы легко написать быструю утилиту, которая брала бы набор файлов jar и объединяла их в один файл jar. Если его еще нет.

person Mark Adler    schedule 27.03.2013

Один подход, который я использовал в прошлом, заключается в том, чтобы в течение некоторого времени регистрировать фактические запросы на zip-файлы. Если вы обнаружите, что запросы сильно искажены, вы можете использовать кэширование, чтобы уменьшить стоимость создания zip-файлов на лету.

По сути, реализуйте дифференциальное хранилище в соответствии с вашими предложениями. Выделите также некоторую сумму, скажем, 10% от общего объема хранилища для LRU (или любого другого алгоритма замены, который вам нравится) для фактических ZIP-файлов. Каждый раз, когда пользователь запрашивает zip, вы отправляете его из кеша, если он готов, или создаете его на лету и помещаете в кеш, если нет.

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

В противном случае я вижу ваши варианты как:

  1. Используйте дельта-кодирование на диске, а затем измените формат, ожидаемый вашими клиентами для ответов. Например, вместо zip вы можете предоставить им формат, который в основном представляет собой биты файлов с дельта-кодированием, которые им нужны для восстановления файла. На стороне сервера вы экономите большую часть работы, так как вы просто передаете файлы более или менее неизмененными с диска, а затем клиент должен собрать их вместе (существующий клиент уже должен разархивировать файлы, так что, возможно, это не неоправданное бремя).

  2. Внимательно изучите формат .zip и храните свои файлы особым образом, который выполняет большую часть работы .zip заранее. Например, что-то вроде дельта-кодирования, но с фактической сложной частью поиска совпадений, хранящейся на диске, так что кодирование файла может быть очень быстрым процессом. Однако для этого потребуется кто-то с глубоким знанием формата zip для проектирования.

person BeeOnRope    schedule 19.02.2016