Поиск товаров с потерянными изображенями.

[Pirks]

Все првиет!
А подскажите в каком направлении думать, для реализации скрипта вытаскивающего все товары у которых потеряны изображения. Т.е. файлов нет на диске. 
Перебирать product и product_image и проверять наличие файла на диске это решение задачи в  лоб.
И наверное будет не быстро если товаров ~ n*10000. Может быть уже есть красивые решения?  

Сейчас смотрю логи ngnix - может быть искать сообщения с no_image?
Какие есть идеи?
 

[Einshtein]

Я когда-то решал вопрос с помощью этого скрипта, только дорабатывал его. Это заготовка, попробуйте дописать под свои нужды

fixit.php

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

[Pirks]

8 минут назад, Einshtein сказал:

Я когда-то решал вопрос с помощью этого скрипта, только дорабатывал его. Это заготовка, попробуйте дописать под свои нужды

fixit.php

 Einshtein, спасибо за скрипт. ) У меня почти такой же, только на PDO. По моим подсчетам если за 1 секунду проверять 10 файлов ( что очень оптимистично ), а записей в product_image ~180 тыс. то получается ~5 часов.
После этих расчетов я задумался об альтернативном решении. 

[Pirks]

Сейчас пытаюсь реализовать такую схему - забрать имена файлов изображений в mySQL и потом уже сравнивать с product и product_image.
 

Змінено 21 серпня 2018 користувачем Pirks

[Einshtein]

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

То есть по сути получается что одна запись об изображении = 1 запрос, причем не тяжелый, даже очень легкий

Либо можно одним запросом вытащить все записи в массив и потом уже перебирать сам массив.

Я уже не помню сколько времени у меня это заняло, но я проверял порядка 4к товаров, по 5-10 изображений у каждого и не помню чтобы были какие-то проблемы

[thentru]

Если сделать доп проверку наличия фото в контроллере продукта?
Т.е. фото нет - обновили данные по товару

Боты ведь ходят по страницам

[Einshtein]

1 минуту назад, thentru сказал:

Если сделать доп проверку наличия фото в контроллере продукта?
Т.е. фото нет - обновили данные по товару

Боты ведь ходят по страницам

Это если не требуется сиеминутное решение. Да и автору нужен полный список таких товаров, видимо чтобы удалить их или проставить фото. 
 

[chukcha]

47 минут назад, Pirks сказал:

Перебирать product и product_image и проверять наличие файла на диске это решение задачи в  лоб.

Это самое быстрое и верное решение..
 

[Pirks]

52 минуты назад, Einshtein сказал:

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

 

Да вы правы, file_exists - быстро работает! )  Может быть я открывал и получил такое время. (
 

49 минут назад, Einshtein сказал:

Это если не требуется сиеминутное решение. Да и автору нужен полный список таких товаров, видимо чтобы удалить их или проставить фото. 
 

Мне надо получить их список и докачать через API с ресурсов поставщика. 

Всем спасибо, за участие. )

[chukcha]

1 час назад, Einshtein сказал:

он просто обращается по пути из базы к нужному файлу и если не находит его

здесь вопрос о десятке тысяч товаров

Т.е. можно упереться просто во время выполнения скрипта и память

Для єтого создать временную таблицу
в которой записывать проверенііе id

SELECT product_id, t_product_id
FROM oc_product
LEFT JION oc_t_product ON product_id = t_product_id
WHERE t_product_id IS NULL

[Pirks]

1 час назад, thentru сказал:

Если сделать доп проверку наличия фото в контроллере продукта?
Т.е. фото нет - обновили данные по товару

Боты ведь ходят по страницам

Это хорошая идея по поводу потерянных изображений, я как раз искал место, где генерируется событие на не найденное изображение.
Отсюда можно забрать ссылку на изображение  или product_id и потом скачать. 
А данные по товару   планируется обновлять, когда приходит обновление цен, а атртикул не находится.  Вот тогда запускается процесс скачивания основного каталога товаров, а там и ссылки на изображения есть.

Змінено 21 серпня 2018 користувачем Pirks

[Pirks]

9 минут назад, chukcha сказал:

здесь вопрос о десятке тысяч товаров
Т.е. можно упереться просто во время выполнения скрипта и память
Для єтого создать временную таблицу
в которой записывать проверенііе id

 

Так и планируется, только сразу имя файла писать, а не id. 
Другой скрипт будет по это таблице периодически скачивать по крону или этот же, после проверки.

 

А просто "пробежать" в консоли по  product с ~45000 записей проверяя  file_exists - 1 сек.
Конечно, с записью во временную таблицу будет дольше. 

[Einshtein]

13 минут назад, chukcha сказал:

здесь вопрос о десятке тысяч товаров

Т.е. можно упереться просто во время выполнения скрипта и память

Для єтого создать временную таблицу
в которой записывать проверенііе id

SELECT product_id, t_product_id
FROM oc_product
LEFT JION oc_t_product ON product_id = t_product_id
WHERE t_product_id IS NULL

это для того чтобы в случае обрыва - не с 0 стартовать, а от последней записи?
Идея хорошая, но я бы просто ипанул 300 секунд на выполенние скрипта и ждал
Учитывая что запросы не особо тяжелые - 10к товаров имхо не составило бы труда за это время проверить)
А если не уложился бы - охренел и разбил бы базу на несколько частей
Да-да, ваш покорный слуга еще тот говнокодер
 

[Pirks]

Итак, все проверил, результаты:

Проход по   ~45000 записей в product с проверкой   file_exists и с занесением в таблицу mySQL ~1500 записей с именем файла  ~1 сек.

Все хорошо. )

Т.е все можно ставить в фоне по крону  и другим скриптом докачивать изображения. 

P.S. Тут еще идея появилась, прятать эти товары  с фронта, пока изображений нет. Ну это если кому надо. ) 

Змінено 21 серпня 2018 користувачем Pirks

[Einshtein]

Мои поздравления
Спасибо что отписали, ждал результатов

[chukcha]

26 минут назад, Einshtein сказал:

это для того чтобы в случае обрыва - не с 0 стартовать, а от последней записи?

Да..

@Einshtein решение в лоб хоть и не оптимальное, но явное и быстрое
А поиск оптимизации кода может занять недели :)

[Einshtein]

10 минут назад, chukcha сказал:

Да..

@Einshtein решение в лоб хоть и не оптимальное, но явное и быстрое
А поиск оптимизации кода может занять недели

я в таких вопросах обычно рассуждаю следующим образом
if (нужно быстрое разовое решение) {

  выбираю решение быстрое, топорное, но чтобы быть уверенным что это сработает  в определенных сроках, как например в этом случае если бы был тяжелый запрос - разбил бы базу и все. Тут легко просчитать сколько времени уйдет на работу.
} else {

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

}

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

[Pirks]

17 минут назад, Einshtein сказал:

Мои поздравления

Спасибо! )