Как я должен обслуживать ZIP-страницы?

Общие сведения.
Наше программное обеспечение создает отчеты для клиентов в обычных подозрительных форматах (HTML, PDF и т. д.), и каждый отчет может содержать диаграммы и другую графику, уникальную для этого отчета. Для PDF-файлов все хранится в одном месте — в самом PDF-файле. HTML сложнее, так как отчет в основном представляет собой сумму более чем 1 файла. Файлы доступны по HTTP через Tomcat.

Проблема.
Я действительно хочу иметь аккуратную среду и упаковать HTML-отчеты в один файл. Есть MTHML, Data URI, несколько форматов для рассмотрения. Это отличное question утверждает, что, учитывая отсутствие межбраузерной поддержки этих форматов, ZIP является отличным решением. Это привлекательно для меня, так как я также могу предложить zip для загрузки в качестве опции «HTML-отчет, который вы можете отправить по электронной почте». (В прошлом пользователи жаловались на потерю графики при отправке HTML-отчетов по электронной почте.)

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

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

Может ли кто-нибудь подсказать, хорошо это или плохо, и предложить альтернативное решение?

Изменить для получения дополнительной справочной информации!
Отчеты должны сохраняться на сервере. Нашими клиентами являются пользователи на сайтах, и видимость одного отчета может быть такой же широкой, как у всех на сайте. В процессе создания пользователь выбирает критерии для отчета и отправляет его для создания на сервер. Данные извлекаются из базы данных и создается документ. Заполнительная запись попадает в базу данных, а сами документы сохраняются где-то на файловом сервере. Это часть «документы на файловом сервере», которую я хотел бы сделать более аккуратной — заархивирование также означает использование меньшего дискового пространства!. Созданный отчет становится доступен всем, кто может его просмотреть.


java zip tomcat multipart webpage
person banjollity    schedule 02.03.2009    source источник

Ответы (3)


arrow_upward
1
arrow_downward

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

Не зная о вашей архитектуре, я бы предположил такой подход:

  • Отчет по запросам пользователей
  • Сервер отображает отчет в формате HTML
  • Возможно, пользователь меняет некоторые параметры, повторяет запрос
  • Сервер отображает отчет в формате HTML (повторяйте, пока пользователь не будет доволен)
  • В каждом HTML-отчете есть ссылка «скачать как zip».
  • Пользователь нажимает на ссылку
  • Сервер регенерирует отчет, сохраняет его в zip-файле и передает пользователю.
  • Пользователь где-то сохраняет zip-файл, отправляет его по электронной почте и т. д. — сервер вообще не задействован

Конечно, это зависит от возможности повторного запуска отчета для создания zip-файла. Вы можете создавать ZIP-файл каждый раз, когда создаете какой-либо HTML-код, но это расточительно, если вам не нужно это делать, и требуется очистка и т. д.

Возможно, я вас неправильно понял... если это звучит неуместно, не могли бы вы обновить свой вопрос?

РЕДАКТИРОВАТЬ: Хорошо, увидев обновление вашего вопроса, у меня возникнет соблазн хранить файлы для каждого отчета в отдельном каталоге (например, используя GUID в качестве имени каталога). Многие файловые системы поддерживают сжатие на уровне файловой системы, поэтому «преждевременное архивирование», вероятно, не сэкономит много места на диске и затруднит извлечение отдельных файлов. Затем, если пользователь запрашивает zip-файл, вам просто нужно создать zip-файл в этот момент, возможно, просто в памяти, прежде чем его обслуживать.

person Jon Skeet    schedule 02.03.2009
comment
@Jon: сколько у тебя пальцев на одной руке? Это уже N-й раз, когда ты опередил меня, отвечая так быстро (где N - это довольно много) :) - person tehvan; 02.03.2009
comment
Отчеты не генерируются каждый раз, когда они обслуживаются — они должны сохраняться в файловой системе сервера неопределенное время, и это должно быть максимально аккуратным и компактным. Я подправил вопрос. - person banjollity; 02.03.2009

arrow_upward
1
arrow_downward

Созданный отчет становится доступен всем, кто может его просмотреть.

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

Один из способов сделать это — разработать способ хеширования параметров вместе таким образом, чтобы разные комбинации параметров (которые приводят к разным отчетам) хэшировали до разных значений. затем вы можете использовать этот хэш в качестве ключа в большой кеш отчетов, хранящихся на диске в zip (может быть, имя файла является хэшем?)

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

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

person Chii    schedule 02.03.2009
comment
Все это делается, за исключением того, что HTML-отчеты хранятся как составные части, а не в виде zip-архива. Мой вопрос заключался в том, является ли использование zip хорошей идеей или нет. Извините, если я не совсем правильно сформулировал этот момент! :) - person banjollity; 02.03.2009
comment
ах - ну, я полагаю, нет ничего плохого в том, чтобы застегнуть его. это очень индивидуальный вопрос. Но вы упомянули, что лучше использовать меньше места на диске - если архивирование не имеет побочных эффектов, таких как потребление мощности процессора (потому что у вас много?), тогда я не вижу ничего плохого. - person Chii; 04.03.2009

arrow_upward
0
arrow_downward

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

person mP.    schedule 02.03.2009