Нужна реализация подгрузки описания и фото товара по API

[yop3bik]

Необходима реализация подгрузки описания и фото товаров по API со стороннего источника.

Документация по api 

http://rlsaurora10.azurewebsites.net

Все необходимы доступы предоставлю. 

[MaDMaxX111]

Готов реализовать

[yop3bik]

@designer

выборка будет производится по штрихкоду

http://rlsaurora10.azurewebsites.net/api/inventory_brief?ean=4607009582412

У каждого товара есть штрих код

[yop3bik]

В 16.08.2017 в 09:41, Designer сказал:

@yop3bik

А есть демо доступы к API?
По идее, нужно не подгружать описание и фото, а реализовать в таком формате:
Нет описания - обращаемся к API и заполняем описание в БД у этого товара
Нет фото - загружаем фото на сервер и закремляем его к указанному товару

 

Если делать постоянное обращение к API, то это будет тормозить

Демо доступы есть.

База - более 20 тыс позиций. Мне кажется при полном заполнении базы будет тормозить.

[yop3bik]

Возможно ли решение, при котором все данные будут запрашиваться на стороннем сервере?

[yop3bik]

40 минут назад, Designer сказал:

@yop3bik что тормозить? 20 000 позиций, это не много.

Возможно, только смысл? Данные и так на стороннем сервере у API поставщика

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

[kvr66]

4 часа назад, yop3bik сказал:

Возможно ли решение, при котором все данные будут запрашиваться на стороннем сервере?

возможно, только дорого, не думаю что вы готовы платить за такое решение )

[Yoda]

В 16.08.2017 в 06:15, MaDMaxX111 сказал:

Готов реализовать

не рекомендую связываться с человеком с рейтингом 1 в реализации сложной задачи!

12 часов назад, yop3bik сказал:

Демо доступы есть.

База - более 20 тыс позиций. Мне кажется при полном заполнении базы будет тормозить.

При полном заполнении не тормозит и миллион!

5 часов назад, Designer сказал:

@yop3bik Перераспределение чего? Вообще, можно потратить пару часов времени и спарсить в БД все ночью один раз. При этом нагрузка на сервер будет нулевая.

Я не знаю, что Вы хотите перераспределять с мизерным количеством товаров в 20 000. Это не то количество, чтобы загружать на второй сервер, потом дергать с него на основной. Время затраты обработки данных будет даже дольше со второго сервера, чем получать данные от поставщика. Не создавайте себе головную боль с дурными мыслями. Если сайт тормозит от 20 000 позиций, вложите средства в оптимизацию как клиентской части, так и серверной

А вы спросите, прежде чем такое пишите!
от 20 000 товаров - это не сайт - это сложный проект!

[Yoda]

21 минуту назад, Designer сказал:

Первым делом я и сделал, что задал вопрос!

 

 Вы считаете, что от кол-во товаров на сайте, можно проект назвать сложным?

 

Я абсолютно в этом уверен.

Так как после 20 000 товаров. Возникают технологические сложности не связанные с движком, а связанные с технологическими особенностями PHP и MYSQL.

 

Из которых, чтобы вам понятно было, конкретно явные - это :

а) быстрый контексный поиск, который слабо реализуем на php+mysql, даже  через match against

б) резервирование нагрузки системы под всплески посещений ботов

в) если мы говорим о конкретном случае. И регулярном парсинге остатков, наличия, цен. Необходимы механизмы обхода блокирования таблиц в базе данных при постоянном обновлении данных и перестроении индексов.

 

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

[Yoda]

12 минут назад, Designer сказал:

@Yoda
1. С поиском понятно, тут сложно не согласиться.
2. Чтобы снизить нагрузку от ботов, можно задать им Crawl-delay и на серверном уровне, запрещать индексацию сайта залетным ботам.
2.1 Query Cache
2.2 Memcache
3. Регулярный парсинг в 4 утра, когда посещение сайта снижается к нулевой отметке, можно не беспокоиться об блокировке и обновлении данных.

После парсинга, можно так же можно выполнить оптимизацию и анализ таблиц для перестроении индексов.

Но создав сайт и загрузив туда 20к + товаров, я не могу называть это сложным проектом.
Помимо Выше указанных Вами пунктов, нужно смотреть и в корень проекта.
Так как нагрузить сайт можно и 100 товарами, если у части кода будет утечка памяти, кривой запрос, отсутствие индексов и т.д.

 

 

2 - нет нет и еще раз нет. Во первых это возможно только для Яндекса, гугл в упор не видит эту директиву. Во вторых. Снижать частоту посещения ботов - это равнозначно грызть себе руку.

2.1 - так же в корне неправильно, читаем мануал к mysql. Она отлично сама кеширует запросы, но в формает постоянно обновляемых данных и данных о просмотре товаров, данная техника неактуальна от слова совсем.

2.2 - в нынешних реалиях от memcache есть прирост только при обращении к повторяющимся данным, как-то например в сео про с кешем от фрилансера. Но на 50 к товаров в сео про кеш вреден больше чем полезен. А в остальных ситуациях, когда происходит одинарное чтение данных из кеша, прирост от memcache по сравнению с файловым кешем ssd - минимален. А при небольшом тюнинге библиотеки файлового кеша и вовсе нивелируется в рамках статистической погрешности.

3. У ботов нет дня и ночи, они не спят. Получить от яндекса пессимизацию с его новым оценочным алгоритмом, который требует ttfb < 3 сек - можно автоматически при такой технике.

Топик стартер совершенно верно формулировал мысль но не довел ее до конца. Если мы говорим о идеальном парсинге. Нам обязательно нужен промежуточный контейнер. В виде какого-то хранилища. Либо мы можем использовать технику перевода front-end выдачи каталога на индекс sphinx целиком, а не только поиска, и парсинга товара в базу данных с периодической переиндексацией сфинкса. Для регулярного real-time обновления данных о товарах opencart в коробке и существующие парсеры к сожалению, не сильно подходят. Я обсуждал концепции порционного обновления боевых таблиц как с @usergio так и с @MaxD несколько лет назад. Дядя Сережа покивал головой, сказал круто и забыл. А второй персонаж даже не понял зачем нужны какие то промежуточные таблицы, ведь и так же все вроде работает.

 

[MaxD]

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

А второй персонаж даже не понял зачем нужны какие то промежуточные таблицы, ведь и так же все вроде работает.

Немного оффтоп для этой темы, но видимо надо отозваться.

 

Yoda, у тебя нет никаких цифр, как и у меня. Если я ошибаюсь - поделись, будь добр.

А без цифр получается, что твои фантазии против моих. Мои фантазии такие:

 

Кеш MySQL с товарами не работает, его не рассматриваем. Запросы для записи нового товара в базу относительно быстрые (меньше 10 мс на все).

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

[Yoda]

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

Немного оффтоп для этой темы, но видимо надо отозваться.

 

Yoda, у тебя нет никаких цифр, как и у меня. Если я ошибаюсь - поделись, будь добр.

А без цифр получается, что твои фантазии против моих. Мои фантазии такие:

 

Кеш MySQL с товарами не работает, его не рассматриваем. Запросы для записи нового товара в базу относительно быстрые (меньше 10 мс на все).

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

 

Какие цифры... О чем вы сейчас. Я говорю о базовых принципах работы msysql. Когда мы пишем в таблицу, если она в Myisam - она лочится на чтение. В принципе... Если лочится таблица oc_product и у нас есть хоть какой-то трафик даже от ботов, этот лок вызывает лавинообразный поток наслоения процессов apache, потому что php стоит и ждет. Поэтому если происходит нон-стоп парсинг, то у нас постоянно заперта то одна то вторая то третья таблица, а таблиц с товарами допустим пусть будет 10... Соответсвенно 10 мс превращаются в  100. А в это время нас все время ждет очередь запросов на чтение... В итоге нагинается целиком весь проект.

 

Что мешает сделать  промежуточные клоны таблиц p2c p2s ps pd и так далее. Загонять в них 500-1000 наборов данных и одним большим запросом мерджить это с боевыми таблицами - я не знаю. Это достаточно просто. Но видимо все очень уверены в своем скиле.

Кроме этого. При изменении данных в любой таблице, сбрасывается внутренний кеш mysql, который мог бы работать на тех запросах которые не используют NOW().

К сожалению, вам лень читать мануал. Давайте все таки начнем с того, что вы внимательно изучите принцип работы MySql с таблицами MYISAM, изучите механизм блокировки и работы кеша. А потом мы начнем говорить дальше....

 

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

 

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

Разработка парсера + свинкс для клиентов будет дорогим удовольствием. В 99% клиенты ужасаются от стоимости разработки парсера. От этого и подходы к разработке соответствующие.
По поводу промежуточного контейнера, с него придется тоже обновлять данные в реал-тайм иначе, возвращаемся к началу всей проблемы.

2.1  ЕЩЕ РАЗ!!! КЕШИРОВАТЬ нативно ЗАПРОСЫ Mysql средствами PHP, это как мыть голову шампунем, одевая резиновую шапочку. Можно - но сродни идиотизму.

2.2 Если сайт непосещаем. Это не значит что он не будет посещаем в будущем. Если мы говорим о проекте даже на 20 000 товаров. То раз в три дня его должны обойти два бота гугл и яндекс. А это 40 000 посещений за 72 часа... А это 555 заходов  в час и 9 заходов в минуту. Это при идеальном роботсе и настроенном сео, а так умножайте на 4, и получаем 36 pageview в час. А кроме этого есть другие боты. А кроме этого есть какие-никакие посетители и так далее...

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

 

Разработка парсера не так страшна, если у вас есть готовая бизнес-логика обновления товаров и вам достаточно поменять драйвер API поставщика контента. По сути ничем не будет отличаться от смены классов используемого хранилища для кеша в в 2.3 opencart.

 

Обновлять реал-тайм данные в контейнере - да легко. Вот тут подробнее: http://sphinxsearch.com/docs/current/rt-overview.html

 

[MaxD]

3 минуты назад, Yoda сказал:

К сожалению, вам лень читать мануал.

Ну уж мне хоть своего привычного пафоса не пиши. Для лавинообразного наслоения процессов апаче под "хоть каким-то трафиком от ботов" нужны задержки порядка 10+ секунд. Никаких дополнительных 100 мс к этому не приведут.

 

Что мешает перейти на InnoDB, если так страшат локи? Одни плюсы.

 

Yoda, ты лучше меня знаешь, что практически все запросы Opencart, которые стоит кешировать, используют таблицу product. Остальные и так быстрые. Ну ты сам в пункте 2.1 обьясняешь, как парадоксально.

[Yoda]

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

Ну уж мне хоть своего привычного пафоса не пиши. Для лавинообразного наслоения процессов апаче под "хоть каким-то трафиком от ботов" нужны задержки порядка 10+ секунд. Никаких дополнительных 100 мс к этому не приведут.

 

Что мешает перейти на InnoDB, если так страшат локи? Одни плюсы.

 

Yoda, ты лучше меня знаешь, что практически все запросы Opencart, которые стоит кешировать, используют таблицу product. Остальные и так быстрые. Ну ты сам в пункте 2.1 обьясняешь, как парадоксально.

 

Да при чем тут пафос. Таблица на 200-300 000 записей умирает при частых операциях чтения не только из-за локов а из-за перестроения индексов.

И о чем мы ща спорим?

А мы спорим, о том что долбить в нее по одной записи абослютно неэффективно, когда можно пихнуть 1000 записей за один запрос, и закрыть в принципе все проблемы с локами. Что касается ботов и задержки. Ну не ходят они равномерно и по графику. У  пассивной нагрузки всегда есть рапределенные стохастические всплески, которые при постоянном обновлении легко валят голые проекты.

На InnoDB мешает перейти full-text индексы, который поддерживает только mariadb10, которая недоступна в большинстве хостинг-платформ.

 

И опять же я не понимаю в чем суть спора. Я долблю про технологию партицированного парсинга уже четвертый год. 
Какая сложность это реализовать ? 

У меня есть пример магазина, в котором 500 000 товаров. В нем весь каталог товаров подвешен в Sphinx, при этом база постоянно обновляется - ни единого разрыва. Разнесенные хранилища в разные контейнеры - это абсолютно минус головная боль...
Да вы сейчас скажете, что сфинкс надо еще поставить настроить. Ок не вопрос. Кто мешает вам сделать два контейнера в рамках Mysql ?

 

 

[MaxD]

4 минуты назад, Yoda сказал:

из-за перестроения индексов

 

Да, ты и тогда про перестроение индексов говорил. Нету в MySQL перестроения индексов при изменении данных, в индексе меняется/вставляется/удаляется только одно нужное значение.

 

Спорим мы вот о чем. Чтобы был смысл городить такой огород с промежуточным хранилищем (а городить там прилично), нужны веские реальные цифры вида "среднее время отклика сайта такое-то, запускаем парсинг - выростает вдвое". И чтобы еще было видно, что именно MySQL садится, и желательно на каких именно запросах.

 

На той же shopica остановка парсинга как-то не особо ее оживляла.

[Yoda]

20 минут назад, MaxD сказал:

 

Да, ты и тогда про перестроение индексов говорил. Нету в MySQL перестроения индексов при изменении данных, в индексе меняется/вставляется/удаляется только одно нужное значение.

 

Спорим мы вот о чем. Чтобы был смысл городить такой огород с промежуточным хранилищем (а городить там прилично), нужны веские реальные цифры вида "среднее время отклика сайта такое-то, запускаем парсинг - выростает вдвое". И чтобы еще было видно, что именно MySQL садится, и желательно на каких именно запросах.

 

На той же shopica остановка парсинга как-то не особо ее оживляла.

 

Мне очень давно не попадались магазины с parseMX. Но вот модуль @usergio, дай бог ему здоровья, стоит на каждом втором магазине. И я думаю, что каждый владелец его модуля подтвердит, что в момент работы парсера, магазин ложится на слабых хостингах, или начинает существенно подтормаживать на нормальных.

А цифры и выкладки - это не ко мне в данной ситуации. Потому что такими темпами, придется делать собственный парсер, а мне это не интересно.

[MaxD]

36 минут назад, Yoda сказал:

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

 

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

 

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

 

В любом случае, буду наблюдать за этим ньюансом у клиентов. И да, делать свой парсер - удовольствие такое себе )

[yop3bik]

О сколько я всего пропустил.

Резюмируя:

1. У меня большое сомнение, что если я спарсю весь контент по аптечным товарам себе в базу, сайт не начнет тормозить

2. У поставщика API под это дело выделенная площадка, и я так понимаю, что их основной сайт справочника не хранит данные у себя, а берез их через  этот же API. Речь идет о справочнике РЛС.

Какое же решение вопроса верное?

Хранить все у себя и настраивать свой софт и железо,

либо дергать по запросу у поставщика API?

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

[MaDMaxX111]

Мое мнение вносить справочник в свою систему, вот что написано на РЛС - "

РЛС^® Аврора – система публикации данных о лекарствах для интеграции в медицинские информационные системы (МИС), медицинские системы помощи принятия решений, товарные учетные системы дистрибьютеров, аптечных сетей и аптек. Эта система предназначена для разработчиков. Т.е. разработчики должны научиться встраивать публикуемые данные в свои информационные системы, реализовать процедуры периодического обновления."

Если сайт будет сильно тормозить то уже применят определенные методы оптимизации нагрузки