Как делать выборку в потоках?

Question

[ZIK1337]

Имеется БД, к которой одновременно может быть максимум 50 подключений (лимит хостера, изменить нельзя).
Работают 200 потоков, в каждом потоке получается id, который нужно проверить по БД (через SELECT) - есть ли он там (не уникальный). И в зависимости от того, есть или нет этот id уже в БД - будут зависеть дальнейшие действия в потоке.

Если в каждом потоке создавать подключение - ошибка из-за лимита. Если ждать, пока станет меньше 50 подключений - слишком долго.
Передавать подключение дочерним потокам, используя pymysql, нельзя.

Каким образом же тогда организовать выборку в потоках?

Comments

[Иван]

а что одно подключение сделать нельзя?

[ZIK1337]

Иван, Передавать подключение дочерним потокам, используя pymysql, нельзя.

[Иван]

ZIK1337, глобальные переменные передаются во все потоки, проверял
хоть юзаю и другую бд, но у меня одно подключение на несколько потоков

[ZIK1337]

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

[Иван]

ZIK1337, всмысле, подключение же одно

[ZIK1337]

Иван, ну значит в этой библиотеке не так работает
делал еще курсор глобальным, то же ошибка, что он закрыт

[Иван]

ZIK1337, попробуй поменять)))))

[ZIK1337]

Иван, что поменять?

[Иван]

ZIK1337, библиотеку

Answer 1

[Emil Revencu]

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

Comments

[ZIK1337]

не мои лимиты, а хостера
нельзя увеличить

[Dr. Bacon]

ZIK1337, если это еще и хостеры лимиты, то это какой-то неполноценный хостинг, тем более про большое кол-во потоков можно забыть.

Answer 2

[Dr. Bacon]

Еще раз 200 потоков, да даже 50 и каждый с подключением к БД, это сильно много для python, там много ресурсов будет тупо уходить на переключение между ними. Отвечал еще в прошлый раз, надо разделить работу с данными и работы с БД через очереди. Кладешь id в очередь, несколько потоков в цикле получают из этой очереди, обрабатывают, в простейшем случаю и записывают в бд, либо делаешь еще одну очередь, которая будет аналогично работать на запись. Через замеры производительности, определяешь оптимальное кол-во поток, сомневаюсь что там больше 10 будет.

Comments

[ZIK1337]

Мне не надо записывать в БД, с этим уже изменил. Мне теперь выборка нужна.

Работа идет с аккаунтами из списка на несколько тысяч штук, по API, поэтому 200 потоков это нормально.

[Dr. Bacon]

ZIK1337, тогда один поток с одним коннектом к БД, делает сразу большую выборку и кладет в очередь, а остальные обрабатывают, зачем им БД?

[ZIK1337]

Dr. Bacon, имеете в виду получить все id из БД или что?

[Dr. Bacon]

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

[ZIK1337]

Dr. Bacon, ну в БД около 2млн строк, ну и растет постоянно, так что вряд ли подойдет такое.

Я вроде описал, если еще более конкретно - в потоке получается id проверяемой страницы из списка аккаунтов. Если такой id уже есть в БД, значит ранее этот аккаунт уже проверялся и нужно пометить как повтор.

[Dr. Bacon]

ZIK1337, не, не понятна целостная картина.

[ZIK1337]

Dr. Bacon, ну попробую еще конкретнее. Программа - чекер аккаунтов.
Есть список аккаунтов, на несколько тысяч или десятков тысяч штук.
Есть БД с аккаунтами (другими, которые чекались ранее, соответственно и id ранее прочеканных там).

Одновременно чекаются по 200 акков из этого списка - то есть 200 потоков.
В потоке, если аккаунт рабочий, из ответа на запрос вытягивается id страницы.
Если такого id нет в БД, значит ранее данный аккаунт не попадался, то есть он уникальный - и он заносится в сводную таблицу.
Если же есть, то это повтор, в таблицу уже не заносится, а идет в список повторных.

[Dr. Bacon]

ZIK1337, Почему бы в одном запросе не чекнуть сразу N аккаунтов, а не по одному? И сделать разные очереди, для новых акков, для старых. Кроме это, использовать connection pool, всё равно в один момент времени все 50 коннектов не будут делать запросы, ну и не держать всё время коннект, а как сделал запрос, вернул его обратно в пул, обработал данные, если опять потребовалась работа с БД, заново из пула взять.

[ZIK1337]

Dr. Bacon,

Почему бы в одном запросе не чекнуть сразу N аккаунтов, а не по одному?

использую публичное API, там по одному только.

Коннекты закрывал после выборки сразу, но все равно не хватало.
А где про connection pool можно вкратце прочесть, чтобы внедрить сразу?

[Dr. Bacon]

ZIK1337,

использую публичное API

для это вообще можно отдельные потоки (или вообще async) сделать, тут же не требуется связь с базой и как раз время ожиданиz ответа от АПИ одно из узким мест. А про connection pool надо гуглить, я не в курсе какие есть решения для mysql