Я про те, що це декілька операцій -

select record_id, ... where lock_record = true
update ... set lock_record=true where record_id = id

а select ... for update, який типу атомарний, лочить таблицю.


On 9/14/24 21:08, Taras Heichenko wrote:
>
> 14.09.2024 22:06, Vladimir A. Podgorny:
>> Хіба якщо СУБД вміє per-row lock. Якщо лочить таблицю, то краще вже
>> кріль...
>
> Ну звичайно лочка на рівні записів. Але оскільки з базою в цьому
> випадку працюють тільки твої тулзи, то лочкою запису може бути,
> наприклад, true в полі lock_record ;)
>
>>
>> сб, 14 вер. 2024, 22:04 користувач Taras Heichenko
>> <tasic@academ.kiev.ua> пише:
>>
>>
>>     12.09.2024 19:08, Volodymyr Litovka via UANOG:
>>     > Я не захваті від ідеї використовувати БД як queue.
>>     >
>>     > Одна з причин - у черги операція "взяв в обробоку" атомарна,
>>     тобто як
>>     > тільки воркер забрав повідомлення, воно зникає й, відповідно, не
>>     > попаде нікому іншому в обробку. У випадку з БД це процедура з
>>     > щонайменше з двох кроків - "взяв в обробку, видалив з БД", тобто
>>     одне
>>     > повідомлення може бути взято в обробку одразу декількома
>> воркерами.
>>
>>     Ну взагалі то "залочив, взяв в обробку, обробив, видалив"
>>
>>     >
>>     > On 9/12/24 17:44, Mykola Ulianytskyi wrote:
>>     >> Привіт
>>     >>
>>     >> >  - якщо хтось юзає ребіт під навантаженням - що думає?
>>     >>
>>     >> Дико тормозить при великої кількості (десятки тисяч) queues /
>>     streams
>>     >> / channels да так, що API лежить повністю.
>>     >> Vertical scaling не вирішив проблему (32 ядра, 64GB RAM).
>>     >>
>>     >> Переписали мікросервіс на MongoDB InMemory (Percona Memory
>>     Engine) та
>>     >> забули про всі проблеми з перфомансом.
>>     >>
>>     >> --
>>     >> Best regards,
>>     >> Mykola
>>     >>
>>     >>
>>     >> On Thu, Sep 12, 2024 at 6:30 PM Volodymyr Litovka via UANOG
>>     >> <uanog@uanog.one> wrote:
>>     >>
>>     >>     Привіт,
>>     >>
>>     >>     порадьте менеджер черг для високонавантажених систем, окрім
>>     >>     RabbitMQ.
>>     >>     Про цього чувака я знаю, але колеги з розробки кажуть, що він
>>     >>     косячить
>>     >>     під високим навантаженням. Я не можу ані підтвердити, ані
>>     >>     спростувати це
>>     >>     твердження - я його користував тіко в комплекті з
>>     опенстеком, де
>>     >>     у мене
>>     >>     не було ані навантаження, ані проблем.
>>     >>
>>     >>     Тому, насправді, питання два:
>>     >>     - порадьте менеджер черг для високонавантажених систем, окрім
>>     >>     RabbitMQ
>>     >>     - якщо хтось юзає ребіт під навантаженням - що думає?
>>     >>
>>     >>     Дякую.
>>     >>
>>     >>     --
>>     >>     Volodymyr Litovka
>>     >>        "Vision without Execution is Hallucination." -- Thomas
>>     Edison
>>     >>
>>     >>  _______________________________________________
>>     >>     UANOG mailing list -- uanog@uanog.one
>>     >>     To unsubscribe send an email to uanog-leave@uanog.one
>>     >>
>>     >
>>     > --
>>     > Volodymyr Litovka
>>     >    "Vision without Execution is Hallucination." -- Thomas Edison
>>     >
>>     > _______________________________________________
>>     > UANOG mailing list -- uanog@uanog.one
>>     > To unsubscribe send an email to uanog-leave@uanog.one
>>
>>     --     tasic@
>>
>>     _______________________________________________
>>     UANOG mailing list -- uanog@uanog.one
>>     To unsubscribe send an email to uanog-leave@uanog.one
>>

--
Volodymyr Litovka
   "Vision without Execution is Hallucination." -- Thomas Edison

_______________________________________________
UANOG mailing list -- uanog@uanog.one
To unsubscribe send an email to uanog-leave@uanog.one