Отправка больших файлов по HTTP
У меня есть клиент PHP, который запрашивает файл XML через HTTP (т.е. загружает файл XML через URL-адрес). На данный момент размер XML-файла составляет всего несколько КБ. Проблема, которую я могу предвидеть, заключается в том, что XML станет размером в несколько мегабайт или гигабайт. Я знаю, что это огромный вопрос и, вероятно, существует множество решений, но какие идеи у вас есть для передачи этих данных клиенту?
Спасибо!
Ответы 11
Gallery2, которая позволяет загружать фотографии через http, позволяет настроить несколько параметров php, post_max_size и upload_max_filesize, чтобы разрешить загрузку большего размера. Возможно, вы захотите изучить это.
Мне кажется, что при публикации больших файлов возникают проблемы с тайм-аутом браузера и т.п., но с другой стороны, это лучше работает с прокси-серверами и брандмауэрами, чем использование другого протокола загрузки файлов.
Не обращая внимания на то, насколько хорошо браузер может или не может обрабатывать XML-файл размером в ГБ, единственная реальная проблема, о которой я могу придумать, это то, что время выполнения для генерации всего XML больше, чем любые пороговые значения времени выполнения, которые установлены в вашей среде.
Спасибо за ответы. Я не упомянул, что передача файла должна быть относительно быстрой (максимум несколько минут, это вообще возможно?). Запрошенный XML будет анализироваться и вставляться в базу данных каждую ночь. XML может быть тем же, что и накануне вечером, или другим. Одно из предложенных решений - заархивировать XML-файл и затем передать его. Таким образом, есть два основных требования: 1. он должен быть относительно быстрым; 2. он должен минимизировать количество операций записи в базу данных.
Одно из предложенных решений - заархивировать XML-файл и затем передать его. но это удовлетворяет только (1)
Есть другие идеи?
Сначала вы сказали, что XML может вырасти до гигабайт, а теперь говорите «максимум несколько минут». Вы не можете сделать и то, и другое.
исходя из вашего варианта использования, я определенно предлагаю сначала заархивировать данные. Кроме того, вы можете захотеть хэшировать файл md5 и сравнить его перед началом загрузки (нет необходимости обновлять, если файл не имеет изменений), это поможет с пунктом №2.
кроме того, можно ли просто отправить уже существующий сегмент XML, а не весь файл?
Отправка сегментов была бы хорошей идеей, и это определенно осуществимо.
отлично, я бы посоветовал хешировать весь файл на обоих концах и сравнивать хеши перед началом передачи. если есть обновления, просто отправьте сегмент (сжатый, как упомянуто), а затем соедините его на «клиенте». если вы не привязаны к XML, возможно, более легкое решение (json?) может быть лучше
Учитывая, что XML создается динамически с вашим PHP, самое простое, что я могу придумать, - это обеспечить автоматическую gzip-архивировку файла веб-сервером, как описано здесь, он предлагает общий подход PHP и решение для Apache httpd.
Кроме того, наличие браузера (что еще может быть PHP-клиентом?) Выполнять такую работу каждую ночь, так как синхронизация данных звучит так, будто где-то еще должно быть гораздо более простое решение.
И, конечно же, в какой-то момент передача «большого количества» данных займет «много» времени ...
"что еще может быть PHP-клиентом?" Другой сервер - вроде soapclient = P
Работая локально, php сможет загружать файлы через интерфейс командной строки, который можно добавить как задание cron.
Есть ли какие-нибудь алгоритмы, которые я мог бы применить для сжатия XML? Как большие файлы, такие как MP3, загружаются за считанные секунды?
ну, это совсем другое дело, в зависимости от скорости загрузки вашего сервера и скорости загрузки пользователя (или других ваших машин) и, конечно же, всех случайных трубок между ними :)
MP3-файлы не имеют размера в несколько ГБ
PHP получение ГБ данных займет много времени и накладных расходов. Еще более заметны изъяны.
Я бы отправил назначение сценарию оболочки (wget с простым отловом ошибок), которого не беспокоит время выполнения, и в случае сбоя, возможно, даже можно было бы повторить попытку по собственному усмотрению.
У меня нет опыта в этом, но, хотя можно использовать exec () или что-то подобное, они, к сожалению, работают модально.
Вызов скрипта с **./test.sh &** заставляет его работать в фоновом режиме и решает эту проблему, я полагаю. Скрипт может легко позволить вашему PHP забрать его резервную копию через wget `http://yoursite.com/continue-xml-stuff.php?id=1049381023&status=0´. Идентификатор может быть именем файла, если вам не нужно восстанавливать потерянные запросы. Статус будет указывать на то, как сценарий закончил обработку запроса.
Вы думали об использовании какой-то системы контроля версий, чтобы справиться с этим? Вы можете использовать его способность вычислять и отправлять только различия в файлах, а также получаете дополнительные преимущества ведения истории версий вашего файла.
Поскольку я не знаю подробностей вашей ситуации, я задам вопрос. Просто для аргументации, должен ли это быть HTTP? FTP намного лучше подходит для передачи больших объемов данных и может быть легко автоматизирован с помощью PHP или Perl.
Это не обязательно должен быть HTTP. Это был первоначальный план, но я могу использовать любой протокол ... FTP может работать. Однако я экспериментирую со сжатием XML, а затем отправляю его по HTTP.
Проблема в том, что он синхронизирует два набора данных. Проблема полностью искажена.
Вам необходимо: а) вести дифференциальный журнал изменений в наборе данных A, чтобы вы могли отправить этот журнал в набор данных B, или б) сохранить две копии набора данных (прошлые ночи и текущий набор данных), а затем сравнить их, чтобы вы затем можно отправить дифференциальный журнал из A в B.
Добро пожаловать в мир репликации.
Проблема с (а) заключается в том, что он потенциально инвазивен для всего вашего кода, хотя, если вы используете СУБД, вы могли бы сделать некоторое ведение журнала через триггеры базы данных, чтобы отслеживать вставки / обновления / удаления и записывать информацию таблицу, а затем экспортируйте соответствующие строки как свой дифференциальный журнал. Но это тоже может быть неприятно.
Проблема с (b) заключается во всем «сравнении базы данных» сразу. Штраф за 100 рядов. Плохо для 10 ^ 9 рядов. Противно мерзко.
На самом деле все это может быть неприятно. Репликация неприятна.
Лучший план - изучить «настоящую» систему репликации, разработанную для конкретных баз данных, которые вы используете (при условии, что вы работаете с базой данных). Что-то, что, возможно, отправляет записи журнала базы данных для синхронизации, а не пытается откатить свои собственные.
Большинство современных СУБД имеют системы репликации.
Если вы используете Apache, вы также можете рассмотреть Apache mod_gzip. Это должно позволить вам автоматически сжимать файл, и распаковка также должна происходить автоматически, если обе стороны принимают сжатие gzip.
У браузеров не должно быть проблем, я использовал HTTP для загрузки файла размером 3 ГБ в одно из моих приложений в прошлом. Это заняло большую часть дня, но в конце концов добралось до цели.