View a markdown version of this page

Unire i dati di più tabelle per inserirli in un unico documento - OpenSearch Servizio Amazon
PrerequisitiSchemi di unione supportatiConfigurazione di esempioTipi di joinStruttura del documentoLimitazioniRisoluzione dei problemi

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Unire i dati di più tabelle per inserirli in un unico documento

La joins configurazione nel plug-in sorgente RDS consente la denormalizzazione automatica delle tabelle relazionali normalizzate in singoli documenti. OpenSearch Una volta configurata, la pipeline legge gli eventi CDC (Change Data Capture) da più tabelle correlate e li unisce in un documento principale utilizzando upsert basati su script Painless.

Questo argomento spiega come configurare i join di tabella nelle pipeline di ingestione di Aurora e Amazon RDS, inclusi i tipi di join, i prerequisiti, la sintassi di configurazione, il monitoraggio delle versioni e la risoluzione dei problemi più comuni.

Prerequisiti

  • Comprensione di base dei concetti dei database relazionali, tra cui chiavi primarie, chiavi esterne e relazioni tra tabelle.

  • Tabelle con relazioni tra chiavi esterne (padre-figlio).

  • Tutte le tabelle relations devono essere elencate in. tables.include

  • La tabella principale deve avere una chiave primaria.

  • Le tabelle secondarie devono avere una colonna che faccia riferimento alla chiave primaria del genitore.

  • Le tabelle secondarie devono avere la propria chiave primaria (child_primary_key) per identificare i singoli record negli upsert.

Schemi di unione supportati

  • Genitore → Figlio (1:1)

  • Genitore → Figlio (1:N)

  • Più figli per genitore

Configurazione di esempio

La seguente configurazione YAML mostra come definire le relazioni tra tabelle padre-figlio per il plugin sorgente Aurora. Questo esempio configura una tabella principale con due tabelle secondarie utilizzando diversi tipi di join:

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

Tipi di join

uno a uno

I campi secondari vengono appiattiti al livello principale del documento principale. Da utilizzare quando ogni genitore ha esattamente un record secondario correlato.

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"
}
uno a molti

I record secondari vengono memorizzati come matrice annidata nel documento principale. Da utilizzare quando ogni genitore può avere più record secondari correlati.

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}
  ]
}

Struttura del documento

ID del documento

Il OpenSearch documento _id è impostato sul valore della chiave primaria della tabella principale. Tutti i record secondari dello stesso genitore vengono uniti in questo unico documento.

Monitoraggio delle versioni

version_field(impostazione predefinita:__versions) memorizza una mappa dei contatori delle versioni per tabella:

"__versions": {
  "orders": 12345678901,
  "order_items": 12345678902,
  "shipping": 12345678903
}

La versione di ogni tabella è derivata dal timestamp di esportazione o dal timestamp binlog. Quando arriva un evento di esportazione o CDC, lo script Painless verifica se la versione in entrata è più recente della versione memorizzata per quella tabella specifica. Se precedente, l'evento viene ignorato. Ciò garantisce:

  • Elaborazione idempotente: gli eventi riprodotti vengono ignorati in modo sicuro.

  • Versioni indipendenti: un aggiornamento degli ordini non interferisce con gli aggiornamenti degli articoli.

  • Sicurezza simultanea: più inserti secondari per lo stesso genitore vengono gestiti correttamente.

_versione del documento

Il OpenSearch _version campo aumenta con ogni ribaltamento riuscito. Per un documento con 1 genitore + N articoli +1 record di spedizione, _version = N + 2.

Limitazioni

  • Single-level si unisce solo a: genitore → figlio. Multi-level (genitore → figlio → nipote) non è supportato.

  • Una tabella principale per pipeline. Tutte le tabelle secondarie si uniscono allo stesso elemento principale.

  • Le tabelle secondarie non possono appartenere a più genitori nella stessa pipeline.

  • max_child_recordslimita la dimensione dell'array per i one_to_many join. I record che superano questo limite vengono eliminati.

Conflitti tra nomi di campo

Per i one_to_one join, i campi secondari vengono appiattiti a livello principale. Se una tabella figlio ha una colonna con lo stesso nome di una colonna principale, il valore figlio sovrascrive il valore principale. Utilizzate nomi di colonna distinti nelle tabelle principali e one_to_one secondarie.

Per i one_to_many join, i campi figlio sono annidati all'interno di un array che prende il nome dalla tabella secondaria, quindi i conflitti non sono un problema.

Risoluzione dei problemi

Documenta i record dei bambini mancanti

  • __versionsArchivia il documento. Se manca la versione di una tabella secondaria, gli eventi secondari non sono ancora stati elaborati.

  • Verifica che la pipeline sia attiva e che la changeEventsProcessed metrica sia diversa da zero.

Documenti non presenti in OpenSearch

  • Controlla se il record principale esiste nella tabella di origine.

  • Verifica che l'tables.includeelenco contenga tutte le tabelle obbligatorie.

  • Controlla i log della pipeline per errori di importazione e problemi di configurazione:. /aws/vendedlogs/pipeline-log-group