Избежать конкуренции при многопоточной обработке данных в БД

Задача проще пареной репы. И сводится к получению изменённой записи (её ИД).
Я могу ошибаться, но мне кажется то ты не понял задачу.
Очень многие её не понимают, и думают что она сводится к другой, им теоретически знакомой.

Там перед апдейтом есть еще селект.
 
Я могу ошибаться, но мне кажется то ты не понял задачу.
Очень многие её не понимают, и думают что она сводится к другой, им теоретически знакомой.

Там перед апдейтом есть еще селект.
Думаю, что понял, - сделать многопоточную обработку записей в таблице.
Там ТС использует SELECT, чтобы получить ИД записи, которая будет позже изменена/обработана в этом же потоке. Не лучшее решение, хоть и стандартное (как бы).
Решение с GUID простое, надёжное, быстрое, красивое. Лучше решений нет. Или я о них не знаю.
 
Я могу ошибаться, но мне кажется то ты не понял задачу.
Очень многие её не понимают, и думают что она сводится к другой, им теоретически знакомой.

Там перед апдейтом есть еще селект.
Не, все он понял.

Красивое решение.

Сгенерил UUID, проапдейтил с нужным order by и limit 1, а потом по этому же UUID селектнул.

Только еще timestamp надо, чтобы, если воркер сдох, по таймауту UUID обнулить.
 
Гриш, ну в данном случае вопрос не в диссертации а в небольшом усилии чтобы вникнуть в задачу :)
Которая состоит не в том чтобы прочитать определенную строку, а в том что мы читаем в несколько потоков случайные строки, и чтобы потоки не делали работу друг друга. То есть мы при чтении заранее не знаем, какую строку мы хотм залочить.
скажи, а рассматривается только mysql? как насчет redis?
 
и что мешает добавить контейнер с 5м редисом для стримов? :)
 
update - это хорошее и надежное решение, но надо не забывать, что операция дорогая и не масштабируемая
 
Тогда мешало отсутствие 5-го redis-а и машины времени. :)

А вообще, если производительность становится проблемой, это повод использовать специализированные решения для очередей. Тут явно вопрос в том, как обойтись БД, и автор вопроса вряд ли столкнется с проблемой производительности на своих полутора пользователях :)
 
Не, все он понял.
Красивое решение.
Спасибо :)
Про таймстамп, кстати я сам сообразил (хоть что-то!), там в моем ответе про это написано.
Тоже думал, не писать ли прямо в полсе стутс но потом решил не смешивать сущности и отдельным полем
 
Последнее редактирование:
Сверху