Processamento eficiente da diferença entre dados de entrada e banco de dados

Eu tenho um conjunto de dados de entrada cujos registros serão anexados a um banco de dados existente. Antes de serem anexados, os dados passam por um processamento pesado e demorado. Desejo filtrar os registros do conjunto de dados de entrada que já existem no banco de dados para reduzir o tempo de processamento.

A diferença entre a entrada e o banco de dados é ilustrada aqui:

Esta é uma visão geral do tipo de processo que estou analisando. Os dados de entrada eventualmente serão alimentados no banco de dados.

Minha solução atual envolve o uso de um transformador Matcher no banco de dados e na entrada combinados e, em seguida, filtrar o resultado NotMatched usando um FeatureTypeFilter para reter apenas os registros de entrada.

Existe uma maneira mais eficiente de obter os recursos de diferença?

Se você tiver as características do banco de dados indicadas pelo diagrama. Entrada pequena, sobreposição minúscula, alvo grande. Em seguida, o seguinte tipo de espaço de trabalho poderá funcionar com bastante eficiência, mesmo que ele faça várias consultas no banco de dados.

Portanto, para cada recurso, leia a consulta de entrada do recurso correspondente no banco de dados. Verifique se há índices adequados no local. Teste o atributo _matched_records para 0, faça o processamento e insira no banco de dados.

Não usei o FME, mas tinha uma tarefa de processamento semelhante que exigia o uso de uma tarefa de processamento de 5 horas para identificar três possíveis casos de processamento para um banco de dados paralelo através de um link de rede de baixa largura de banda:

• Novos recursos a serem adicionados
• Recursos existentes a serem atualizados
• Recursos existentes a serem excluídos

Como eu tinha a garantia de que todos os recursos manteriam valores únicos de ID entre passes, eu pude:

1. Execute um script de processamento que gerou uma tabela de pares {uID, checksum} nas colunas importantes da tabela atualizada
2. Usaram os pares {uID, checksum} gerados na iteração anterior para transmitir atualizações para a tabela de destino com as linhas na tabela atualizada em que o uID estava IN em uma subconsulta na qual as somas de verificação não correspondiam
3. Transmitir inserções da tabela atualizada que uma subconsulta de junção externa indicou possuir uIDs incomparáveis ​​e
4. Transmitiu uma lista de uIDs para excluir recursos na tabela externa que uma subconsulta de junção externa indicou que não tinha mais uIDs correspondentes na tabela atual
5. Salve os pares atuais {uID, checksum} para a operação do dia seguinte

No banco de dados externo, eu apenas precisei inserir os novos recursos, atualizar os deltas, preencher uma tabela temporária de uIDs excluídos e excluir os recursos na tabela de exclusão.

Consegui automatizar esse processo para propagar centenas de alterações diárias em uma tabela de 10 milhões de linhas com um impacto mínimo na tabela de produção, usando menos de 20 minutos de tempo de execução diário. Ele foi executado com custo administrativo mínimo por vários anos sem perder a sincronização.

Embora seja certamente possível fazer comparações de N entre M linhas, o uso de um resumo / soma de verificação é uma maneira muito atraente de realizar um teste "existe" com custo muito menor.

Use featureMerger, juntando e agrupando pelos campos comuns de DATABASE AND INPUT DATA.