View a markdown version of this page

Le migliori pratiche per lavorare con l'integrazione e il servizio DynamoDB Zero-ETL OpenSearch - Amazon DynamoDB
ConfigurazioneOsservabilitàDimensionamento

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 l'integrazione e il servizio DynamoDB Zero-ETL OpenSearch

DynamoDB ha un'integrazione DynamoDB Zero-ETL con Amazon Service. OpenSearch Per ulteriori informazioni, consulta il plug-in DynamoDB for Ingestion e le best practice specifiche per Amazon Service OpenSearch . OpenSearch

Configurazione

  • Indicizza solo i dati su cui devi eseguire ricerche. Usa sempre un modello di mappatura (template_type: index_template e template_content) e include_keys per implementare questa opzione.

  • Monitora i tuoi log per individuare eventuali errori legati a conflitti di tipo. OpenSearch Il servizio prevede 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, utilizza il valore di metadati primary_key per il valore document_id. In OpenSearch Service, l'ID del documento è l'equivalente della chiave primaria in DynamoDB. L'uso della chiave primaria semplificherà la ricerca del documento e assicurerà che gli aggiornamenti vengano replicati in modo coerente senza conflitti.

    È possibile utilizzare la funzione helper getMetadata per ottenere la chiave primaria (ad esempio, document_id: "${getMetadata('primary_key')}"). Se si utilizza una chiave primaria composita, la funzione helper si occuperà di concatenare le chiavi insieme.

  • In generale, utilizza il valore di metadati opensearch_action per l’impostazione action. Ciò assicurerà che gli aggiornamenti vengano replicati in modo tale che i dati nel OpenSearch Servizio corrispondano allo stato più recente in DynamoDB.

    È possibile utilizzare la funzione helper getMetadata per ottenere la chiave primaria (ad esempio, action: "${getMetadata('opensearch_action')}"). È possibile anche visualizzare il tipo di evento di flusso attraverso dynamodb_event_name per casi d’uso come il filtraggio. Tuttavia, in genere non sarebbe da utilizzare per l’impostazione action.

Osservabilità

  • Usa sempre una coda di lettere morte (DLQ) sui tuoi sink per gestire gli eventi interrotti. OpenSearch DynamoDB è generalmente meno strutturato del OpenSearch servizio ed è sempre possibile che accada qualcosa di inaspettato. Con una coda DLQ è possibile ripristinare singoli eventi e persino automatizzare il processo di recupero. Questo aiuterà a evitare di dover ricostruire l’intero indice.

  • Imposta sempre avvisi perché il ritardo di replica non superi la quantità prevista. Di norma, un minuto è un valore sicuro che evita notifiche eccessive. 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, il flusso inizierà a ridurre gli eventi e si riscontreranno problemi di precisione, a meno di non eseguire una ricostruzione completa dell’indice da zero.

Dimensionamento

  • Usa il dimensionamento automatico per le pipeline per aumentare o ridurre verticalmente le OCU per adattarle al meglio al carico di lavoro.

  • Per le tabelle con throughput allocato senza dimensionamento automatico, si consiglia di impostare le OCU in base alle unità di capacità di scrittura (WCU, Write Capacity Units) divise per 1000. Imposta il minimo su 1 OCU al di sotto di tale quantità (ma almeno su 1) e imposta il massimo su almeno 1 OCU al di sopra di tale quantità.

    • Formula:

      OCU_minimum = GREATEST((table_WCU / 1000) - 1, 1)
OCU_maximum = (table_WCU / 1000) + 1

    • Esempio: nella tabella sono state allocate 25000 WCU. Gli OCU della pipeline devono essere impostati con un minimo di 24 (25000/1000 - 1) e un massimo di almeno 26 (+ 1). 25000/1000

  • Per le tabelle con throughput allocato con dimensionamento automatico, si consiglia di impostare le OCU in base alle WCU minime e massime, divise per 1000. Imposta il minimo su 1 OCU al di sotto del minimo di DynamoDB e imposta il massimo su almeno 1 OCU 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 policy di dimensionamento automatico con un minimo di 8000 e un massimo di 14000. Gli OCU della pipeline devono essere impostati con un minimo di 7 (8000/1000 - 1) e un massimo di 15 (14000/1000 + 1).

  • Per le tabelle con throughput on demand, si consiglia di impostare le OCU in base al picco e alla valle tipici per le 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 OCU al di sotto del minimo di DynamoDB e imposta il massimo su almeno 1 OCU 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. Gli OCU della pipeline devono essere impostati con un minimo di 1 (300/1000 -1, ma almeno 1) e un massimo di 5 (4300/1000 + 1).

  • Segui le migliori pratiche 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 funzione SQL che, in base a una serie di argomenti, restituisce l’argomento con il valore massimo.