Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Joindre les données de plusieurs tables pour les intégrer dans un seul document
La joins configuration du plugin source RDS permet la dénormalisation automatique des tables relationnelles normalisées en documents uniques. OpenSearch Une fois configuré, le pipeline lit les événements de capture des données de modification (CDC) à partir de plusieurs tables associées et les fusionne dans un document parent à l'aide d'upserts basés sur des scripts Painless.
Cette rubrique explique comment configurer les jointures de tables dans les pipelines d'ingestion Aurora et Amazon RDS, notamment les types de jointure, les conditions requises, la syntaxe de configuration, le suivi des versions et la résolution des problèmes courants.
Conditions préalables
-
Compréhension de base des concepts de base de données relationnelle, notamment les clés primaires, les clés étrangères et les relations entre les tables.
-
Tables avec des relations de clé étrangère (parent-enfant).
-
Toutes les tables
relationsdoivent être répertoriées danstables.include. -
La table parent doit avoir une clé primaire.
-
Les tables enfants doivent comporter une colonne faisant référence à la clé primaire du parent.
-
Les tables enfants doivent avoir leur propre clé primaire (
child_primary_key) pour identifier les enregistrements individuels dans les upserts.
Modèles de jointure pris en charge
-
Parent → Enfant (1:1)
-
Parent → Enfant (1:N)
-
Plusieurs enfants par parent
Exemple de configuration
La configuration YAML suivante montre comment définir les relations de table parent-enfant pour le plug-in source Aurora. Cet exemple configure une table parent avec deux tables enfants utilisant différents types de jointure :
version: "2" aurora-joins-pipeline: source: rds: db_identifier: "my-aurora-cluster" engine: "aurora-mysql" database: "my_database" tables: include: - "parent_table" - "child_table_1" - "child_table_2" s3_bucket: "my-pipeline-bucket" s3_region: "us-east-1" s3_prefix: "rds-export" export: kms_key_id: "my-kms-key-id" iam_role_arn: "arn:aws:iam::123456789012:role/my-export-role" stream: true aws: sts_role_arn: "arn:aws:iam::123456789012:role/my-pipeline-role" region: "us-east-1" authentication: username: ${{aws_secrets:secret:username}} password: ${{aws_secrets:secret:password}} joins: version_field: "__versions" relations: - parent: "parent_table" child: "child_table_1" parent_key: "id" child_key: "parent_id" child_primary_key: "child_id" join_type: "one_to_many" max_child_records: 100 - parent: "parent_table" child: "child_table_2" parent_key: "id" child_key: "parent_id" child_primary_key: "child_id" join_type: "one_to_one" sink: - opensearch: hosts: ["https://search-mydomain.us-east-1.es.amazonaws.com"] index: "my-joined-index" document_id: "${getMetadata(\"primary_key\")}" action: "${getMetadata(\"opensearch_action\")}" aws: sts_role_arn: "arn:aws:iam::123456789012:role/my-pipeline-role" region: "us-east-1" extension: aws: secrets: secret: secret_id: "arn:aws:secretsmanager:us-east-1:123456789012:secret:my-db-secret" region: "us-east-1" sts_role_arn: "arn:aws:iam::123456789012:role/my-pipeline-role" refresh_interval: PT1H
Types de jointures
- un à un
-
Les champs enfants sont aplatis à la racine du document parent. À utiliser lorsque chaque parent a exactement un enregistrement d'enfant associé.
Parent table: orders (order_id, customer_name, total) Child table: shipping (shipping_id, order_id, tracking_number, carrier) Result document: { "order_id": 1, "customer_name": "Alice", "total": 299.99, "shipping_id": "1", "tracking_number": "TRK-1", "carrier": "FedEx" } - un à plusieurs
-
Les enregistrements des enfants sont stockés sous forme de tableau imbriqué dans le document parent. À utiliser lorsque chaque parent peut avoir plusieurs fiches enfant associées.
Parent table: orders (order_id, customer_name, total) Child table: order_items (item_id, order_id, product_name, quantity, price) Result document: { "order_id": 1, "customer_name": "Alice", "total": 299.99, "order_items": [ {"item_id": 10, "product_name": "Keyboard", "quantity": 1, "price": 149.99}, {"item_id": 11, "product_name": "Mouse", "quantity": 1, "price": 29.99} ] }
Structure du document
- Numéro du document
-
Le OpenSearch document
_idest défini sur la valeur de la clé primaire de la table parent. Tous les enregistrements d'enfants d'un même parent sont fusionnés dans ce document unique. - Suivi des versions
-
Le
version_field(par défaut :__versions) stocke une carte des compteurs de versions par table :"__versions": { "orders": 12345678901, "order_items": 12345678902, "shipping": 12345678903 }La version de chaque table est dérivée de l'horodatage d'exportation ou de l'horodatage binlog. Lorsqu'une exportation ou un événement CDC arrive, le script Painless vérifie si la version entrante est plus récente que la version stockée pour cette table spécifique. S'il est plus ancien, l'événement est ignoré. Cela garantit :
-
Traitement idempotent : les événements rejoués sont ignorés en toute sécurité.
-
Versionnage indépendant : la mise à jour d'une commande n'interfère pas avec les mises à jour des articles.
-
Sécurité simultanée : plusieurs encarts pour enfants destinés au même parent sont gérés correctement.
-
- _Version du document
-
Le OpenSearch
_versionchamp augmente à chaque insertion réussie. Pour un document comportant 1 parent + N articles + 1 enregistrement d'expédition,_version= N + 2.
Limitations
-
Single-level se joint uniquement : parent → enfant. Multi-level (parent → enfant → petit-enfant) n'est pas pris en charge.
-
Une table parent par pipeline. Toutes les tables pour enfants sont reliées au même parent.
-
Les tables pour enfants ne peuvent pas appartenir à plusieurs parents dans le même pipeline.
-
max_child_recordslimite la taille du tableau pour lesone_to_manyjointures. Les enregistrements dépassant cette limite sont supprimés.
Conflits de noms de champs
Pour les one_to_one jointures, les champs enfants sont aplatis au niveau de la racine. Si une table enfant possède une colonne portant le même nom qu'une colonne parent, la valeur enfant remplace la valeur parent. Utilisez des noms de colonne distincts pour les tables parent et one_to_one enfant.
Pour les one_to_many jointures, les champs enfants sont imbriqués dans un tableau nommé d'après la table enfant, de sorte que les conflits ne constituent pas un problème.
Résolution des problèmes
- Documents, dossiers d'enfants manquants
-
-
Vérifiez
__versionsle document. Si la version d'une table enfant est manquante, les événements enfants n'ont pas encore été traités. -
Vérifiez que le pipeline est actif et que la
changeEventsProcessedmétrique est différente de zéro.
-
- Documents ne figurant pas dans OpenSearch
-
-
Vérifiez si l'enregistrement parent existe dans la table source.
-
Vérifiez que la
tables.includeliste contient toutes les tables requises. -
Vérifiez les journaux du pipeline pour détecter les échecs d'ingestion et les problèmes de configuration :
/aws/vendedlogs/.pipeline-log-group
-