Bonnes pratiques d'intégration à DynamoDB

Lorsque vous intégrez DynamoDB à d'autres services, vous devez toujours suivre les meilleures pratiques relatives à l'utilisation de chaque service individuel. Cependant, certaines bonnes pratiques spécifiques à l'intégration doivent être prises en compte.

Création d'un instantané dans DynamoDB

• En général, nous recommandons d'utiliser l'exportation vers Amazon S3 pour créer des instantanés destinés à la réplication initiale. Il est à la fois rentable et ne concurrencera pas le trafic de votre application en termes de débit. Vous pouvez également envisager une sauvegarde et une restauration sur une nouvelle table suivies d'une opération de numérisation. Cela vous évitera de concurrencer votre application en termes de débit, mais sera généralement nettement moins rentable qu'une exportation.

• Définissez toujours un StartTime lorsque vous effectuez une exportation. Cela permet de déterminer facilement par où vous allez commencer votre capture des données de modification (CDC).

• Lorsque vous utilisez l'exportation vers S3, définissez une action de cycle de vie sur le compartiment S3. En règle générale, une action d'expiration fixée à 7 jours est sûre, mais vous devez suivre toutes les directives de votre entreprise. Même si vous supprimez explicitement vos articles après ingestion, cette action peut aider à détecter les problèmes, ce qui permet de réduire les coûts inutiles et d'éviter les violations des politiques.

Capture des modifications de données dans DynamoDB

• Si vous avez besoin d'un CDC en temps quasi réel, utilisez DynamoDB Streams ou Amazon Kinesis Data Streams (KDS). Lorsque vous décidez lequel utiliser, considérez généralement celui qui est le plus facile à utiliser avec le service en aval. Si vous devez fournir un traitement des événements dans l'ordre au niveau de la clé de partition, ou si vous avez des éléments exceptionnellement volumineux, utilisez DynamoDB Streams.

• Si vous n'avez pas besoin d'un CDC en temps quasi réel, vous pouvez utiliser l'exportation vers Amazon S3 avec des exportations incrémentielles pour exporter uniquement les modifications survenues entre deux points dans le temps.

  Si vous avez utilisé l'exportation vers S3 pour générer un instantané, cela peut être particulièrement utile car vous pouvez utiliser un code similaire pour traiter les exportations incrémentielles. En général, l'exportation vers S3 est légèrement moins chère que les options de streaming précédentes, mais le coût n'est généralement pas le principal facteur déterminant pour choisir l'option à utiliser.

• Vous ne pouvez généralement avoir que deux consommateurs simultanés d'un flux DynamoDB. Tenez-en compte lors de la planification de votre stratégie d'intégration.

• N'utilisez pas de scans pour détecter les modifications. Cela peut fonctionner à petite échelle, mais devient peu pratique assez rapidement.

Intégration DynamoDB Zero-ETL au service OpenSearch

DynamoDB intègre DynamoDB Zero-ETL à Amazon Service. OpenSearch Pour plus d'informations, consultez le plug-in DynamoDB OpenSearch pour l'ingestion et les meilleures pratiques spécifiques pour Amazon Service. OpenSearch

Configuration

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

• Surveillez vos journaux pour détecter les erreurs liées à des conflits de types. OpenSearch Le 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 de primary_key métadonnées pour la document_id valeur. 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'assistance getMetadata pour obtenir votre clé primaire (par exemple,document_id: "${getMetadata('primary_key')}"). Si vous utilisez une clé primaire composite, la fonction d'assistance les concaténera pour vous.

• En général, utilisez la valeur de opensearch_action métadonnées pour le action paramètre. Cela garantit que les mises à jour sont répliquées de telle sorte que les données du OpenSearch Service correspondent à l'état le plus récent dans DynamoDB.

  Vous pouvez utiliser la fonction d'assistance 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 action réglage.

Observabilité

• Utilisez toujours une file d'attente de lettres mortes (DLQ) sur vos récepteurs pour gérer OpenSearch les événements abandonnés. DynamoDB est généralement OpenSearch moins structuré que Service, et il est toujours possible qu'un imprévu se produise. Avec une file d'attente de lettres mortes, vous pouvez récupérer des événements individuels et même automatiser le processus de restauration. 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 OpenSearch calcul (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, sauf si vous reconstruisez complètement votre index à partir de zéro.

Mise à l'échelle

• Utilisez le dimensionnement automatique pour les pipelines afin d'augmenter ou de réduire les OCU afin de mieux les adapter à la charge de travail.

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

  • Formule :

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

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

• Pour les tables de débit provisionnées avec mise à l'échelle automatique, nous vous recommandons de définir les OCU en fonction de vos WCU minimum et maximum, divisés par 1 000. Définissez le minimum à 1 OCU en dessous du minimum de DynamoDB, et définissez le maximum à au moins 1 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 de dimensionnement automatique avec un minimum de 8 000 et un maximum de 14 000. Les OCU de votre pipeline doivent être définis sur un minimum de 7 (8000/1000 - 1) et un maximum de 15 (14000/1000 + 1).

• Pour les tables de débit à la demande, nous vous recommandons de définir les 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 OCU en dessous du minimum de DynamoDB, et définissez le maximum à au moins 1 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 OCU de votre pipeline doivent être définis sur un minimum de 1 (300/1000 - 1, mais au moins 1) et un maximum de 5 (4300/1000 + 1).

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

Note

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