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](OpenSearchIngestionForDynamoDB.md) Service. OpenSearch Per ulteriori informazioni, consulta il [plug-in DynamoDB OpenSearch per Ingestion e le [best practice specifiche](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/bp.html) per](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/configure-client-ddb.html) 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** [https://docs.aws.amazon.com/redshift/latest/dg/r_GREATEST_LEAST.html](https://docs.aws.amazon.com/redshift/latest/dg/r_GREATEST_LEAST.html) è una funzione SQL che, in base a una serie di argomenti, restituisce l’argomento con il valore massimo.