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