debezium в чем-то сильно проще, в чем-то немного сложнее. Да, отправка через него работает быстрее в общем случае. Из недостатков я бы наверное выделил: 1 - дополнительный элемент в системе, который мы контролируем опосредованно, 2 - либо нужна та же отдельная таблица для событий, либо ещё сервис, который будет интерпретировать изменения основных таблиц и формировать события.
В общем это два подхода, каждый из которых имеет достоинства и недостатки.
Это был почти самый первый комментарий, когда я рассказывал про наши приключения внутри компании) То, что вы описали - это классическая event driven architecture. Отличная штука для высоконагруженных систем. Но и у неё есть свои ограничения)
Как вы написали - консистентность. То есть пользователь после выполнения действия не может рассчитывать на его результат в моменте. Чаще всего получит, но не гарантировано.
Это изменение коснётся всей платформы. Ну точнее той её части, которая зависит от исходного сервиса. А если исходный сервис - это ядро платформы? То есть надо переписать фактически всё.
Ивент драйвен архитектура хороша, когда она заложена на начальных этапах разработки. Плюс в неё тяжелее вкатывать неопытных специалистов (это моё личное мнение, может быть неправдой :) )
Да, это рабочий вариант, спасибо. Были и такие идеи. В данном случае аутбокс - это давнее решение, с которым приходится работать. Переписывать полностью схему отправки пока выглядит дороже сделанных доработок. Если упрёмся в потолок - будем решать)
Да, нагрузка никакая) поэтому проблема была только в моменты, когда приходил вакуум. Из-за настроек и какого-то сбоя в задаче на удаление старых записей пришёл wraparound, который блокирнул всю таблицу)
Сейчас проблем с блокировками нет при insert only и разумном размере партиций.
debezium в чем-то сильно проще, в чем-то немного сложнее. Да, отправка через него работает быстрее в общем случае. Из недостатков я бы наверное выделил: 1 - дополнительный элемент в системе, который мы контролируем опосредованно, 2 - либо нужна та же отдельная таблица для событий, либо ещё сервис, который будет интерпретировать изменения основных таблиц и формировать события.
В общем это два подхода, каждый из которых имеет достоинства и недостатки.
"Лучший аутбокс - это отсутствие аутбокса)))"
Это был почти самый первый комментарий, когда я рассказывал про наши приключения внутри компании) То, что вы описали - это классическая event driven architecture. Отличная штука для высоконагруженных систем. Но и у неё есть свои ограничения)
Как вы написали - консистентность. То есть пользователь после выполнения действия не может рассчитывать на его результат в моменте. Чаще всего получит, но не гарантировано.
Это изменение коснётся всей платформы. Ну точнее той её части, которая зависит от исходного сервиса. А если исходный сервис - это ядро платформы? То есть надо переписать фактически всё.
Ивент драйвен архитектура хороша, когда она заложена на начальных этапах разработки. Плюс в неё тяжелее вкатывать неопытных специалистов (это моё личное мнение, может быть неправдой :) )
Да, именно поэтому мы перешли к реализации на партициях. Тоже не идеальное решение, но нам пока подходит
Да, это рабочий вариант, спасибо. Были и такие идеи. В данном случае аутбокс - это давнее решение, с которым приходится работать. Переписывать полностью схему отправки пока выглядит дороже сделанных доработок. Если упрёмся в потолок - будем решать)
Да, нагрузка никакая) поэтому проблема была только в моменты, когда приходил вакуум. Из-за настроек и какого-то сбоя в задаче на удаление старых записей пришёл wraparound, который блокирнул всю таблицу)
Сейчас проблем с блокировками нет при insert only и разумном размере партиций.