Как мы в Delivery Club outbox оптимизировали

[IvanVakhrushev]

1) У вас действительно в схеме БД сделано order_id bigserial ? Или это опечатка?

2) Пробовали потюнить автовакуум вообще и ля это таблицы в частности?

3) Как у вас реализовано удаление строк из этой таблицы? Меня смутило отсутствие индекса по order_id.

[RomanKantorovich]

1) Очепятка :) должен быть bigint

2) Да, всё настройки были выкручены по максимуму админами, самих настроек у меня к сожалению не осталось

3) По primary_key, по order_id удалять нельзя, иначе можем затереть несколько событий. У заказа может быть несколько событий в таблице одновременно.

[Gromilo]

Насколько сложный процессинг событий? Возможен ли ретрай?

Спрашиваю потому, что обычно обработка проходит хорошо и можно сделать батчинг получения и проставления статусов, чтобы уменьшить нагрузку на БД в запросах.
Подходит для сценариев, когда нужно просто в кафку переложить.

[RomanKantorovich]

1. Обработка разная в зависимости от статуса. Но я могу заблуждаться, код обработчика почти не трогался, а дело было 2.5 года назад.

2. Ретрай будет всегда на rollback

3. Для батчинга необходима группировка по order_id или пришлось бы городить какой-нибудь CTE например, в первом случае запрос будет работать медленно, ибо снова в группировке соберем всё мёртвые слепки, во втором случае - не удобно, и по факту каждый CTE отдельный запрос, из плюсов только экономия на сетевых запросах.

[karrakoliko]

проблема — таблица events находится в уже нагруженной и большой БД

Можно было бы, конечно, поставить новый инстанс базы

решение оказалось проще, чем мы думали: просто отказались от Redis.

уважаю ваш героизм, но что-то в корне неверное произошло

[Gromilo]

Редис тоже подыхал

[RomanKantorovich]

А в чем вопрос?)