речь шла об оптимизации парсинга. При этом очень много получаемых данных.
Вопрос - что оптимальней - брать все полученные данные записывать по новому или делать сверку.
Кратко. Есть интернет магазин в котором есть каталог товаров.
весь каталог разбит на разделы
разделы-разбиты на подразделы
подразделы разбиты на секции
секции на страницы (пагинатор)
на странице от 1 до 72 кратких обзора товара с ссылкой на полное описание товара.
Задача: получить все товары каталога, сохраняя иерархию каталого.
Спор начался тогда, кода стал вопрос об обновлении спарсенных данных.
Обновление планировалось с помощью крона, 1 раз в неделю (ночью в субботу)
Я предложил: (т.к. БД очивидно что состоит не из одной таблицы, как минимум из 6)
Перед каждым этапом - чистить таблицу под ноль и писать новые данные, комментируя это тем, что в данном случае - обновление будет проходить быстрее
Директор же настаивал именно на обновлении, соотв- но проверка, наличие, обновление или удаление или добавление.
Вот в принципе и всё.
Сейчас я уже понимаю, что по моему предложению - во время обновления наш сайт будет бустым какое то время (10-20 мин) и в случае сбоя на сайте доноре - можно вообще на какое то время остаться ни с чем.
По этому рассматриваю 2 варианта (2я БД со временными результатами или просто флаг, который бы показавал - обновлена ли секция раздел подраздел или товар: поэтапное обнавление)
в частности могу добавить что речь идёт о 337 секциях, ~500страниц секций ~10k-15k товаров (или страниц с полным описанием на товар)
Так же директор настоял на использовании SHD (объясняя что остальные именно с ним работают), договорились о частичном использовании т.к. я на примере показал что регулярки справляются за 16-20 сек, а SHD уходит за 1-2минуты
При парсинге использую мульти курл , при записи mysqli_multi_query
Предварительно упаковываю в массивы, потом в БД.
Спустя 2 минуты, 16 секунд (14.11.2011 - 10:53) Семён написал(а):
Его вариант правильнее
Спустя 1 минута, 6 секунд (14.11.2011 - 10:54) Игорь_Vasinsky написал(а):
Семён
Прокомментируй как нить. Он так же говорит.
А по быстродействию - у него же уйма запросов в БД ещё появиться.
хотя SELECT поспокойней INSERT...
Да видимо придётся по его плану. Сдаётся мне инфа там не часто обновляется...
Прокомментируй как нить. Он так же говорит.
А по быстродействию - у него же уйма запросов в БД ещё появиться.
хотя SELECT поспокойней INSERT...
Да видимо придётся по его плану. Сдаётся мне инфа там не часто обновляется...
Спустя 5 минут, 7 секунд (14.11.2011 - 10:59) linker написал(а):
Тебе придётся чистить всё, иначе порушатся связи, если таковые имеются. С другой стороны в цикле дёргать мускул на предмет наличия данных тоже некузяво.
Спустя 1 минута, 6 секунд (14.11.2011 - 11:00) Семён написал(а):
Игорь_Vasinsky
По быстродействию твой вариант естественно будет работать быстрее.
1) Ты будешь заниматься постоянно дефрагментацией базы?
2) Что лучше для базы SELECT/UPDATE или DELETE/INSERT.
3) Постоянная смена id, смена индексов, кеша и прочего.
4) Что будет происходить с сайтом в момент полной очистки?
--- Оба варианта, достойны внимания, но я бы пошёл путём lazy-сравнения.
По быстродействию твой вариант естественно будет работать быстрее.
1) Ты будешь заниматься постоянно дефрагментацией базы?
2) Что лучше для базы SELECT/UPDATE или DELETE/INSERT.
3) Постоянная смена id, смена индексов, кеша и прочего.
4) Что будет происходить с сайтом в момент полной очистки?
--- Оба варианта, достойны внимания, но я бы пошёл путём lazy-сравнения.
Спустя 34 секунды (14.11.2011 - 11:00) Игорь_Vasinsky написал(а):
linker
ВОт я и говорю. Записать то с мульти запросом - я без проблем, но выборка.. это уже другое дело.
ВОт я и говорю. Записать то с мульти запросом - я без проблем, но выборка.. это уже другое дело.
Спустя 3 минуты, 3 секунды (14.11.2011 - 11:04) Renden написал(а):
Игорь_Vasinsky
Все жестко мочить можно только в том случае если ты 100% уверен что данные придут те которые надо в любом случае..., а такую гарантию почти ниче не дает, вариант с обновлением хоть и будет медленнее но он будет 100500раз правильнее.
linker
Все жестко мочить можно только в том случае если ты 100% уверен что данные придут те которые надо в любом случае..., а такую гарантию почти ниче не дает, вариант с обновлением хоть и будет медленнее но он будет 100500раз правильнее.
linker
| Цитата |
| С другой стороны в цикле дёргать мускул на предмет наличия данных тоже некузяво. |
Нафига? ИМХО самая оптимальная реализация дернуть твоим скриптом опять ВСЕ-ВСЕ с сайта донора, и залить их во временую таблицу (TEMPORARY TABLE), а далее сделать UPDATE таблицы основной теми данными которых не хватает, и взять их быстренько из твоей временной таблицы, а потом её мочкануть) И волки сыты и овцы целы
Спустя 13 минут, 31 секунда (14.11.2011 - 11:17) Игорь_Vasinsky написал(а):
| Цитата |
| залить их во временую таблицу (TEMPORARY TABLE), а далее сделать UPDATE таблицы основной теми данными которых не хватает, и взять их быстренько из твоей временной таблицы, а потом её мочкануть) И волки сыты и овцы целы |
т.е. не было печали, стало скучно и я ещё одну БД временную собрал. А как я проверю то всё записалось или кусками? это же контент, он как переменная. сёдня 10 000 наименований, завтра 15 000 и т.д.
Если производить обновление - то мне нужно проверить все наименования разделов, подразделов, секций, кол-во страниц в пагинаторе секции+ кол-во товаров + каждый товар по 2м таблицам.
Спустя 9 минут, 2 секунды (14.11.2011 - 11:26) linker написал(а):
Главное при апдейте не забыть, удалить те элементы, которые были удалены на распарсиваемом сайте.
Спустя 5 минут, 50 секунд (14.11.2011 - 11:32) Renden написал(а):
Игорь_Vasinsky
| Цитата |
А как я проверю то всё записалось или кусками? |
Ну так INSERT ... ON DUPLICATE KEY UPDATE обновит если надо, если уже есть добавит..
| Цитата |
| Если производить обновление - то мне нужно проверить все наименования разделов, подразделов, секций, кол-во страниц в пагинаторе секции+ кол-во товаров + каждый товар по 2м таблицам. |
ну несколько таблицы, несколько условий, в цикле думаю не так уж тяжко будет сделать..
ЗЫ у меня таже просто похожая задача была, и самый быстрый вариант это был именно с несколькими таблицами..
linker
| Цитата |
| Главное при апдейте не забыть, удалить те элементы, которые были удалены на распарсиваемом сайте. |
Это уже по желанию, можно например ставить и disable = 1
Спустя 21 минута, 59 секунд (14.11.2011 - 11:54) linker написал(а):
Renden
Не важно как, главное не забыть проверить отсутствие там и присутствие здесь.
Не важно как, главное не забыть проверить отсутствие там и присутствие здесь.
Спустя 2 часа, 26 минут, 8 секунд (14.11.2011 - 14:20) imbalance_hero написал(а):
Объясни мне, вот зайдут люди, захотят посмотреть тему, а в начале написано: "вопрос решен", давай АБСОЛЮТНО весь форум так перепишем? Типо задал человек, получил ответ - удалили тему. Думаешь, это правильное решение?
Спустя 3 минуты, 59 секунд (14.11.2011 - 14:24) Игорь_Vasinsky написал(а):
ДА это флейм. я не хочу чтоб это кое кому на глаза попалось, всё равно не восстановить. Тут по сообщениям ясно что речть идёт об оптимизации парсинга.
Спустя 33 минуты, 15 секунд (14.11.2011 - 14:57) imbalance_hero написал(а):
Игорь_Vasinsky
Ну так всё равно некрасиво к остальным людям, кто заходить будет... да и мне любопытно было!
Ну так всё равно некрасиво к остальным людям, кто заходить будет... да и мне любопытно было!
Спустя 37 минут, 24 секунды (14.11.2011 - 15:35) Игорь_Vasinsky написал(а):
Восстановил как смог.
Спустя 50 минут, 57 секунд (14.11.2011 - 16:26) imbalance_hero написал(а):
Товар же имеет внутренний id, значит он такой же id, как у у тебя на сайте.
Я бы сделал как выше говорится, INSERT ... ON DUPLICATE KEY UPDATE .
Если старые нужно будет очистить, то последним полем делаешь timestamp, и те поля, которые были записаны на прошлой неделе ( а не обновлены на этой) - delete, но это по желанию.
Я бы сделал как выше говорится, INSERT ... ON DUPLICATE KEY UPDATE .
Если старые нужно будет очистить, то последним полем делаешь timestamp, и те поля, которые были записаны на прошлой неделе ( а не обновлены на этой) - delete, но это по желанию.
Спустя 5 минут, 45 секунд (14.11.2011 - 16:31) Игорь_Vasinsky написал(а):
не. там хитрее. ни чего удалять не нужно, нужно добавлять если добавятся разделы, подразделы, секции и товары и так же следить за изменениями цены.
Вот и всё. оказывается.. это я час назад узнал, работая с той недели
Вот и всё. оказывается.. это я час назад узнал, работая с той недели
| Цитата |
Товар же имеет внутренний id, значит он такой же id, как у у тебя на сайте. Я бы сделал как выше говорится, INSERT ... ON DUPLICATE KEY UPDATE . |
я тоже скланяюсь к такому решению, только мои ID с ихними не совпадают, я изначально свои назначал
Спустя 10 минут, 7 секунд (14.11.2011 - 16:41) imbalance_hero написал(а):
Игорь_Vasinsky
переназначь Лучше избавиться от гемороя на первой неделе работы, чем спустя года Никто не говорит, что у тебя тоже должно называться id, пусть будет ещё одна колонка: id_enemy
переназначь
Лучше избавиться от гемороя на первой неделе работы, чем спустя года Никто не говорит, что у тебя тоже должно называться id, пусть будет ещё одна колонка: id_enemy Спустя 3 минуты, 30 секунд (14.11.2011 - 16:45) Игорь_Vasinsky написал(а):
я уже над этим работаю. _____________
HTML, CSS (Bootstrap), JS(JQuery, ExtJS), PHP, MySQL, MSSql, Posgres, (TSql, BI OLAP, MDX), Mongo, Git, SVN, CodeIgnater, Symfony, Yii 2, JiRA, Redmine, Bitbucket, Composer, Rabbit MQ, Amazon (SQS, S3, Transcribe), Docker