Cenário
Eu tenho um pipeline de dados que está transmitindo para um cluster postgres. Não tenho controle sobre a fonte de dados de streaming, mas sim propriedade total do destino. Pretendo ter processos que pesquisem o banco de dados em busca de quaisquer dados pertinentes que tenham sido alterados desde a última execução e sincronizem outros sistemas (variantes, não bancos de dados).
Emitir
Infelizmente, o pipeline que grava esses registros não fornece um carimbo de data/hora preciso para a data de modificação ou qualquer tipo de nonce que possa rastrear quais registros foram alterados desde o último processo de pesquisa sincronizado.
Algumas notas extras:
- Exclusão reversível de registros
- O pipeline está replicando um data lake, portanto há um grande volume de dados e mudanças acontecendo o tempo todo
- É fundamental que os processos de sincronização de votação não percam nenhuma alteração
O que eu tentei
Eu criei algumas abordagens para resolver isso, mas não tenho certeza de qual é a melhor abordagem para este caso de uso.
Abordagem 1 : adicione uma date_modified
coluna a cada uma das tabelas de destino e um gatilho para atualizar o carimbo de data/hora sempre que ocorrer uma atualização. Isso parece leve e simples.
Abordagem 2: a replicação lógica era atraente, mas não parecia haver uma maneira de adicionar qualquer tipo de metadado que pudesse ajudar (como o tempo de replicação).
Abordagem 3: usar uma tabela de auditoria e gatilhos que capturariam e atribuiriam um ID de evento funcionaria, mas a compensação com o desempenho é preocupante e não consigo ver diferença no uso da Abordagem 1 para este caso de uso específico.
O que espero ter respondido
Com base no exposto, parece que a resposta é simplesmente usar a Abordagem 1 . Posso então rastrear o último carimbo de data/hora que foi sincronizado usando os processos de pesquisa e simplesmente extrair registros que possuem um carimbo de data/hora posterior das tabelas.
Existem desvantagens na Abordagem 1 que não estou vendo? Ou existem outros caminhos melhores para conseguir isso?
Talvez imaginemos o papel da replicação lógica do Postgres neste cenário de forma diferente. Vejo que ele está sendo usado no final do "pipeline de dados que está transmitindo para um cluster Postgres", depois que as alterações foram feitas no banco de dados Postgres, porque é disso que você precisa: replicar as alterações no banco de dados para "outros sistemas ".
Você pode configurar um decodificador lógico, como
pg_recvlogical
, para capturar, pré-processar e enviar as alterações posteriormente. Por exemplo, o mencionado acimapg_recvlogical
, junto com um plugin como owal2json
, poderia produzir um fluxo contínuo de objetos JSON que representam as alterações no banco de dados Postgres em tempo real, conforme elas acontecem, em vez de pesquisar as alterações.Se por algum motivo você precisar usar a sondagem, poderá salvar o fluxo de alterações em um arquivo e simplesmente truncar o arquivo quando o processo de sondagem estiver concluído.
Em ambos os casos, não há necessidade de injetar metadados extras no fluxo de mudança.