Le migliori pratiche per l'integrazione con DynamoDB

Quando integri DynamoDB con altri servizi, devi sempre seguire le migliori pratiche per l'utilizzo di ogni singolo servizio. Tuttavia, ci sono alcune best practice specifiche per l'integrazione che dovresti prendere in considerazione.

Creazione di un'istantanea in DynamoDB

• In genere, consigliamo di utilizzare l'esportazione in Amazon S3 per creare istantanee per la replica iniziale. È allo stesso tempo conveniente e non è in grado di competere con il traffico dell'applicazione in termini di velocità effettiva. È inoltre possibile prendere in considerazione un backup e un ripristino su una nuova tabella seguiti da un'operazione di scansione. In questo modo si eviterà di competere con l'applicazione in termini di produttività, ma in genere si rivelerà molto meno conveniente rispetto all'esportazione.

• Imposta sempre un StartTime quando esegui un'esportazione. In questo modo è facile determinare da dove iniziare l'acquisizione dei dati di modifica (CDC).

• Quando usi l'esportazione su S3, imposta un'azione del ciclo di vita sul bucket S3. In genere, un'azione di scadenza impostata su 7 giorni è sicura, ma dovresti seguire tutte le linee guida che la tua azienda potrebbe avere. Anche se elimini esplicitamente i tuoi articoli dopo l'ingestione, questa azione può aiutare a catturare i problemi, riducendo i costi inutili e prevenendo le violazioni delle norme.

Acquisizione delle modifiche ai dati in DynamoDB

• Se hai bisogno di un CDC quasi in tempo reale, usa DynamoDB Streams o Amazon Kinesis Data Streams (KDS). Quando decidi quale usare, in genere considera qual è la più facile da usare con il servizio downstream. Se devi fornire l'elaborazione degli eventi in ordine a livello di chiave di partizione o se hai elementi di dimensioni eccezionalmente grandi, usa DynamoDB Streams.

• Se non hai bisogno di un CDC quasi in tempo reale, puoi utilizzare l'esportazione su Amazon S3 con esportazioni incrementali per esportare solo le modifiche avvenute tra due momenti nel tempo.

  Se hai utilizzato l'esportazione in S3 per generare uno snapshot, ciò può essere particolarmente utile perché puoi utilizzare un codice simile per elaborare esportazioni incrementali. In genere, l'esportazione su S3 è leggermente più economica rispetto alle precedenti opzioni di streaming, ma in genere il costo non è il fattore principale per l'opzione da utilizzare.

• In genere è possibile avere solo due utenti simultanei di un flusso DynamoDB. Consideratelo quando pianificate la vostra strategia di integrazione.

• Non utilizzare le scansioni per rilevare le modifiche. Questo potrebbe funzionare su piccola scala, ma diventa poco pratico abbastanza rapidamente.

Integrazione zero-ETL di DynamoDB con Service 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_templateandtemplate_content) e include_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 il document_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 stream dynamodb_event_name per casi d'uso come il filtraggio. Tuttavia, in genere non dovresti utilizzarlo per l'actionimpostazione.

Osservabilità

• Utilizzate sempre una coda a lettera morta (DLQ) nei 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 le OCU per adattarle al meglio al carico di lavoro.

• Per le tabelle di throughput assegnate senza scalabilità automatica, consigliamo di impostare le OCU in base alle unità di capacità di scrittura (WCU) divise per 1000. Imposta il minimo su 1 OCU al di sotto di tale importo (ma almeno 1) e imposta il massimo su almeno 1 OCU al di 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 WCU. Gli OCU della pipeline devono essere impostati 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 le OCU in base alle WCU minime e massime, divise per 1000. Impostare il minimo su 1 OCU al di sotto del minimo di DynamoDB e impostare 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 politica di ridimensionamento 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 di throughput su richiesta, consigliamo di impostare gli 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. Impostare il minimo su 1 OCU al di sotto del minimo di DynamoDB e impostare 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 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.