PT
Если я сделаю SELECT ... FOR UPDATE LIMIT 1, каждый клиент будет хотеть одну строку. Это уже с учетом того, что у меня индексы будут.
Size: a a a
2020 October 05
PT
Но почему они будут хотеть разные строки, а не одну и ту же?
GK
Если я сделаю SELECT ... FOR UPDATE LIMIT 1, каждый клиент будет хотеть одну строку. Это уже с учетом того, что у меня индексы будут.
Они будут хотеть одну и ту же и ещё другие. Много других. И вы создаёте проблемы для тех кто хочет другие строки, а те кто хотят другие содают проблемы для тех кто вашу.
BI
Но почему они будут хотеть разные строки, а не одну и ту же?
Возможно разные товары, разные строки
PT
Они будут хотеть одну и ту же и ещё другие. Много других. И вы создаёте проблемы для тех кто хочет другие строки, а те кто хотят другие содают проблемы для тех кто вашу.
Если я сделаю
limit 1, то клиент будет хотеть только одну строку.PT
Но загвоздка в том, что все клиенты хотят одну и туже строку.
PT
Возможно разные товары, разные строки
Думаете?
GK
Вы не видите поблем, в том что блокируете больше записей чем нужно?
PT
Так я не блокирую больше чем нужно. У меня будет блокироваться одна запись. В этом нет проблемы.
PT
Если есть индекс, блокируется одна.
GK
И много у вас клиентов конкурируют за одну запись? Сколько времени занимает обновление флага у одной записи?
Si
вам нужен order by random внутри группы
BI
Думаете?
Я предположил то, что имел в виду Геннадий: блочатся строки, которые касаются других товаров. Вы сейчас утверждаете, что при LIMIT 1 лочится одна строка (нюанс - так ли это?) и клиенты хотят только её.
Если одна строка за один товар отвечает и несколько клиентов пытаются его зарезервировать, то просадка логична. Нет?
Как если бы несколько рук сразу потянулось за одной булкой
Если одна строка за один товар отвечает и несколько клиентов пытаются его зарезервировать, то просадка логична. Нет?
Как если бы несколько рук сразу потянулось за одной булкой
PT
вам нужен order by random внутри группы
Вооо. Но тут есть небольшой нюанс - может возникнуть ситуация, когда один и тотже пользователь захочет одну и туже запись.
PT
Я предположил то, что имел в виду Геннадий: блочатся строки, которые касаются других товаров. Вы сейчас утверждаете, что при LIMIT 1 лочится одна строка (нюанс - так ли это?) и клиенты хотят только её.
Если одна строка за один товар отвечает и несколько клиентов пытаются его зарезервировать, то просадка логична. Нет?
Как если бы несколько рук сразу потянулось за одной булкой
Если одна строка за один товар отвечает и несколько клиентов пытаются его зарезервировать, то просадка логична. Нет?
Как если бы несколько рук сразу потянулось за одной булкой
Пользователь хочет один лотерейный билет из нескольких миллионов. Пользователю не важно, какой он будет. Но ему важно, что бы этот билет достался только ему.
PT
Поскольку на сервере все это дело не в один поток обрабатывается, может возникнуть ситуация, когда сразу 100 юзеров придут и скажу - "дай билет". Так вот. SELECT FOR UPDATE очень сильно снизят пропускную способность.
PT
Использование рэнд в группе повышает пропускную способность, но есть кейсы, когда у разных юзеров rand может выдать одну и туже строку. Но это уже что-то.
PT
Может еще варианты есть?
Si
Использование рэнд в группе повышает пропускную способность, но есть кейсы, когда у разных юзеров rand может выдать одну и туже строку. Но это уже что-то.
если товаров в группе больше, чем одновременных юзеров, мне кажется, этим уже можно пренебречь
PT
Возможно. Надо протестировать.