MySQL. Как обновлять данные по расписанию?

Question

[vlaabra]

Здравствуйте!

Упрощенная таблица:
id INT
bonus INT
date_reg TIMESTAMP

Записей много. Каждый день нужно прибавлять +1 к bonus. В идеале не в определенное время всем, а каждому по прошествии суток.

Не нравятся следующие решения: cron и MySQL EVENT, потому что надо в один момент менять записи или ежеминутно делать выборку записей, которые нужно обновить.

Что посоветуете?

Answer 1

[Владлен Грачев]

Не знаю, что конкретно хранится в date_reg, поэтому будем предполагать, что есть поле date, хранящее время последнего прибавления (возможно, можно получить это из date_reg).
При любом обращении к некой записи в БД смотрите значение date, прибавляете к bonus число полных дней, прошедших с date, и к date тоже прибавляете число полных дней.

Допустим, некая запись имеет в bonus значение 10, а в date — 11.08.2014 16:20. При обращении к ней где-то отрабатывается описанный выше алгоритм. Если обращение произошло 14.08.2014 21:50, то bonus меняется на 13, а date — на 14.08.2014 16:20. И работа ведется с уже измененными данными.

Где будет производиться описанная обработка — решать вам. На мой взгляд, разумно было бы реализовать это на триггерах в БД.

Прочие варианты будут подразумевать cron или демонов.

Comments

[vlaabra]

Изначально date_reg — это дата создания записи, которая не меняется. Но это не проблема, можно добавить дату обновления записи тоже. Спасибо, наверное, это решение подойдет. Буду тестировать.

[Леша Киселев]

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

[Владлен Грачев]

@Yakud, зависит от реализации. Если не на стороне БД запилить процедуру, которая будет отрабатывать только при заходе юзера, то да. А при правильной реализации оно будет работать ровно тогда, когда нужно. К тому же задача не настолько хорошо известна, чтобы говорить, что в каких-то иных ситуациях оно еще потребуется.

Answer 2

[Оптимус Пьян]

cron

Answer 3

[Леша Киселев]

Как вариант, выгрузить задачи в очередь и при разборе оной, смотреть время выдачи "бонуса".
Выгрузили из базы -> положили в очередь <- берем головной элемент, время наступило - даем бонус. Нет - обратно в очередь.
В очереди должна быть уже рассчитанное время выдачи, либо время когда начали отсчитывать время бонуса + через какое время отдаем бонус.

Comments

[vlaabra]

То есть, теоретически, в какой-то момент времени в очереди могут находиться огромное кол-во заданий, которые по кругу дергают базу данных и ничего не делают? И, насколько я понимаю принцип работы очередей, даже небольшое кол-во заданий все равно будут по кругу дергать базу данных с определенной периодичностью. Получается тот же cron или event.

[Леша Киселев]

@vlaabra Дергать базу не придется, в задании, которое находится в очереди, должны быть все данные для определения "стоит ли давать бонус".
Теоретически да, такая вероятность есть.
Можно, например, разделять записи на разные очереди. 1-я очередь - бонус нужно дать не ранее, чем через 0.5-6 часов. Такую очередь разбираем раз в 1-6 часов (выбрать под объем данных), например. 2-я очередь - для задач, которые нужно выполнять уже совсем скоро. В нее будут попадать задачи из первой и разбираться она будет гораздо чаще.
Таким образом, можно здорово снизить нагрузку. 1-я очередь будет всегда большая, но и разбираться она будет редко. Во 2-ой очереди, задачи не будут долго задерживаться и она будет меньшего объема.
Вот как-то так..

[vlaabra]

@Yakud Бонус начисляется на все аккаунты каждые сутки, поэтому нет каких-то особых условий. Если запись создана 15:01:01, то каждый день в 15:01:01 независимо от других причин надо прибавить +1 к бонусу. Как мне кажется, решение с несколькими очередями приблизится к идеальному, если очередей будет много, тогда как триггер будет обновлять бонус при каждом обращении к записи. Конечно, это тоже не идеал, так как накладывает некоторые ограничения, например запрос суммы всех бонусов админом.