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à.
Comprensione dei record CDC
Importante
Questa funzionalità viene fornita come AWS anteprima ed è soggetta a modifiche. Per ulteriori informazioni, consulta la sezione 2, Beta e anteprime, nei Termini di AWS servizio
Prima della disponibilità generale, aggiungeremo nuovi tipi di operazioni ("op": "u"per gli aggiornamenti) al payload dello stream. Per garantire che l'applicazione gestisca queste modifiche senza modifiche, considera qualsiasi op valore non riconosciuto come un problema, applicando il payload. after Per informazioni dettagliate, vedi Comprensione dei record CDC.
Aurora DSQL CDC fornisce ogni modifica come record JSON. Il record utilizza una struttura a busta con tipo di operazione, immagini di riga prima e dopo e metadati di origine.
In che modo i record vengono mappati su Amazon Kinesis
Aurora DSQL scrive ogni record CDC come un singolo record Kinesis. Il Data campo del record Kinesis contiene il payload JSON. Aurora DSQL utilizza una chiave di partizione Kinesis randomizzata per distribuire i record CDC in modo uniforme tra gli shard. Per leggere tutte le modifiche, utilizza tutti gli shard del flusso di dati Kinesis. Se un record supera il limite di dimensione dei record Kinesis, Aurora DSQL lo divide tra più record Kinesis. Per informazioni dettagliate, vedi Gestione di dischi di grandi dimensioni.
Nota
Un record Kinesis ha un Data blob. I valori della chiave primaria vengono visualizzati nel campo del payload JSON per le eliminazioni o before nel campo per gli inserimenti e gli aggiornamentiafter. Per estrarre la chiave primaria per l'elaborazione a valle, leggila dal campo appropriato nel payload.
Chiave primaria nel payload
Per le tabelle con una chiave primaria, i valori della colonna della chiave primaria vengono visualizzati nel payload:
-
Per gli inserimenti e gli aggiornamenti, il payload include le colonne della chiave primaria insieme a tutte le altre colonne del campo.
after -
Per le eliminazioni, le colonne della chiave principale vengono visualizzate nel campo.
before
Ad esempio, considera una tabella con una chiave primaria composita:
CREATE TABLE order_items ( order_id INT, item_id INT, quantity INT, price NUMERIC, PRIMARY KEY (order_id, item_id) );
Un'eliminazione su questa tabella produce un payload dove"before": {"order_id": 1001, "item_id": 42}.
Registra il payload
Il payload utilizza il seguente formato di busta JSON.
Esempio INSERT
L'esempio seguente mostra un record CDC per un'operazione di inserimento:
{ "type": "full", "op": "c", "before": null, "after": {"order_id": 1001, "item_id": 42, "quantity": 5, "price": "29.99"}, "source": { "version": "1.0", "ts_ms": 1705318200000, "ts_ns": 1705318200000000000, "txId": "ffthunp5stx6ffs2vyfqoatmfu", "schema": "public", "table": "order_items", "db": "postgres", "cluster": "kmabugltfmjdaj2siqr2qbxgju" }, "ts_ms": 1705318200125, "ts_ns": 1705318200125483291 }
Esempio UPDATE
L'esempio seguente mostra come apparirà un record CDC prodotto da un'UPDATEistruzione dopo l'inizio dell'emissione di Aurora DSQL: op: "u"
Importante
Attualmente Aurora DSQL emette sia op: "c" per gli inserimenti che per gli aggiornamenti. Verrà emessa una versione successiva op: "u" per gli aggiornamenti e per gli inserimenti. op: "c" Progetta la tua app in modo che sia u gestibilec, d in modo che il consumatore continui a lavorare durante la transizione.
{ "type": "full", "op": "u", "before": null, "after": {"order_id": 1001, "item_id": 42, "quantity": 10, "price": "29.99"}, "source": { "version": "1.0", "ts_ms": 1705318300000, "ts_ns": 1705318300000000000, "txId": "qvtiesgmd55cvlfukm3dfuotji", "schema": "public", "table": "order_items", "db": "postgres", "cluster": "kmabugltfmjdaj2siqr2qbxgju" }, "ts_ms": 1705318300125, "ts_ns": 1705318300125483291 }
Esempio DELETE
Per le eliminazioni su tabelle con una chiave primaria, il before campo contiene i valori della chiave primaria della riga eliminata:
{ "type": "full", "op": "d", "before": {"order_id": 1001, "item_id": 42}, "after": null, "source": { "version": "1.0", "ts_ms": 1705318400000, "ts_ns": 1705318400000000000, "txId": "xyzabc123def456ghi789jklmno", "schema": "public", "table": "order_items", "db": "postgres", "cluster": "kmabugltfmjdaj2siqr2qbxgju" }, "ts_ms": 1705318400125, "ts_ns": 1705318400125483291 }
Campi del payload
| Campo | Description |
|---|---|
type |
Il tipo di record. fullper un record completo che include dati in linea before e after valori. chunkedper un record principale che fa riferimento a record di frammenti per una o entrambe le immagini. fragmentper una singola parte di un'immagine suddivisa in blocchi. Per informazioni dettagliate, vedi Gestione di dischi di grandi dimensioni. |
op |
Tipo di operazione. c= crea (inserisci), u = aggiorna, d = elimina. Attualmente Aurora DSQL emette sia c per gli inserimenti che per gli aggiornamenti. Verrà emessa una versione successiva u per gli aggiornamenti e per gli inserimenti. c Progetta la tua app per gestire tutti e tre i valori. |
before |
Per le eliminazioni su tabelle con una chiave primaria, contiene i valori della chiave primaria della riga eliminata. Aurora DSQL imposta questo campo null per inserimenti, aggiornamenti ed eliminazioni su tabelle senza chiave primaria. |
after |
Lo stato completo della riga dopo la modifica, incluse tutte le colonne. Aurora DSQL imposta questo campo su per null le eliminazioni. |
chunked |
Presente solo quando lo è. type chunked Contiene i metadati di riassemblaggio per l'beforeimmagine, l'afterimmagine o entrambi. Aurora DSQL omette l'immagine suddivisa in blocchi dal primo livello before o after dal campo e la colloca invece sotto. chunked Per informazioni dettagliate, vedi Gestione di dischi di grandi dimensioni. |
source.version |
La versione del formato dei metadati di origine CDC. La versione corrente è 1.0. |
source.ts_ms |
Il timestamp di conferma della transazione in millisecondi dall'epoca Unix, Coordinated Universal Time (UTC). |
source.ts_ns |
Timestamp di conferma della transazione in nanosecondi, UTC. Il timestamp con la massima precisione disponibile. Utilizza questo campo per stabilire l'ordine totale delle transazioni. |
source.txId |
Un identificatore di transazione univoco, codificato come base32. Tutti i record della stessa transazione condividono lo stesso valore. txId Utilizzare questo campo per raggruppare i record che appartengono alla stessa transazione. |
source.schema |
Il nome dello schema PostgreSQL (ad esempio,). public |
source.table |
Il nome della tabella. |
source.db |
Nome del database. Sempre postgres per Aurora DSQL. |
source.cluster |
L'identificatore del cluster Aurora DSQL. |
ts_ms |
L'ora in cui il sistema CDC ha elaborato il record, in millisecondi, UTC. La differenza tra ts_ms e source.ts_ms è una misura del ritardo di replica. |
ts_ns |
L'ora in cui il sistema CDC ha elaborato il record, in nanosecondi, UTC. |
Dettagli sul formato
I seguenti dettagli descrivono come Aurora DSQL CDC formatta i record. Progetta la tua app per gestire questi comportamenti.
-
Immagine finale completa per inserti e aggiornamenti. Aurora DSQL include lo stato completo della riga nel
aftercampo per tutte le scritture. Ilbeforecampo servenullper inserimenti e aggiornamenti. Attualmente vengono utilizzati sia gli inserti che gli aggiornamentiop: "c", ma verrà emessaop: "u"una versione successiva per gli aggiornamenti. Progetta la tua app in modo che utilizzisource.ts_nsogni chiave primaria per l'ordinazione anziché affidarti alopcampo per distinguere tra inserti e aggiornamenti. -
Post-change solo lo stato delle righe. I record CDC includono lo stato completo della riga dopo ogni modifica. Lo stato della riga prima di un aggiornamento non è incluso. Per le eliminazioni su tabelle con una chiave primaria, il
beforecampo contiene i valori della chiave primaria. -
Tipi numerici serializzati come stringhe. Aurora DSQL serializza
numericedecimalvaluta come stringhe JSON per preservare la precisione esatta. -
Dati binari codificati come Base64. Aurora DSQL codifica i
byteavalori come stringhe Base64. -
Valori numerici e a virgola mobile speciali. Aurora DSQL serializza NaN e ±Infinity come stringhe e.
"NaN""Infinity""-Infinity"Questo vale per e tipi.realdouble precisionnumeric -
Colonne JSON serializzate come stringhe JSON. Aurora DSQL serializza i valori delle
jsoncolonne come stringhe JSON che contengono il testo JSON non elaborato memorizzato nella colonna. Analizza il valore della stringa nella tua app (ad esempio, conJSON.parsein JavaScript ojson.loadsin Python) per accedere al valore JSON sottostante. -
Valori di overflow emessi come null. Se un valore non può essere rappresentato nel tipo JSON di destinazione durante la serializzazione, Aurora DSQL emette JSON per quella colonna.
nullCiò si applica aiintervalvalori i cui microsecondi totali superano l'intervallo di numeri interi con segno a 64 bit (±9.223.372.036.854.775.807 microsecondi, circa ±292.271 anni). Progettanullla tua app per gestire valori imprevisti in colonne che non possono essere annullate nello schema del database. -
I record sovradimensionati si dividono in blocchi. Se un record supera il limite di dimensione del record di Amazon Kinesis, Aurora DSQL divide l'immagine
aftero l'immaginebeforeinteressata in frammenti e li consegna come record Kinesis separati in modo da ricevere comunque la modifica. Progetta la tua app per riassemblare le immagini. Per informazioni dettagliate, vedi Gestione di dischi di grandi dimensioni.
Gestione di dischi di grandi dimensioni
Quando il codice JSON serializzato di un record CDC supera i 9 MiB, Aurora DSQL before and/or after divide le immagini, fornendo più record Kinesis. Ogni record contiene un type campo di primo livello che ne indica la struttura: full per un record completo, per un record principale che fa riferimento ai frammenti e chunked per una singola parte di un'immagine suddivisa in blocchi. fragment I ts_ns campiop, sourcets_ms, e di un record principale suddiviso in blocchi si comportano come in un record completo. I record che rientrano in un singolo record Kinesis sono type impostati full e non richiedono alcuna gestione aggiuntiva.
A chunk_id è stabile tra i tentativi. Se Aurora DSQL riconsegna nuovamente un frammento, ha lo stesso chunk_id contenuto della distribuzione originale, in modo che l'app possa continuare a memorizzare nel buffer con lo stesso identificatore senza gestire set parziali dei tentativi precedenti.
Record principale
Un record principale suddiviso in blocchi sostituisce il livello before o il after campo superiore dell'immagine divisa con un chunked oggetto che descrive come riassemblarla. Ogni voce sottostante chunked ha un chunk_id (l'identificatore che collega i frammenti a questo record), total_fragments (il numero di frammenti che compongono quell'immagine) e crc32c (un checksum CRC32C, come stringa decimale, sul testo dell'immagine riassemblato). Se un'immagine è in linea e l'altra è suddivisa in blocchi, l'immagine in linea viene comunque visualizzata al livello superiore come valore o. null
{ "type": "chunked", "op": "c", "before": null, "after": null, "source": { "version": "1.0", "ts_ms": 1705318200000, "ts_ns": 1705318200000000000, "txId": "ffthunp5stx6ffs2vyfqoatmfu", "schema": "public", "table": "order_items", "db": "postgres", "cluster": "cluster-id" }, "chunked": { "after": { "chunk_id": "chunk-id", "total_fragments": 3, "crc32c": "2073618257" } }, "ts_ms": 1705318200125, "ts_ns": 1705318200125483291 }
Record di frammenti
Ogni frammento è il proprio record Kinesis type con set fragment to e tre campichunk_id: corrisponde al valore nel record chunked.before.chunk_id corrispondente chunked.after.chunk_id o nel record principaleindex, è la posizione in base zero del frammento all'interno dell'immagine data ed è un segmento del testo JSON dell'immagine suddiviso UTF-8 sui limiti dei caratteri (il valore di ogni frammento data è una stringa valida a sé stante). UTF-8 Poiché Aurora DSQL CDC utilizza la UNORDERED modalità e le chiavi di partizione randomizzate, i frammenti e il record principale possono arrivare su diversi shard e in qualsiasi ordine. Per leggere tutti i frammenti, utilizza tutti gli shard del flusso di dati Kinesis. Per ulteriori informazioni sugli ordini con consegna, consulta. Ordinazione
{ "type": "fragment", "chunk_id": "chunk-id", "index": 0, "data": "partial-JSON-text" }
Per riassemblare un'immagine sovradimensionata, inserite nel buffer ogni record con il relativo. type fragment chunk_id Quando ricevete un record principale con typechunked, attendete di avere total_fragments frammenti per ogni chunk_id riferimento sotto chunked.before ochunked.after, ordinate i frammenti in ordine crescente e concatenate le stringhe. index data Il risultato concatenato è l'originale before o after l'oggetto come testo JSON: analizzatelo per accedere ai valori delle colonne. Per verificare l'integrità della consegna, calcola CRC32C sulla stringa concatenata e confronta il risultato con o. chunked.before.crc32c chunked.after.crc32c
Serializzazione del tipo di dati
Le tabelle seguenti descrivono come Aurora DSQL serializza ogni tipo di dati PostgreSQL nei record CDC.
Tipi Integer
| Tipo PostgreSQL | Rappresentazione JSON | Esempio |
|---|---|---|
smallint (int2) |
Numero JSON | 42 |
integer (int4) |
Numero JSON | 1001 |
bigint (int8) |
Numero JSON | 9223372036854775807 |
oid |
Numero JSON (senza segno) | 16384 |
I valori bigint superiori a ±2^53 potrebbero perdere la precisione negli ambienti. JavaScript In questi casi, utilizzate BigInt librerie a precisione arbitraria.
Floating-point tipi
| Tipo PostgreSQL | Rappresentazione JSON | Esempio | Note |
|---|---|---|---|
real (float4) |
Numero JSON | 3.14159 |
NaN e ±Infinity sono serializzati come stringhe"NaN",,. "Infinity" "-Infinity" |
double precision (float8) |
Numero JSON | 3.141592653589793 |
Stessa gestione dei valori speciali direal. |
numeric / decimal |
Stringa JSON | "123.45" |
Sempre una stringa per preservare la precisione esatta. NaN e ±Infinity sono serializzati come stringhe"NaN",,. "Infinity" "-Infinity" |
Booleano
| Tipo PostgreSQL | Rappresentazione JSON | Esempio |
|---|---|---|
boolean |
JSON booleano | true o false |
Tipi di carattere
| Tipo PostgreSQL | Rappresentazione JSON | Esempio |
|---|---|---|
varchar / text |
stringa JSON | "Hello, world!" |
bpchar (char(n)) |
stringa JSON | "ABC"(spazi finali eliminati) |
name |
stringa JSON | "pg_class" |
"char"(byte singolo) |
stringa JSON | "A" |
Binario
| Tipo PostgreSQL | Rappresentazione JSON | Esempio |
|---|---|---|
bytea |
stringa JSON (Base64) | "SGVsbG8gV29ybGQh" |
Tipi di data e ora
| Tipo PostgreSQL | Rappresentazione JSON | Esempio | Note |
|---|---|---|---|
date |
Numero JSON (giorni dall'epoca di Unix) | 19797 |
+infinitye -infinity sono rappresentati come conteggi dei giorni sentinella derivati dall'aritmetica epoch-offset. Questi valori non corrispondono a date di calendario significative. |
time |
Numero JSON (microsecondi dalla mezzanotte) | 52200123456 |
|
timetz |
Numero JSON (microsecondi dalla mezzanotte, UTC) | 52200123456 |
L'ora locale viene adattata all'UTC applicando lo scostamento del fuso orario memorizzato (secondi a ovest dell'UTC). Il risultato viene riassunto nell'intervallo [0, 86400000000) microsecondi. |
timestamp |
Numero JSON (microsecondi dall'epoca Unix) | 1710510600123456 |
±Infinity esegue la mappatura ai valori sentinella: for e for. 9223372036825200000 +infinity -9223372036832400000 -infinity |
timestamptz |
Numero JSON (microsecondi dall'epoca Unix) | 1710510600123456 |
Memorizzato ed emesso in UTC. Stessi valori di sentinella ±infinity di. timestamp |
interval |
Numero JSON (microsecondi totali approssimativi) | 2802603000000 |
I mesi sono approssimativamente pari a 30,4375 giorni (2.629.800 secondi). Il totale (months × 2,629,800 + days × 86,400) ×
1,000,000 + microseconds viene calcolato come. Se il risultato supera l'intervallo di numeri interi con segno a 64 bit (±9.223.372.036.854.775.807 microsecondi, circa ±292.271 anni), Aurora DSQL emette JSON per la colonna. null |
Altri tipi
| Tipo PostgreSQL | Rappresentazione JSON | Esempio |
|---|---|---|
uuid |
Stringa JSON (formato esadecimale standard 8-4-4-4-12) | "550e8400-e29b-41d4-a716-446655440000" |
oidvector |
Matrice vuota JSON | [] |
json |
Stringa JSON contenente il testo JSON non elaborato | "{\"key\": \"value\"}" |
Valori NULL
Per qualsiasi tipo di dati, i valori NULL delle colonne sono rappresentati come null JSON.
Evoluzione dello schema nei record CDC
Quando si modifica lo schema di una tabella, ad esempio aggiungendo, eliminando o rinominando una colonna, i record CDC riflettono la modifica a partire dalla transazione che ha eseguito la modifica DDL. I record delle transazioni eseguite prima della modifica DDL utilizzano lo schema precedente. Esempio:
-
Se aggiungi una colonna, i record delle transazioni precedenti non includono la nuova colonna. I record dalla transazione di aggiunta in poi includono la nuova colonna.
-
Se si elimina una colonna, i record dalla transazione di eliminazione in poi non includono più quella colonna.
-
Se si rinomina una colonna, i record dalla transazione di ridenominazione in poi utilizzano il nuovo nome di colonna.
Tieni traccia delle modifiche allo schema nel tuo consumatore a valle esaminando i nomi delle colonne presenti in ogni record e campo. after before Il source.version campo in ogni record identifica il formato della busta CDC.