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à.
Le migliori pratiche per lavorare con DynamoDB Zero ETL Integration and Service OpenSearch
DynamoDB ha un'integrazione zero di DynamoDB con Amazon Service. ETL OpenSearch Per ulteriori informazioni, consulta il plug-in DynamoDB OpenSearch per Ingestion e le best practice specifiche per Amazon Service. OpenSearch
Configurazione
-
Indicizza solo i dati su cui devi eseguire ricerche. Usa sempre un modello di mappatura (
template_type: index_template
andtemplate_content
) einclude_keys
implementalo. -
Monitora i log per verificare la presenza di errori correlati ai conflitti di tipo. OpenSearch Il servizio si aspetta che tutti i valori di una determinata chiave abbiano lo stesso tipo. Genera eccezioni in caso di mancata corrispondenza. Se si verifica uno di questi errori, è possibile aggiungere un processore per verificare che una determinata chiave abbia sempre lo stesso valore.
-
In genere, utilizzate il valore
primary_key
dei metadati per ildocument_id
valore. In OpenSearch Service, l'ID del documento è l'equivalente della chiave primaria in DynamoDB. L'utilizzo della chiave primaria faciliterà la ricerca del documento e garantirà che gli aggiornamenti vengano replicati in modo coerente senza conflitti.È possibile utilizzare la funzione di supporto per
getMetadata
ottenere la chiave primaria (ad esempio,document_id: "${getMetadata('primary_key')}"
). Se utilizzi una chiave primaria composita, la funzione di supporto le concatenerà insieme per te. -
In generale, utilizzate il valore dei
opensearch_action
metadati per l'impostazione.action
Ciò garantirà che gli aggiornamenti vengano replicati in modo tale che i dati in OpenSearch Service corrispondano allo stato più recente di DynamoDB.È possibile utilizzare la funzione di supporto per
getMetadata
ottenere la chiave primaria (ad esempio,).action: "${getMetadata('opensearch_action')}"
Puoi anche visualizzare il tipo di evento streamdynamodb_event_name
per casi d'uso come il filtraggio. Tuttavia, in genere non dovresti usarlo per l'action
impostazione.
Osservabilità
-
Utilizzate sempre una coda di lettere non scritte (DLQ) sui vostri OpenSearch sink per gestire gli eventi interrotti. DynamoDB è generalmente OpenSearch meno strutturato di Service ed è sempre possibile che accada qualcosa di inaspettato. Con una coda di lettere non scritte, è possibile ripristinare singoli eventi e persino automatizzare il processo di ripristino. Questo ti aiuterà a evitare di dover ricostruire l'intero indice.
-
Imposta sempre avvisi che il ritardo di replica non supera l'importo previsto. In genere è lecito attendere un minuto senza che l'avviso sia troppo rumoroso. Questo può variare a seconda dell'intensità del traffico di scrittura e delle impostazioni della OpenSearch Compute Unit (OCU) sulla pipeline.
Se il ritardo di replica supera le 24 ore, lo stream inizierà a interrompere gli eventi e avrai problemi di precisione, a meno che non esegui una ricostruzione completa dell'indice da zero.
Dimensionamento
-
Usa la scalabilità automatica per le pipeline per aumentare o ridurre la scalabilità per adattarsi OCUs al meglio al carico di lavoro.
-
Per le tabelle di throughput assegnate senza ridimensionamento automatico, consigliamo di impostare l'impostazione in OCUs base alle unità di capacità di scrittura (WCUs) divise per 1000. Imposta il minimo su 1 al di OCU sotto di tale importo (ma almeno 1) e imposta il massimo su almeno 1 al di OCU sopra di tale importo.
-
Formula:
OCU_minimum = GREATEST((table_WCU / 1000) - 1, 1) OCU_maximum = (table_WCU / 1000) + 1
-
Esempio: nella tabella sono disponibili 25000 unitàWCUs. Le tue pipeline OCUs devono essere impostate con un minimo di 24 (25000/1000 - 1) e un massimo di almeno 26 (25000/1000 + 1).
-
-
Per le tabelle di throughput assegnate con scalabilità automatica, consigliamo di impostare in OCUs base al valore minimo e massimoWCUs, diviso per 1000. Imposta il minimo su 1 al di OCU sotto del minimo di DynamoDB e imposta il massimo su almeno OCU 1 al di sopra del massimo di DynamoDB.
-
Formula:
OCU_minimum = GREATEST((table_minimum_WCU / 1000) - 1, 1) OCU_maximum = (table_maximum_WCU / 1000) + 1
-
Esempio: la tabella ha una politica di ridimensionamento automatico con un minimo di 8000 e un massimo di 14000. Le pipeline OCUs devono essere impostate con un minimo di 7 (8000/1000 - 1) e un massimo di 15 (14000/1000 + 1).
-
-
Per le tabelle di throughput su richiesta, consigliamo di impostare in OCUs base al picco e alla valle tipici delle unità di richiesta di scrittura al secondo. Potrebbe essere necessario calcolare la media su un periodo di tempo più lungo, a seconda dell'aggregazione disponibile. Imposta il minimo su 1 al di OCU sotto del minimo di DynamoDB e imposta il massimo su almeno OCU 1 al di sopra del massimo di DynamoDB.
-
Formula:
# Assuming we have writes aggregated at the minute level OCU_minimum = GREATEST((min(table_writes_1min) / (60 * 1000)) - 1, 1) OCU_maximum = (max(table_writes_1min) / (60 * 1000)) + 1
-
Esempio: la tabella ha una valle media di 300 unità di richiesta di scrittura al secondo e un picco medio di 4300. Le tue pipeline OCUs devono essere impostate con un minimo di 1 (300/1000 - 1, ma almeno 1) e un massimo di 5 (4300/1000 + 1).
-
-
Segui le best practice per scalare gli indici dei servizi di destinazione. OpenSearch Se gli indici sono sottodimensionati, l'acquisizione da DynamoDB rallenterà e potrebbe causare ritardi.
Nota
GREATEST
è una SQL funzione che, in base a una serie di argomenti, restituisce l'argomento con il valore massimo.