Привет!
Есть файлик extallor.json
Его масса тела равна 30 МБ
Вот спрашивается, что бы вы сделали, если бы вам надо было это всё распарсить и занести данные в базу? Какие методы, средства использовали бы?
я гуглил, нашёл эту разработку. Но установить не смог,
composer require salsify/json-streaming-parser
не смог я установить её. с composeroм на хостинге траблы
Карлиндоу Мэрлифи, вполне возможно: например, по дефолту ограничена вложенность. а может в лимиты по памяти или времени упираетесь. а мож ещё чо другое. вариантов - масса.
но зачем гадать, когда можно показать код и описать в чём проблема? а если ещё и файл приложите, то вообще супер.
Просто вынесите задачу на фронт. Создайте небольшую html-страничу, внутри нее кнопку. При нажатии на кнопку, вы скачивайте ваш JSON и парсите его. После парсинга по одному перебирайте ключи первого уровня вложенности и fetch-ем по одному отсылайте данные на сервер, чтобы он из сохранил у себя. Отсылайте по одному и строго один за другим, чтобы не перегружать ваш бэкенд и так, чтобы каждый очередной запрос с гарантией успевал отработать за 60 сек.
Uneasy Hearts Weigh the Most, я бы сам банально запустил парсинг в консоли, там нет ограничений на время выполнения php-скриптов. Однако, если подобной возможности нет, то описанной мной способ наиболее простой - съесть слона по кусочкам. Кстати, экспорт товаров в движках интернет-магазинов обычно так и делается - по кусочкам, чтобы php-скрипты успевали отработать куски до наступления таймаута.
я наконец то нашел одного из представителя тех самых меньшинтсв, из-за которых все чаще появляются сайты, при посещении которых телефон становится горячим. умерьте пыл, вам дай шанс - вы вообще всю логику на фронт вынесете.
DevMan, а что плохого? Например, когда мне надо было написать плагин импорта дохреналлиона картинок, я использовал описанный подход. Просить юзера добавить задачу в крон или лезть в консоль - плохая идея. Юзеру тупо надо чтобы он установил плагин через админку сайта и все работало. Поэтому съесть слона по кусочкам (грузить картинки по одному инициируя куски задач с фронта) самая хорошая идея.
Единственное, где я коскнул в своем ответе это то, что предлагаю JSON разбирать во фронте, ведь в принципе это тоже можно вынести на бэкенд, просто непосредственно импорт в БД надо разбить на мелкие кусочки.
DevMan, ну а ваше решение какое? Это сейчас у юзера вполне умеренные 30 метров, которые легко можно импортировать за один подход практически на любом хостинге. Но что делать, если будет 100, 200 или даже 5000 мегабайт?
DevMan, если браузер и/или сервер зависнет, то потом когда юзер повторно зайдет, то импорт продолжится с того же места, где все прервалось (если логику правильную сделать, ведь мы кусками все импортируем). Аналогично и с отвалом сети.
DevMan, ну тогда это фактически тоже самое получается, просто потоковый парсер мы запускаем через консоль, а мой вариант через браузер - в обеих случаях обработка будет постепенная, разница лишь в способе запуска.
Надим Закиров, да, она будет постепенной.
разница в том, что ваш вариант предполагает загрузку по сети всего файла (возьмём ваши же 5000), его процессинг и при факапах повторение того же самого (не учитывая, что по вашему варианту будет полно ненужных сетевых запросов).
а мой вариант работает на сервере и берёт файл с сервера, и вообще никак не трогает ни сеть вообще, ни браузер у клиента.
разницу не наблюдаете?
DevMan, да, в этом плане ваш вариант лучше, но мой вариант будет работать на любом php-хостинге. Наверное имеет смысл объединить потоковый парсер на сервере и его циклический запуск с фронта. Это если делать не для себя, а для всех, чтобы остальным было удобно запускать и видеть при этом прогресс импорта. Если чисто для себя, то тогда уже плевать, можно просто через консоль.
Надим Закиров, мой вариант тож будет работать на любом хостинге: нет вариант пользовать консоль напрямую, используйте крон.
незачем грузить фронт тем, что ему вообще не нужно. и при этом плодить еще кучу запросов на сервер.
что может быть обработано только на сервере, должно быть обработано только там.
это аксиома.
или вы желаете иметь клиентов, у которых страница будет грузиться десятками секунд или минутами?
DevMan, страница грузится сразу, а далее там банально крутится индикатор прогресса импорта. Или вы про то, что другие пользователи не смогут использовать в это время сайтом? Так это ни чем не отличается от запуска в консоли или через крон - ресурсы на хостинг-аккаунте одинаковые и мотают счетчик процессорного времени одинаково, не важно как ты запускаешь скрипт. Доп. нагрузкой создаваемой пост-запросами каждые 30 сек. можно пренебречь, это просто мизер для любого хостинга.
P. S. Крон не везде есть, как и консоль. Например у бегет есть бесплатной php-хостинг, только там нет крона и доступа к консоли.
Надим Закиров, и сколько же времени потребуется для загрузки в браузер 30мб?
а 300?
а 3000?
а 5000?
а на сервере он уже есть. неужели это не очевидно?
Доп. нагрузкой создаваемой пост-запросами каждые 30 сек. можно пренебречь, это просто мизер для любого хостинга.
рили?
вы считаете что несколько десятков или дестяков тысяч запросов на сервер, когда можно без них – это норм?
особенно, когда сервер должен еще что–то делать?
DevMan, воу-воу полегче. Я же признал выше, что фронт грузить парсингом не обязательно. Фронт просто будет инициировать периодический запуск php-скрипта, который по кускам парсит json с сервера и раскладывает по таблицам в БД.
DevMan, фронт нужен для удобства использования, как вы не понимайте. Если вот это решение по импорту оформлять в виде модуля к какому-нибудь CMS, то запуск через консоль или крон неприемлема.
Надим Закиров, она отлично приемлема: отправить с фронта задание бэку.
всё на этом. остальным рулит только и исключительно бэк.
фронту остаётся только периодически спрашивать бэк "готово ли".
DevMan, хорошо. Возьмём ситуацию, когда некий плагин установленный на неком php-движке и на неизвестном хостинге хочет что-то импортировать в БД. Каким образом это плагин сможет создать задачу в кроне на неизвестном хостинге, при этом не заебывая пользователя, что бы тот вручную добавил задачу? Так как хостинг неизвестный, у нас время выполнения скриптов может быть ограничено и скорее-всего ограничено хостером. И не факт, что есть доступ к консоли.
Надим Закиров, это зависит от движка.
некоторые вообще не имеют подобного функционала, некоторые посредством собственного апи позволяют поставить задачу в фон/очередь и/или в крон.
этот разговор без конкретики – вообще ни о чём.
более того, на среднестатистическом хостинге "не заебывая пользователя" не получится загрузить большой файл. а на некоторых - это тупо невозможно.
DevMan, очень даже возможно. Если бы мне дали дрыщевый хостинг, который едва тянет сайт, я бы все равно смог загрузить туда файл любого объема, банально пересылая и собирая его по кускам. Ладно, не вижу смысла спорить. Как бы вы не убеждали меня, но внести инициатор импорта на фронт - хорошо. Если кто-то заказывает у меня граббер для сайта, всегда так делаю и буду делать.
Надим Закиров, я бы тоже смог. но это не вяжется с вашим же "не заебывая пользователя".
а если вы сами это делаете, то и консоль можно попользовать и в крон закинуть.
короче: не знать/уметь чего–либо – абсолютно нормально. но отстаивать свое незнание – за пределами моего понимания.
DevMan, я не незнание отстаивают, например про то, что существуют потоковые парсеры JSON я не знал и в будущем буду их использовать. Я отстаиваю прежде всего удобство. В один клик воткнуть плагин на сайт и также в один клик начать импорт - это удобно, не надо конечному пользователю объяснять про консоль и крон, все будет работать сразу-сходу, только кнопку нажми.
Надим Закиров, дело тут совсем не в ни "как", а в том, что вы из последних сил пытаетесь найти оправдание своим потугам.
в практически любом современном популярном движке, есть функционал добавления собственных задач в крон.
а где-то даже есть очереди.
а если вам реально захотелось упороться и заявлять "юзер вообще тупой", то спешу заявит - такому юзеру не то что такие файлы нужны, а он даже не сможет их загрузить.
