EG
Бд умеет брать много индексов
не всегда эфективно индексы мержатся
Size: a a a
2021 February 04
EG
Tim
А если хранить эту табличку в редисе?
А сколько записей в CarVariant таблице?
L
Tim
Парни, дайте экспертное мнение
У меня задача - поставить 4млн джобов на парс
Есть 14000 вариантов машин и 278 вариантов запчастей
Я делаю джоб, который генерит эти джобы на парс
Внутри этого джоба есть обращение к бд, чтоб определить ID конкретного сочетания - год + марка + машина и эта хрень оч сильно тормозит скрипт, как бы вы поступили?
У меня задача - поставить 4млн джобов на парс
Есть 14000 вариантов машин и 278 вариантов запчастей
Я делаю джоб, который генерит эти джобы на парс
Внутри этого джоба есть обращение к бд, чтоб определить ID конкретного сочетания - год + марка + машина и эта хрень оч сильно тормозит скрипт, как бы вы поступили?
На мой взгляд вариантов не так много, можно просто в памяти хранить таблицу
T
А сколько записей в CarVariant таблице?
14000
Y
не всегда эфективно индексы мержатся
Ну постгрес тот же нормально берёт
T
На мой взгляд вариантов не так много, можно просто в памяти хранить таблицу
Вот тож об этом подумал
EG
Tim
14000
до 100к по индексам пожно и не дергаться, но лучше поставить
T
до 100к по индексам пожно и не дергаться, но лучше поставить
уже стоят
EG
а если делать асинхронные запросы, т.е.
на 14000 вариантов запускаем Jobs (т.е. 14000 jobs), а в Jobs делаем пулами по 50-100 асинхронных (Guzzle или др. клиент) запросов вариантов запчастей, но мне кажется ebay заболит такого клиента.
на 14000 вариантов запускаем Jobs (т.е. 14000 jobs), а в Jobs делаем пулами по 50-100 асинхронных (Guzzle или др. клиент) запросов вариантов запчастей, но мне кажется ebay заболит такого клиента.
T
а если делать асинхронные запросы, т.е.
на 14000 вариантов запускаем Jobs (т.е. 14000 jobs), а в Jobs делаем пулами по 50-100 асинхронных (Guzzle или др. клиент) запросов вариантов запчастей, но мне кажется ebay заболит такого клиента.
на 14000 вариантов запускаем Jobs (т.е. 14000 jobs), а в Jobs делаем пулами по 50-100 асинхронных (Guzzle или др. клиент) запросов вариантов запчастей, но мне кажется ebay заболит такого клиента.
ошибаешься
T
а если делать асинхронные запросы, т.е.
на 14000 вариантов запускаем Jobs (т.е. 14000 jobs), а в Jobs делаем пулами по 50-100 асинхронных (Guzzle или др. клиент) запросов вариантов запчастей, но мне кажется ebay заболит такого клиента.
на 14000 вариантов запускаем Jobs (т.е. 14000 jobs), а в Jobs делаем пулами по 50-100 асинхронных (Guzzle или др. клиент) запросов вариантов запчастей, но мне кажется ebay заболит такого клиента.
я паршу ебей в 500 потоков с одной прокси, все ок
T
а если делать асинхронные запросы, т.е.
на 14000 вариантов запускаем Jobs (т.е. 14000 jobs), а в Jobs делаем пулами по 50-100 асинхронных (Guzzle или др. клиент) запросов вариантов запчастей, но мне кажется ebay заболит такого клиента.
на 14000 вариантов запускаем Jobs (т.е. 14000 jobs), а в Jobs делаем пулами по 50-100 асинхронных (Guzzle или др. клиент) запросов вариантов запчастей, но мне кажется ebay заболит такого клиента.
и там не 14000 джобсов у меня, а 4млн
T
ибо у каждой varVariant есть 278 запчастей)
T
причем что интересно, у них есть апи и оно ограничено 5000 запросов в сутки :D
EG
Tim
и там не 14000 джобсов у меня, а 4млн
правильно 14000 x 278 = 4кк
а если запустить 14000 jobs на все модели, а в них сделать параллельные запросы на поиск запчастей и jobs меньше и нагрузка по памяти, да и мне кажется отработает даже быстрее.
а если запустить 14000 jobs на все модели, а в них сделать параллельные запросы на поиск запчастей и jobs меньше и нагрузка по памяти, да и мне кажется отработает даже быстрее.
T
правильно 14000 x 278 = 4кк
а если запустить 14000 jobs на все модели, а в них сделать параллельные запросы на поиск запчастей и jobs меньше и нагрузка по памяти, да и мне кажется отработает даже быстрее.
а если запустить 14000 jobs на все модели, а в них сделать параллельные запросы на поиск запчастей и jobs меньше и нагрузка по памяти, да и мне кажется отработает даже быстрее.
так то же самое получится 4 млн запросов, какая разница?
EG
правильно 14000 x 278 = 4кк
а если запустить 14000 jobs на все модели, а в них сделать параллельные запросы на поиск запчастей и jobs меньше и нагрузка по памяти, да и мне кажется отработает даже быстрее.
а если запустить 14000 jobs на все модели, а в них сделать параллельные запросы на поиск запчастей и jobs меньше и нагрузка по памяти, да и мне кажется отработает даже быстрее.
или например из Jobs по моделям пулять, Jobs на поиск запчастей
EG
Tim
так то же самое получится 4 млн запросов, какая разница?
но Jobs не 4кк и памяти не 80gb как ты как-то писал
T
или например из Jobs по моделям пулять, Jobs на поиск запчастей
а я понял о чем ты, но мне не нравится в таком подходе, что одновременно и джобы генерятся на парс и сам парс идет, хрен поймешь все ли правильно сработало, у меня на этапе подготовки джобов на парс был глюк - он то 4 млн генерил то 4,1 то 3,9 например и терь у меня параноя
T
а насчет 60гб памяти я уже понял, в чем ошибка и поправил )