Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
# Daten aus mehreren Tabellen zusammenführen, um sie in ein Dokument aufzunehmen
Die `joins` Konfiguration im RDS-Quell-Plugin ermöglicht die automatische Denormalisierung von normalisierten relationalen Tabellen in einzelne Dokumente. OpenSearch Wenn sie konfiguriert ist, liest die Pipeline CDC-Ereignisse (Change Data Capture) aus mehreren verwandten Tabellen und führt sie mithilfe skriptbasierter Painless-Upserts zu einem übergeordneten Dokument zusammen.
In diesem Thema wird erklärt, wie Tabellen-Joins in Aurora- und Amazon RDS-Ingestion-Pipelines konfiguriert werden, einschließlich Join-Typen, Voraussetzungen, Konfigurationssyntax, Versionsverfolgung und Behebung häufiger Probleme.
## Voraussetzungen
+ Grundlegendes Verständnis von Konzepten relationaler Datenbanken, einschließlich Primärschlüsseln, Fremdschlüsseln und Tabellenbeziehungen.
+ Tabellen mit Fremdschlüsselbeziehungen (Eltern/Kind).
+ Alle Tabellen in `relations` müssen unter aufgeführt sein. `tables.include`
+ Die übergeordnete Tabelle muss einen Primärschlüssel haben.
+ Untergeordnete Tabellen müssen eine Spalte haben, die auf den Primärschlüssel der übergeordneten Tabelle verweist.
+ Untergeordnete Tabellen müssen über einen eigenen Primärschlüssel (`child_primary_key`) verfügen, mit dem einzelne Datensätze in Upserts identifiziert werden können.
## Unterstützte Verbindungsmuster
+ Elternteil → Kind (1:1)
+ Elternteil → Kind (1:N)
+ Mehrere Kinder pro Elternteil
## Beispielkonfiguration
Die folgende YAML-Konfiguration zeigt, wie Eltern-Kind-Tabellenbeziehungen für das Aurora-Quell-Plugin definiert werden. In diesem Beispiel wird eine übergeordnete Tabelle mit zwei untergeordneten Tabellen konfiguriert, die unterschiedliche Join-Typen verwenden:
```
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
```
## JOIN-Typen
one\_to\_one
Untergeordnete Felder werden auf der Stammebene des übergeordneten Dokuments reduziert. Verwenden Sie diese Option, wenn jedes übergeordnete Element genau einen zugehörigen untergeordneten Datensatz hat.
```
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"
}
```
one\_to\_many
Untergeordnete Datensätze werden als verschachteltes Array im übergeordneten Dokument gespeichert. Verwenden Sie diese Option, wenn jedes übergeordnete Element mehrere verknüpfte untergeordnete Datensätze haben kann.
```
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}
]
}
```
## Struktur des Dokuments
Dokument-ID
Das OpenSearch Dokument `_id` wird auf den Wert des Primärschlüssels der übergeordneten Tabelle gesetzt. Alle untergeordneten Datensätze für dasselbe übergeordnete Element werden zu diesem einzigen Dokument zusammengeführt.
Versionsverfolgung
`version_field`(Standard:`__versions`) speichert eine Übersicht der Versionszähler pro Tabelle:
```
"__versions": {
"orders": 12345678901,
"order_items": 12345678902,
"shipping": 12345678903
}
```
Die Version jeder Tabelle wird vom Export-Zeitstempel oder Binlog-Zeitstempel abgeleitet. Wenn ein Export- oder CDC-Ereignis eintrifft, prüft das Painless-Skript, ob die eingehende Version neuer ist als die gespeicherte Version für diese spezifische Tabelle. Wenn es älter ist, wird das Ereignis übersprungen. Dadurch wird Folgendes gewährleistet:
+ Idempotente Verarbeitung — wiedergegebene Ereignisse werden getrost ignoriert.
+ Unabhängige Versionierung — Artikelaktualisierungen werden durch eine Aktualisierung der Bestellung nicht beeinträchtigt.
+ Gleichzeitige Sicherheit — mehrere untergeordnete Einfügungen für dasselbe übergeordnete Objekt werden korrekt behandelt.
\_Version des Dokuments
Das OpenSearch `_version` Feld wird mit jedem erfolgreichen Upsert inkrementiert. Für ein Dokument mit einem übergeordneten Dokument \+ N Artikeln \+ 1 Versanddatensatz gilt `_version` = N \+ 2.
## Einschränkungen
+ Single-level schließt sich nur an — Elternteil → Kind. Multi-level (Elternteil → Kind → Enkelkind) wird nicht unterstützt.
+ Eine übergeordnete Tabelle pro Pipeline. Alle untergeordneten Tabellen werden mit derselben übergeordneten Tabelle verknüpft.
+ Untergeordnete Tabellen können nicht mehreren übergeordneten Tabellen in derselben Pipeline gehören.
+ `max_child_records`begrenzt die Array-Größe für `one_to_many` Joins. Datensätze, die diesen Grenzwert überschreiten, werden gelöscht.
**Konflikte mit Feldnamen**
Bei `one_to_one` Verknüpfungen werden untergeordnete Felder auf Stammebene reduziert. Wenn eine untergeordnete Tabelle eine Spalte mit demselben Namen wie eine übergeordnete Spalte hat, überschreibt der untergeordnete Wert den übergeordneten Wert. Verwenden Sie unterschiedliche Spaltennamen für übergeordnete und `one_to_one` untergeordnete Tabellen.
Bei `one_to_many` Verknüpfungen sind untergeordnete Felder in einem Array verschachtelt, das nach der untergeordneten Tabelle benannt ist, sodass Konflikte kein Problem darstellen.
## Fehlerbehebung
Dokumente, in denen untergeordnete Datensätze fehlen
+ Checken Sie `__versions` das Dokument ein. Wenn die Version einer untergeordneten Tabelle fehlt, wurden die untergeordneten Ereignisse noch nicht verarbeitet.
+ Stellen Sie sicher, dass die Pipeline aktiv ist und die `changeEventsProcessed` Metrik ungleich Null ist.
Dokumente erscheinen nicht in OpenSearch
+ Prüfen Sie, ob der übergeordnete Datensatz in der Quelltabelle vorhanden ist.
+ Stellen Sie sicher, dass die `tables.include` Liste alle erforderlichen Tabellen enthält.
+ Überprüfen Sie die Pipeline-Protokolle auf Aufnahmefehler und Konfigurationsprobleme:. `/aws/vendedlogs/{{pipeline-log-group}}`