Best practice per utilizzare l’integrazione Zero-ETL di DynamoDB e del Servizio 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à.

Best practice per utilizzare l’integrazione Zero-ETL di DynamoDB e del Servizio OpenSearch

DynamoDB dispone di un’integrazione Zero-ETL con il Servizio OpenSearch di Amazon. Per ulteriori informazioni, consulta il plug-in DynamoDB per OpenSearch Ingestion e la pagina specific best practices for Amazon OpenSearch Service.

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 log per verificare la presenza di errori correlati ai conflitti di tipo. Il Servizio OpenSearch 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, utilizza il valore di metadati primary_key per il valore document_id. Nel Servizio OpenSearch, 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 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ò garantirà che gli aggiornamenti vengano replicati in modo tale che i dati nel Servizio OpenSearch corrispondano allo stato più recente di 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 DLQ sui sink OpenSearch per gestire gli eventi eliminati. DynamoDB è generalmente meno strutturato del Servizio OpenSearch 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 dell’unità di calcolo OpenSearch (OCU, OpenSearch Compute Unit) 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. Le OCU della pipeline devono essere impostate con un minimo di 24 (25000/1000 – 1) e un massimo di almeno 26 (25000/1000 + 1).

  • 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. Le OCU della pipeline devono essere impostate 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. Le OCU della pipeline devono essere impostate con un minimo di 1 (300/1000 – 1, ma almeno 1) e un massimo di almeno 5 (4300/1000 + 1).

  • Segui le best practice per scalare gli indici del Servizio OpenSearch di destinazione. 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.