Я могу ошибаться, но мне кажется то ты не понял задачу.
Очень многие её не понимают, и думают что она сводится к другой, им теоретически знакомой.
Там перед апдейтом есть еще селект.
-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
Избежать конкуренции при многопоточной обработке данных в БД
- Автор темы Фанат
- Дата начала
Очень многие её не понимают, и думают что она сводится к другой, им теоретически знакомой.
Там перед апдейтом есть еще селект.
Когда select делать будешь, до или после update?
Предлагают наоборот сделать, что атомарнее
S.Chushkin
Пофигист
Думаю, что понял, - сделать многопоточную обработку записей в таблице.
Там ТС использует SELECT, чтобы получить ИД записи, которая будет позже изменена/обработана в этом же потоке. Не лучшее решение, хоть и стандартное (как бы).
Решение с GUID простое, надёжное, быстрое, красивое. Лучше решений нет. Или я о них не знаю.
Не, все он понял.
Красивое решение.
Сгенерил UUID, проапдейтил с нужным order by и limit 1, а потом по этому же UUID селектнул.
Только еще timestamp надо, чтобы, если воркер сдох, по таймауту UUID обнулить.
скажи, а рассматривается только mysql? как насчет redis?Гриш, ну в данном случае вопрос не в диссертации а в небольшом усилии чтобы вникнуть в задачу
Которая состоит не в том чтобы прочитать определенную строку, а в том что мы читаем в несколько потоков случайные строки, и чтобы потоки не делали работу друг друга. То есть мы при чтении заранее не знаем, какую строку мы хотм залочить.
Ну это в 5-м появились стримы. А чтобы на 3-м сделать надежную очередь с многопоточкой, я lua-скрипты делал
Тогда мешало отсутствие 5-го redis-а и машины времени.
А вообще, если производительность становится проблемой, это повод использовать специализированные решения для очередей. Тут явно вопрос в том, как обойтись БД, и автор вопроса вряд ли столкнется с проблемой производительности на своих полутора пользователях
А вообще, если производительность становится проблемой, это повод использовать специализированные решения для очередей. Тут явно вопрос в том, как обойтись БД, и автор вопроса вряд ли столкнется с проблемой производительности на своих полутора пользователях
Гриш, мопед не мой. Я только объяву разместил
(интересно, кто-то помнит ещё этот один из первых мемасиков?)
Спасибо
Про таймстамп, кстати я сам сообразил (хоть что-то!), там в моем ответе про это написано.
Тоже думал, не писать ли прямо в полсе стутс но потом решил не смешивать сущности и отдельным полем
Последнее редактирование:
Ясно, спасибо. Я почему-то не додумал, что апдейт действительно атомарный.