View a markdown version of this page

Formato a tabella singola per KCL - Flusso di dati Amazon Kinesis

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à.

Formato a tabella singola per KCL

A partire da KCL 3.5, puoi consolidare tutti i metadati DynamoDB in un'unica tabella di leasing utilizzando il formato a tabella singola. Per impostazione predefinita, KCL 3.x crea tre tabelle DynamoDB per ogni applicazione: la tabella di lease, la tabella delle metriche dei lavoratori e la tabella dello stato del coordinatore. Il formato a tabella singola riduce queste tre tabelle a una sola, il che aiuta a evitare i limiti delle tabelle a livello di account DynamoDB.

Come funziona il formato a tabella singola

In formato tabella singola, KCL memorizza le metriche dei lavoratori e le voci dello stato del coordinatore nella tabella di leasing insieme alle voci del leasing. Ogni elemento include un entityType attributo che distingue tra i diversi tipi di record.

Le metriche dei lavoratori e gli elementi relativi allo stato del coordinatore utilizzano la stessa struttura di chiavi primarie della tabella di leasing ma includono un valore distinto. entityType Questo attributo consente a KCL di identificare lo scopo di ogni elemento durante le scansioni della tabella.

Ogni componente di KCL filtra le voci necessarie per la sua logica aziendale in base all'attributo. entityType Ad esempio, il Lease Assignment Manager (LAM) filtra le voci relative alle metriche relative al leasing e al lavoratore per eseguire l'assegnazione del leasing.

Configura il formato a tabella singola

Il modo in cui abiliti il formato a tabella singola dipende dalla tua attuale versione di KCL:

  • Se utilizzi KCL 2.x: segui la guida alla migrazione aggiornata per eseguire l'aggiornamento a KCL 3.5. Il formato a tabella singola viene utilizzato per impostazione predefinita per le nuove migrazioni da 2.x a 3.5.

  • Se utilizzi KCL 3.0—3.4: devi eseguire una distribuzione in due fasi per migrare al formato a tabella singola. Vedi i seguenti passaggi di configurazione e migrazione.

Per i clienti esistenti di KCL 3.x, imposta l'opzione di migrateAllEntitiesToLeaseTable configurazione in. CoordinatorConfig Questa opzione controlla se KCL memorizza tutti i tipi di entità di metadati nella tabella di leasing.

Valori di configurazione per la migrazione AllEntitiesToLeaseTable
Valore Default (Predefinito) Effetto
false

KCL utilizza tabelle separate per le metriche dei lavoratori e lo stato del coordinatore. Il codice dell'applicazione supporta il formato a tabella singola ma non lo attiva.

true No

KCL inizia a scrivere le metriche dei lavoratori e i dati sullo stato dei coordinatori nella tabella dei contratti di locazione. Imposta questo valore nella fase 2 di implementazione dopo i reach DEPLOYED e il gioco è fatto TableMigrationStatus per non subire regressioni.

La migrazione da KCL 3.x al formato a tabella singola richiede una distribuzione in due fasi:

  1. Fase 1: distribuisci il codice KCL 3.5 aggiornato con migrateAllEntitiesToLeaseTable set to (impostazione predefinita). false Questo installa il nuovo codice che supporta il formato a tabella singola ma non attiva la migrazione.

  2. Fase 2: dopo che tutti i worker hanno eseguito il nuovo codice e TableMigrationStatus i DEPLOYED reach e dopo aver verificato che non vi siano regressioni, eseguite nuovamente la distribuzione con migrateAllEntitiesToLeaseTable set true to per iniziare la migrazione.

Stati di migrazione

TableMigrationStateMachineGestisce la transizione dal formato multitabella al formato a tabella singola. KCL tiene traccia dello stato di migrazione corrente in una voce separata dello stato del coordinatore chiamata TableMigration3.5 nella tabella dello stato del coordinatore. Per l'elenco completo di stati, transizioni e descrizioni, consulta gli stati di migrazione a tabella singola di KCL.

Stati di migrazione in formato a tabella singola
Stato Description Condizione di transizione
INIT

Stato iniziale Tutti i lavoratori emettono il codice di supporto minimo nelle statistiche metriche dei lavoratori. I lavoratori continuano a inserire le metriche dei lavoratori nella tabella precedente e a leggere le metriche dei lavoratori e lo stato del coordinatore sia dalla tabella precedente che da quella di leasing. Dal punto di vista funzionale, non c'è differenza tra INIT e DEPLOYED.

Tutti i lavoratori emettono costantemente il codice di supporto minimo per il tempo di cottura. L'applicazione è pronta per passare alla fase 2 della distribuzione.

DEPLOYED

Tutti i lavoratori sono stati impiegati con il nuovo codice (Fase 1 completata). L'applicazione supporta il formato a tabella singola ma non lo ha attivato.

La fase 2 di distribuzione inizia con migrateAllEntitiesToLeaseTable impostato sutrue.

PENDING

Tutti i lavoratori eseguono il nuovo codice. KCL migra i dati dalle metriche dei lavoratori e dalle tabelle degli stati dei coordinatori alla tabella delle locazioni.

Una volta completata la migrazione, trascorre un tempo di cottura predefinito di 24 ore.

COMPLETE

La migrazione è completa. KCL utilizza la tabella di lease esclusivamente per tutte le letture e le scritture. Le vecchie metriche dei lavoratori e le tabelle degli stati dei coordinatori non vengono più utilizzate.

Stato terminale. Non si verificano ulteriori transizioni.

Per informazioni dettagliate su ogni stato, sulle condizioni di transizione e sul comportamento completo della macchina a stati, consulta KCL Single Table Migration State Machine.

Nota

Il tempo di cottura predefinito tra gli stati PENDING e COMPLETE è di 24 ore, ma puoi configurarlo fino a una settimana. Durante questo periodo, KCL utilizza la tabella di lease per tutte le letture e le scritture ma non elimina le vecchie tabelle. È necessario eliminare manualmente le vecchie metriche dei lavoratori e le tabelle degli stati dei coordinatori dopo aver confermato che la migrazione è avvenuta correttamente. KCL non elimina queste tabelle automaticamente.

Considerazioni sul rollback

Il supporto per il rollback dipende dalla versione attuale: TableMigrationStatus

  • Durante la Fase 1 (TableMigrationStatusè DEPLOYED o non è ancora impostata): puoi tornare alla versione precedente in tutta sicurezza. Il nuovo codice viene eseguito in una modalità compatibile con le versioni precedenti e nessun dato è stato scritto nelle voci non di lease nella tabella di lease.

  • Durante la Fase 2 (TableMigrationStatusè DEPLOYED oPENDING): è possibile tornare alla Fase 1. I lavoratori tornano a utilizzare le tabelle precedenti (formato multitavola) per le metriche dei lavoratori e lo stato del coordinatore. La migrazione è stata annullata.

  • Dopo lo stato COMPLETE: il rollback non è supportato. KCL utilizza solo la tabella di leasing per tutte le entità. Anche se il codice torna alla Fase 1, il lavoratore continua a utilizzare la tabella di leasing per tutte le entità e la configurazione viene ignorata.

avvertimento

Dopo che la migrazione ha raggiunto lo stato COMPLETE, l'applicazione funziona esclusivamente in modalità a tabella singola. La migrateAllEntitiesToLeaseTable configurazione viene ignorata e KCL non torna a utilizzare tabelle separate. Assicurati che il tempo di cottura prima di passare a COMPLETE sia sufficiente, perché dopo di che anche un rollback del codice non torna a più tabelle.

Best practice

Segui queste best practice quando adotti il formato a tabella singola:

  • Dopo l'implementazione della Fase 1, verifica che l'ingresso dello stato coordinatore TableMigration3.5 raggiunga DEPLOYED lo stato. Assicuratevi che non vi siano regressioni prima di procedere alla Fase 2.

  • Monitora l'ingresso nello stato TableMigration3.5 coordinatore per tenere traccia dei progressi TableMigrationStatus negli stati DEPLOYED, PENDING e COMPLETE. Lo stato viene memorizzato nella tabella degli stati del coordinatore come voce separata (non nella tabella di leasing) fino a quando la migrazione non raggiunge COMPLETE.

  • Assicurati che il tempo di cottura prima di passare a COMPLETE sia sufficiente, perché dopo di che anche un rollback del codice non ritorna a più tabelle. L'applicazione funziona solo in modalità tabella singola.

  • Una volta completata la migrazione, elimina manualmente le vecchie metriche dei lavoratori e le tabelle degli stati dei coordinatori. KCL non elimina queste tabelle automaticamente, ma smette solo di usarle.

  • Se hai configurato CoordinatorConfig.coordinatorStateTableConfig oLeaseManagementConfig.workerUtilizationAwareAssignmentConfig.workerMetricsTableConfig, puoi rimuovere queste configurazioni al termine della migrazione. Queste configurazioni sono obsolete in KCL 3.5 e versioni successive.