С Наступающим всех!
Вводные данные:
Есть текстовый файл (50Мег, 110тыс строк). В каждой строке подготовленные данные одной записи в БД.
Пробовал :
1. просто натравить скрипт (открываем файл, считываем строку, апдейтим mySQL, считываем след. строку, апдейтим mySQL и т.д.).
Уперлись в предел выполнения скрипта по времени. Обломс.
2. считать все данные в массив, который через CRON QUEUE будет потихоньку обработан за несколько итераций (60секунд на каждую, на пример).
Уперся в ограничение памяти - не лезет мой массив в память.
Думаю с какой стороны подойти к этому вопросу.
Что подскажете?
Спасибо.
Комментарии
Вот человек на днях модуль написал, может поможет - http://xandeadx.ru/blog/drupal/869
насколько я въехал в этот модуль, там непосредственно в функцию обработчик передается текущий номер записи в массиве, под которым у меня будет номер строки в текстовом файле. Так получается каждый раз мне придется этот файл открывать, позиционировать на $i строчку, считывать ее, обновлять mySQL и закрывать файлик. Это будет одна итерация. и таких у меня будет 100тыс. нерационально как-то.
Благодарю, Good Boy ! Обязательно буду изучать все варианты.
Если файл разбить нельзя на мелкие, то
cron + https://api.drupal.org/api/drupal/includes%21common.inc/function/drupal_...
Тоже об этом думал, нарезать штук на 20 и крон запускать каждые 3 минуты наверное. Тот при запуске ищет маленькие куски, нашел кусок (любой) - обработал, удалил кусок и завершился. Следущий запуск аналогично. До тех пор пока кусков не останется.
Хорошо ли это ?
Делите одну большую задачу на много маленьких..
Не помогло? еще раз...
Стопроцентный вариант..
Да.. queue - это самое оно...
Всем добра.. с наступающим-)
Спасибо. С Наступающим. Точнее, с наступившим !
Итого: порезал файл на маленькие файлики. И каждый по отдельности "засосал" в очередь. А обработку очереди повесил на queue . Сижу смотрю - улетают кусочки со свистом Спасибо всем за подсказки.
С Новым Годом !
Импровизировать) Или немножко почитать про алгоритмы,такие задачи попадаются редко но хоть позволяют думать
Есть такой язык, си ....Кстати до сих пор считается самым крутым языком
Добрый день. Вы мысль свою развивать будете ? Или на этом все заканчивается?
Уже все развили до нас. И врядли это кому-то интересно, к сожалению..
110тыс строк). В каждой строке подготовленные данные одной записи в БД. --> Mysql поддерживает свои механизмы импорта данных,которые гораздо быстрее раоты через php. так как на си построены
Вы о подготовке запроса к БД в текстовом файле и скармливанию его MySQLю ? :),
Там море способов.
Уже долгое время отработано и гарантировано работает cron + одна сущность - 1 файл xml
Прошу помочь - научить (показать простейший пример) тому, кто отстал от паровоза за десятки лет
p.S. Засасывание мелких файлов субъективно увеличивает время отклика сайта на внешние вопросы. Этот аспект поставил в List ToDo для будущей оптимизации. может ваш вариант как раз и решит данную проблему. Спасибо.
Самый пример - feeds, но и aggregator иммет право на жизнь.
Вас не затруднит вашу мысль немного расширить(разжевать) ?
p.S. Модуль feeds нужно изучить?
Спасибо и на этом. Посмотрел модулек FEEDS - интересный Все через интерфейс делается Для ленивых точно. Запомнил. Вернусь еще к нему.
Feeds не для ленивых... у него мощное АПИ.. он для умных..
Минимум движений, и грузим откуда хотим, парсим как надо, и импортируем как надо...(fetcher, parser, processor)
А если все более-менее стандартно, то да.. с настройками разобрался, мышкой покликал и все импортируется..
Ну да, все это уже сделано, правда ручками.
Коннектимся, скачиваем, парсим, валидэйт, вывод порционно в файлики. Крон файлики кушает и заносит в БД.
Попробую на него время потратить при следующем импорте чего-либо
Больше всего волнует: минимизация аппетита к ресурсам
Спасибо.
При заргузке файла соединения апача не обрывается по таймауту, а держится при всем процессе загрузки.
Я не говорю что они обрываются. Я говорю что субъективно кажется что их вешают на HOLD.
на что их там вещают?
думаю нужно сперва почитать мануалы.....А то будет дискуссия что быстрее пхп или хтмл..и как правило глубоко копать никто не любит и все заканчивается на этапе распальцовки