Bonnes pratiques d’utilisation de l’intégration zéro ETL à DynamoDB et OpenSearch Service - Amazon DynamoDB
ConfigurationObservabilitéMise à l’échelle

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Bonnes pratiques d’utilisation de l’intégration zéro ETL à DynamoDB et OpenSearch Service

DynamoDB comporte une intégration zéro ETL DynamoDB à Amazon OpenSearch Service. Pour plus d’informations, consultez les rubriques DynamoDB plugin for OpenSearch Ingestion et bonnes pratiques spécifiques relatives à Amazon OpenSearch Service.

Configuration

  • Indexez uniquement les données sur lesquelles vous devez effectuer des recherches. Utilisez toujours un modèle de mappage (template_type: index_template et template_content) et include_keys pour l’implémenter.

  • Surveillez vos journaux pour détecter les erreurs liées à des conflits de types. OpenSearch Service s’attend à ce que toutes les valeurs d’une clé donnée soient du même type. Il génère des exceptions en cas de non-concordance. Si vous rencontrez l’une de ces erreurs, vous pouvez ajouter un processeur pour détecter qu’une clé donnée a toujours la même valeur.

  • Utilisez généralement la valeur primary_key des métadonnées pour la valeur document_id. Dans OpenSearch Service, l’ID du document est l’équivalent de la clé primaire dans DynamoDB. L’utilisation de la clé primaire facilitera la recherche de votre document et garantira que les mises à jour y sont systématiquement répliquées sans conflits.

    Vous pouvez utiliser la fonction d’annotations getMetadata pour obtenir votre clé primaire (par exemple, document_id: "${getMetadata('primary_key')}"). Si vous utilisez une clé primaire composite, la fonction d’annotations les concaténera pour vous.

  • Utilisez généralement la valeur opensearch_action des métadonnées pour le paramètre action. Cela garantira que les mises à jour sont répliquées de telle sorte que les données d’OpenSearch Service correspondent à l’état le plus récent de DynamoDB.

    Vous pouvez utiliser la fonction d’annotations getMetadata pour obtenir votre clé primaire (par exemple, action: "${getMetadata('opensearch_action')}"). Vous pouvez également obtenir le type d’événement de diffusion dynamodb_event_name pour des cas d’utilisation tels que le filtrage. Cependant, vous ne devez généralement pas l’utiliser pour le paramètre action.

Observabilité

  • Utilisez toujours une file d’attente de lettres mortes (DLQ) sur vos récepteurs OpenSearch pour gérer les événements supprimés. DynamoDB est généralement moins structuré qu’OpenSearch Service, et il est toujours possible qu’un imprévu se produise. Une file d’attente de lettres mortes vous permet de récupérer des événements individuels et même d’automatiser le processus de récupération. Cela vous évitera d’avoir à reconstruire l’intégralité de votre index.

  • Définissez toujours des alertes indiquant que le délai de réplication ne dépasse pas le montant prévu. Il est généralement prudent de prévoir une minute sans que l’alerte soit trop bruyante. Cela peut varier en fonction de l’importance de votre trafic d’écriture et des paramètres de votre unité de calcul OpenSearch (OCU) sur le pipeline.

    Si le délai de réplication dépasse 24 heures, votre flux commencera à supprimer des événements et vous rencontrerez des problèmes de précision, à moins que vous ne reconstruisiez complètement votre index à partir de zéro.

Mise à l’échelle

  • Utilisez l’autoscaling pour les pipelines afin d’augmenter verticalement ou de réduire les unités OCU afin de mieux les adapter à la charge de travail.

  • Pour les tables de débit provisionnées sans autoscaling, nous vous recommandons de définir les unités OCU en fonction de vos unités de capacité d’écriture (WCU) divisées par 1 000. Définissez le minimum à 1 unité OCU en dessous de ce montant (mais au moins 1), et définissez le maximum à au moins 1 unité OCU au-dessus de ce montant.

    • Formule :

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

    • Exemple : 25 000 unités WCU sont provisionnées dans votre table. Les unités OCU de votre pipeline doivent être définies sur un minimum de 24 (25 000/1 000 - 1) et un maximum d’au moins 26 (25 000/1 000 + 1).

  • Pour les tables de débit provisionnées avec autoscaling, nous vous recommandons de définir les unités OCU en fonction de vos unités de capacité d’écriture (WCU) minimum et maximum divisées par 1 000. Définissez le minimum à 1 unité OCU en dessous du minimum de DynamoDB, et définissez le maximum à au moins 1 unité OCU au-dessus du maximum de DynamoDB.

    • Formule :

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

    • Exemple : votre table dispose d’une politique d’autoscaling avec un minimum de 8 000 et un maximum de 14 000. Les unités OCU de votre pipeline doivent être définies sur un minimum de 7 (8 000/1 000 - 1) et un maximum d’au moins 15 (14 000/1 000 + 1).

  • Pour les tables de débit à la demande, nous vous recommandons de définir les unités OCU en fonction de votre pic et de votre vallée habituels pour les unités de demande d’écriture par seconde. Il se peut que vous deviez établir une moyenne sur une période plus longue, en fonction de l’agrégation dont vous disposez. Définissez le minimum à 1 unité OCU en dessous du minimum de DynamoDB, et définissez le maximum à au moins 1 unité OCU au-dessus du maximum de DynamoDB.

    • Formule :

      # 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

    • Exemple : votre table présente une vallée moyenne de 300 unités de demande d’écriture par seconde et un pic moyen de 4 300. Les unités OCU de votre pipeline doivent être définies sur un minimum de 1 (300/1 000 - 1, mais au moins 1) et un maximum de 5 (4 300/1 000 + 1).

  • Suivez les bonnes pratiques en matière de mise à l’échelle de vos index OpenSearch Service de destination. Si vos index sont sous-dimensionnés, cela ralentira l’ingestion à partir de DynamoDB et peut entraîner des retards.

Note

GREATEST est une fonction SQL qui, à partir d’un ensemble d’arguments, renvoie l’argument ayant la plus grande valeur.