Хм... Звучит интересно. Надо подумать. В нашем проекте, естественно, не такая примитивная логика - она сопряжена с возможностью сохранения черновиков товаров, валидацией информации, взаимодействием со сторонними ресурсами, поэтому пока не могу однозначно сказать, что будет ли достаточно хранения в Postgres только команд, а не сущностей.
Если я правильно понял вашу мысль, то в этом случае всю логику обновления/удаления придется выносить на уровень приложения. Это рабочий вариант, но он увеличит время транзакции, также вырастет объем данных, передаваемых по сети между базой и приложением.
Соглашусь, удовольствие - так себе. Но надо признать, что в целом работа с json возможна и достаточно эффективна по сравнению с большим количеством join-ов (это отсылка к статье "Замена EAV на JSONB в PostgreSQL").
Да, действительно так и есть. Я этот момент не учел. Спасибо за замечание! Однако Debezium 2.4.0.FINAL пока еще может работать только с primary серверами Postgres. PostgreSQL 16 introduces logical replication from standby servers; however, this feature has not yet been tested by Debezium and will be a feature introduced in a later build of Debezium. For now, logical replication remains only supported via the primary. https://debezium.io/blog/2023/10/03/debezium-2-4-final-released/ Debezium версии 2.5 (еще в development) это исправит https://issues.redhat.com/browse/DBZ-7181
Спасибо за замечание! Да, действительно с таким подходом будет более стабильная архитектура. Тут можно было бы использовать, например, Postgres в качестве основной базы для заказов и Debezium в качестве source / sink Kafka connector. В статье же я придерживался того подхода, который предлагают в Confluent, где они используют саму Kafka в качестве single source of truth.
Хм... Звучит интересно. Надо подумать. В нашем проекте, естественно, не такая примитивная логика - она сопряжена с возможностью сохранения черновиков товаров, валидацией информации, взаимодействием со сторонними ресурсами, поэтому пока не могу однозначно сказать, что будет ли достаточно хранения в Postgres только команд, а не сущностей.
Если я правильно понял вашу мысль, то в этом случае всю логику обновления/удаления придется выносить на уровень приложения. Это рабочий вариант, но он увеличит время транзакции, также вырастет объем данных, передаваемых по сети между базой и приложением.
Соглашусь, удовольствие - так себе. Но надо признать, что в целом работа с json возможна и достаточно эффективна по сравнению с большим количеством join-ов (это отсылка к статье "Замена EAV на JSONB в PostgreSQL").
Да, действительно так и есть. Я этот момент не учел. Спасибо за замечание! Однако Debezium 2.4.0.FINAL пока еще может работать только с primary серверами Postgres. PostgreSQL 16 introduces logical replication from standby servers; however, this feature has not yet been tested by Debezium and will be a feature introduced in a later build of Debezium. For now, logical replication remains only supported via the primary. https://debezium.io/blog/2023/10/03/debezium-2-4-final-released/ Debezium версии 2.5 (еще в development) это исправит https://issues.redhat.com/browse/DBZ-7181
Спасибо за замечание! Да, действительно с таким подходом будет более стабильная архитектура. Тут можно было бы использовать, например, Postgres в качестве основной базы для заказов и Debezium в качестве source / sink Kafka connector. В статье же я придерживался того подхода, который предлагают в Confluent, где они используют саму Kafka в качестве single source of truth.
Спасибо за совет! Добавил)