ОБСУЖДЕНИЕ

Параллельный выбор данных из таблицы

5 ответов 6,1 тыс.
Статус
Закрыто для дальнейших ответов.
Автор темы
Небольшой Callcenter. Агенты при помощи клиентской программы получают контактные телефоны.
Само собой разумеется, различным агентам не должны попасть одинаковые телефоны одновремменно. Хорошо.

Выбираем строку из таблицы, запираем ее(id агента в столбец, скажем "lock_agent_id") и говорим этот агент ее выбрал.

Результат разговора сохраняется и телефон больше не выбирается. Тут все нормально.

Но, сам выбор: допустим

BEGIN
SELECT phone_id,name,phone INTO @phone_id,@name,@phone
FROM phones
WHERE lock_agent_id IS NULL.... LIMIT 1 FOR UPDATE;
UPDATE phones SET lock_agent_id=@agent_id WHERE phone_id = @phone_id;
...
RETURN
END

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

один из них действительно получает номер, а остальные пустую строку.

Кажется, выход только один,- запереть всю таблицу (LOCK TABLE) во время выбора. Правда, тогда всем остальным

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

Нужеле нет другого выхода? Мне кажется, что это стандартная проблема, но к сожалению, я с ней столкнулся впервые.

Может быть кто-то подскажет. Заранее благодарен.
 
Как вариант вынести это деало из прямых обращений к серверу баз данных в свою промежуточную программу, которая ставит все запросы от клиентов в очередь и потом уже сама их обрабатывает .. и далее уже по своему алгоритму синхронизируется с базой данныхи вносит в неё обновления. Это избавит от постоянных обновлений баз данных... поднимется скорость реации на запросы клиентов.
 
Если я правильно понял - это сервис, который хранит внутри себя, для скорости - в ram'е, какое количество строк, ставит в очередь клиентов и выдает им телефоны. Соответственно принимает результаты, сохраняет их снова только внутри себя, и после, при известном условии(количество необработанных адрессов мало или окончание работы), обновляет базу данных результатами, и выбирает новые данные.

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

Но такая схема точно работает .. потому как реализована в существующем работающем (большом) Call center-е :D
 
Я соглашусь. Но мне, к сожалению, приходится думать и о том, сколько программа стоит, и сколь часов уйдет на ее реализацию. Тот, кто отдает за, к примеру, автомобиль 1000 долларов, не ждет от нее комфортности и надежности нового Мерседеса.
Как я написал, callcenter не очень большой, максимум 30 агентов. Думаю, что все же решусь писать и читать напрямую через базу. Небольшую программу для тестирования и поглядеть на результаты.
А за совет спасибо, думаю, что в дальнейшем, если появится необходимость в больших мощностях, именно так и нужно будет попробовать.
Если можно, вопрос: сколько агентов работает в callcenter, который был упомянут?
 
Проектная мощность до 1000... максимальное на текущее время одновременно работающих не более 100...
 
Статус
Закрыто для дальнейших ответов.