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 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 e template_content) e include_keys per implementare questa opzione.

  • Monitora i log per verificare la presenza di errori correlati a 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, 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’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 in OpenSearch Service 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à

  • Utilizza sempre una coda di lettere morte (DLQ) sui tuoi sink per gestire gli eventi interrotti. OpenSearch DynamoDB è generalmente OpenSearch meno strutturato di Service 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 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 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 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 massimo WCUs, diviso 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 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 l'impostazione in OCUs 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 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 funzione SQL che, in base a una serie di argomenti, restituisce l’argomento con il valore massimo.