Comments 7
1) У вас действительно в схеме БД сделано order_id bigserial
? Или это опечатка?
2) Пробовали потюнить автовакуум вообще и ля это таблицы в частности?
3) Как у вас реализовано удаление строк из этой таблицы? Меня смутило отсутствие индекса по order_id.
Насколько сложный процессинг событий? Возможен ли ретрай?
Спрашиваю потому, что обычно обработка проходит хорошо и можно сделать батчинг получения и проставления статусов, чтобы уменьшить нагрузку на БД в запросах.
Подходит для сценариев, когда нужно просто в кафку переложить.
Обработка разная в зависимости от статуса. Но я могу заблуждаться, код обработчика почти не трогался, а дело было 2.5 года назад.
Ретрай будет всегда на rollback
Для батчинга необходима группировка по order_id или пришлось бы городить какой-нибудь CTE например, в первом случае запрос будет работать медленно, ибо снова в группировке соберем всё мёртвые слепки, во втором случае - не удобно, и по факту каждый CTE отдельный запрос, из плюсов только экономия на сетевых запросах.
проблема — таблица events находится в уже нагруженной и большой БД
Можно было бы, конечно, поставить новый инстанс базы
решение оказалось проще, чем мы думали: просто отказались от Redis.
уважаю ваш героизм, но что-то в корне неверное произошло
Как мы в Delivery Club outbox оптимизировали