Traitement efficace de la différence entre les données d'entrée et la base de données

J'ai un jeu de données d'entrée dont les enregistrements seront ajoutés à une base de données existante. Avant d'être ajoutées, les données subiront un traitement lourd et long. Je souhaite filtrer les enregistrements de l'ensemble de données d'entrée qui existent déjà dans la base de données pour réduire le temps de traitement.

La différence entre l'entrée et la base de données est illustrée ici:

Voici un aperçu du type de processus que j'examine. Les données d'entrée finiront par alimenter la base de données.

Ma solution actuelle consiste à utiliser un transformateur Matcher sur la base de données et l'entrée combinées, puis à filtrer le résultat NotMatched à l'aide d'un FeatureTypeFilter pour conserver uniquement les enregistrements d'entrée.

Existe-t-il un moyen plus efficace d'obtenir les fonctionnalités de différence?

Si vous avez les caractéristiques de la base de données indiquées par le diagramme. Petite entrée, petit chevauchement, grande cible. Ensuite, le type d'espace de travail suivant peut fonctionner assez efficacement, même s'il effectuera plusieurs requêtes sur la base de données.

Ainsi, pour chaque entité lue dans la requête d'entrée de l'entité correspondante dans la base de données. Assurez-vous que des index appropriés sont en place. Testez l'attribut _matched_records pour 0, effectuez le traitement, puis insérez-le dans la base de données.

Je n'ai pas utilisé FME, mais j'avais une tâche de traitement similaire qui nécessitait l'utilisation de la sortie d'un travail de traitement de 5 heures pour identifier trois cas de traitement possibles pour une base de données parallèle sur une liaison réseau à faible bande passante:

• De nouvelles fonctionnalités à ajouter
• Fonctionnalités existantes à mettre à jour
• Fonctionnalités existantes à supprimer

Étant donné que j'avais la garantie que toutes les fonctionnalités conserveraient des valeurs d'identification uniques entre les passes, j'ai pu:

1. Exécutez un script de traitement qui a généré une table de paires {uID, checksum} sur les colonnes importantes de la table mise à jour
2. Utilisé les paires {uID, checksum} générées dans l'itération précédente pour transmettre les mises à jour à la table cible avec les lignes de la table mise à jour où l'uID était dans une sous-requête où les sommes de contrôle ne correspondaient pas
3. Transmettre les insertions de la table mise à jour qu'une sous-requête de jointure externe a indiqué avoir des uID sans correspondance, et
4. A transmis une liste d'uID pour supprimer des entités dans la table externe qu'une sous-requête de jointure externe a indiqué ne plus avoir d'uID correspondants dans la table actuelle
5. Enregistrez les paires {uID, checksum} actuelles pour l'opération du lendemain

Sur la base de données externe, je devais simplement insérer les nouvelles fonctionnalités, mettre à jour les deltas, remplir une table temporaire d'uID supprimés et supprimer les fonctionnalités dans la table de suppression.

J'ai pu automatiser ce processus pour propager des centaines de modifications quotidiennes sur une table de 10 millions de lignes avec un minimum d'impact sur la table de production, en utilisant moins de 20 minutes d'exécution quotidienne. Il a fonctionné avec un coût administratif minimal pendant plusieurs années sans perdre la synchronisation.

Bien qu'il soit certainement possible de faire N comparaisons sur M lignes, l'utilisation d'un résumé / somme de contrôle est un moyen très intéressant de réaliser un test «existe» avec un coût beaucoup plus faible.

Utilisez featureMerger, en joignant et en groupant par les champs communs de DATABASE AND INPUT DATA.