Отправка больших файлов через HTTP

Question

У меня есть PHP-клиент, который запрашивает XML-файл по HTTP (то есть загружает XML-файл через URL). На данный момент размер XML-файла составляет всего несколько КБ. Проблема, которую я могу предвидеть, состоит в том, что XML становится размером в несколько МБ или ГБ. Я знаю, что это огромный вопрос и что, возможно, существует множество решений, но какие у вас есть идеи для передачи этих данных клиенту?

Спасибо!

Answer 1

в зависимости от вашего варианта использования, я бы определенно предложил сначала заархивировать данные. Кроме того, вы можете захотеть md5 хешировать файл и сравнить его перед началом загрузки (не нужно обновлять, если файл не имеет изменений), это поможет с пунктом № 2.

также, возможно ли будет просто отправить сегмент XML, который был вместо всего файла?

Answer 2

Игнорирование того, насколько хорошо браузер может или не может обрабатывать XML-файл размером с ГБ, единственная реальная проблема, о которой я могу подумать, это то, что время выполнения для генерации всего XML больше, чем какое-либо выполнение пороги времени, установленные в вашей среде.

• Настройка PHP max_execution_time
• Функция PHP set_time_limit ()
• Директива Apache's TimeOut

Answer 3

Учитывая, что XML создается динамически с вашим PHP, самое простое, что я могу придумать, это убедиться, что файл автоматически распаковывается веб-сервером, как описано здесь , он предлагает общий подход PHP и специфичное для Apache httpd решение.

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

И, конечно, в какой-то момент передача "большого количества" данных займет "много" времени ...

Answer 4

Проблема в том, что он синхронизирует два набора данных. Проблема полностью искажена.

Вам необходимо либо: а) вести дифференциальный журнал изменений в наборе данных A, чтобы вы могли отправить этот журнал в набор данных B, либо b) хранить две копии набора данных (прошлые ночи и текущий набор данных), а затем сравнивать их, чтобы вы могли затем отправить дифференциальный журнал от А до Б.

Добро пожаловать в мир репликации.

Проблема с (a) заключается в том, что он потенциально инвазивен для всего вашего кода, хотя, если вы используете RDBMS, вы можете сделать некоторые записи с помощью триггеров базы данных, чтобы отслеживать вставки / обновления / удаления, и писать информацию в таблицу, а затем экспортируйте соответствующие строки в виде дифференциального журнала. Но это тоже может быть неприятно.

Проблема с (b) заключается в том, что все «сравнение базы данных» происходит одновременно. Штраф за 100 рядов. Плохо для 10 ^ 9 строк. Противный противный.

На самом деле, все это может быть неприятно. Репликация противна.

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

Большинство современных систем СУБД имеют системы репликации.

Answer 5

Если вы используете Apache, вы также можете рассмотреть Apache mod_gzip. Это должно позволить вам автоматически сжимать файл, и распаковка также должна происходить автоматически, если обе стороны принимают сжатие gzip.

Answer 6

Так как я не знаю деталей вашей ситуации, я брошу вопрос там. Просто ради аргумента это должен быть HTTP? FTP намного лучше подходит для передачи больших объемов данных и может быть легко автоматизирован с помощью PHP или Perl.

Answer 7

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

Answer 8

PHP, получающий ГБ данных, займет много времени и потребует много времени. Еще более заметны недостатки.

Я бы - отправил присвоение сценарию оболочки (wget с простым перехватом ошибок), который не беспокоит время выполнения и при неудаче может даже повторить попытку за свой счет.

У меня нет опыта в этом, но хотя можно использовать exec () или что-то подобное, эти печально запускаемые модальные.

Вызов скрипта с **./test.sh &** заставляет его работать в фоновом режиме и решает эту проблему / я думаю. Сценарий может легко позволить вашему PHP восстановить его с помощью wget `http://yoursite.com/continue-xml-stuff.php?id=1049381023&status=0´. Идентификатор может быть именем файла, если вам не нужно возвращать потерянные запросы. Статус будет указывать, как скрипт завершил обработку запроса.

Answer 9

Есть ли какие-нибудь алгоритмы, которые я мог бы применить для сжатия XML? Как загружаются большие файлы, такие как MP3, за считанные секунды?

Answer 10

Спасибо за ответы. Я не упомянул, что передача файла должна быть относительно быстрой (максимум несколько минут, это вообще возможно?). Запрошенный XML-файл будет анализироваться и вставляться в базу данных каждую ночь. XML может быть таким же, как и прошлой ночью, или другим. Одно из предложенных решений - заархивировать XML-файл и затем передать его. Таким образом, есть два основных требования: 1. оно должно быть относительно быстрым 2. оно должно минимизировать количество операций записи в базу данных

Одним из предложенных решений является сжатие файла XML и его передача. но это только удовлетворяет (1)

Есть еще идеи?