Я не захваті від ідеї використовувати БД як 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 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

Привіт, вірно я розумію, що Кафка (згаданим offset'ом) все ж таки може робити, що будь-яке повідомлення буде прочитано тільки один раз? Наскільки я зрозумів з твоїх слов - офсет оновлюється автоматично й щоб повернутись до старого повідомлення, треба явно відмотати офсет назад. Дякую. On 9/12/24 18:46, Illia Lavrovskyi wrote:

Вітаю.

Підтверджую неадекватну поведінку кластеру кроля під суттєвим навантаженням.

Нажаль про альтернативу йому, щоб архітектурно була 1-до-1 я не знаю.

В якості черги є Kafka - https://kafka.apache.org/ (також є PaaS від Confluent), є Redpanda - https://github.com/redpanda-data/redpanda/, є клаунді рішення. Kafka - це one love. Redpanda виглядає дуже цікаво, але особисто так і не довелося з нею пожити.

Архітектурно у RabbitMQ бачу одну гарну річ - він може гарантувати шо певну повідомленні буде прочитане лише раз, не зважаючи скільки конс'юмерів слухають чергу. З Kafka доведеться робити яку логіку саме не боці конс'юмерів (якщо їх більше одного).

Але Kafka дурнюща в сенсі швидкості і пропускної здатності. І вона по суті є логом повідомлення. Це означає, що якщо певне повідомлення все ще в лозі, але вже давно було опрацьоване - до нього можна легко повернутися (offset) і переопрацювати, чи просто на нього подивитися. В купі разів це було дуже при нагоді, коли щось не спрацювало, ти виправляєш баг, а потім просто скидаєш offset до потрібного і все пробігає вже як треба.

On Thu, Sep 12, 2024 at 6:08 PM Volodymyr Litovka via UANOG wrote:

Я не захваті від ідеї використовувати БД як 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 mailto: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

-- Illia Lavrovskyi e-mail: blackprowler@gmail.com

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

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 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@

14.09.2024 22:06, Vladimir A. Podgorny:

Хіба якщо СУБД вміє per-row lock. Якщо лочить таблицю, то краще вже кріль...

Ну звичайно лочка на рівні записів. Але оскільки з базою в цьому випадку працюють тільки твої тулзи, то лочкою запису може бути, наприклад, true в полі lock_record ;)

сб, 14 вер. 2024, 22:04 користувач Taras Heichenko пише:

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 >> 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

-- tasic@

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

В MongoBD тільки один документ (document-level lock), а не всю колекцію (collection-level lock): https://www.mongodb.com/docs/manual/faq/concurrency/ https://www.mongodb.com/blog/post/how-to-select--for-update-inside-mongodb-t... -- Best regards, Mykola On Sat, Sep 14, 2024 at 10:49 PM Volodymyr Litovka via UANOG wrote:

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

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 пише:

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 >> 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

Привіт! Якщо у тебе дійсно супер велике навантаження, то варто глянути в сторону ZeroMQ. Kafka як можлива альтернатива. А може варто просто правильно приготувати RabbitMQ ? On Thu, Sep 12, 2024 at 9:01 PM Maksym Tulyuk wrote:

Привіт

Можна спробувати: ZeroMQ/Kafka/Mosquitto.

Макс

...

On 12 Sep 2024, at 17:30, Volodymyr Litovka via UANOG 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

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