Intégration de base de données native avec @DBFUNCTION

Oracle GoldenGate fournit de puissantes fonctionnalités de transformation lors de la réplication de données, notamment la possibilité d'appeler des fonctions résidant dans la base de données via la structure @DBFUNCTION. Cette fonctionnalité permet aux entreprises d'intégrer directement le traitement basé sur l'IA, tel que la génération d'intégration de vecteurs, dans le pipeline de réplication de données, éliminant ainsi la nécessité d'étapes de post-traitement distinctes et permettant un véritable enrichissement des données d'IA en temps réel.

La fonctionnalité @DBFUNCTION permet aux processus de réplication GoldenGate d'exécuter des fonctions côté base de données en ligne lorsque les données sont appliquées au système cible. Ainsi, chaque transaction étant répliquée, une logique supplémentaire, telle que la génération d'intégrations à partir de texte, peut être exécutée dans le contexte de la base de données. En intégrant la logique de transformation directement dans le flux de réplication, les entreprises peuvent s'assurer que les données vectorielles sont créées de manière synchrone avec l'assimilation des données, tout en maintenant la cohérence et en minimisant la latence.

Un workflow d'intégration en temps réel classique utilisant GoldenGate et @DBFUNCTION se déroule comme suit :

Une transaction source est capturée par le processus d'extraction GoldenGate.
Les données de modification sont transmises à l'environnement cible à l'aide du fichier trace GoldenGate.
Le processus Replicat applique la transaction et appelle @DBFUNCTION pour appeler une fonction d'intégration résidant dans la base de données. Dans l'exemple suivant, l'appel @DBFUNCTION appelle en fait une fonction de wrapper PL/SQL qui exécuterait la fonction d'intégration la plus complexe.
L'intégration est générée en temps réel et stockée dans une table cible, généralement dans une colonne VECTOR pour les cas d'utilisation d'IA en aval et de recherche de similarité. Ce flux étroitement intégré garantit que les intégrations sont toujours synchronisées avec les données source correspondantes, tout en maintenant la cohérence transactionnelle. L'exemple suivant illustre comment @DBFUNCTION peut être utilisé dans une configuration de mise en correspondance GoldenGate pour générer des incorporations à partir de données de texte :
```
  MAP schema.source_table, TARGET schema.target_table,
        COLMAP (
        USEDEFAULTS,
        vector_col = @DBFUNCTION(
            OGGADMIN.CREATE_VECTOR(@AFTER.address, @AFTER.city)
       )
     );
```

Dans cet exemple, la fonction OGGADMIN.CREATE_VECTOR est exécutée pour chaque ligne répliquée, en utilisant les données entrantes de l'adresse et de la ville comme entrée pour transformer le texte brut en une représentation vectorielle au moment de l'application. OGGADMIN.CREATE_VECTOR va intégrer les données. Les méthodes courantes sont les appels de package VECTOR_EMBEDDING() ou DBMS_VECTOR.UTL_TO_EMBEDDING().

@DBFUNCTION Meilleures pratiques

Pour assurer un fonctionnement efficace et fiable, plusieurs bonnes pratiques doivent être suivies lors de l'utilisation de @DBFUNCTION pour l'intégration en temps réel. Les fonctions d'intégration doivent être conçues pour être déterministes et hautement performantes, car elles sont exécutées dans le chemin de réplication et peuvent avoir un impact direct sur le débit.

Dans la mesure du possible, les entreprises doivent tirer parti des fonctionnalités d'Oracle AI Vector Search ou appeler des services d'IA externes via des wrappers PL/SQL optimisés pour l'intégration de la génération. Des mécanismes robustes de gestion des erreurs et de nouvelle tentative doivent être implémentés pour résoudre les défaillances transitoires lors de l'intégration de la génération, en particulier lorsque des services externes sont impliqués.

Enfin, les fonctions longues ou gourmandes en ressources doivent être évitées ou déchargées, car elles peuvent introduire un décalage de réplication et réduire l'évolutivité globale du système. Récapitulatif du modèle d'intégration : choisissez @AISERVICE pour l'inférence externe ou soutenue par GPU, choisissez @DBFUNCTION pour la logique d'intégration résidant dans la base de données et envisagez l'intégration asynchrone lorsque des appels synchrones créent un décalage d'application.