FAQ sur Amazon DynamoDB

DynamoDB est un service de base de données NoSQL distribué, entièrement géré et sans serveur, avec des performances de latence de quelques millisecondes, quelle que soit l’échelle. DynamoDB n’offre aucune gestion d’infrastructure, aucune maintenance sans interruption de service, une évolutivité instantanée pour répondre à toutes les demandes des applications et une facturation à la demande. Il n'y a aucun démarrage à froid, aucune mise à niveau de version et aucune fenêtre de maintenance. DynamoDB est entièrement géré, ce qui élimine les tâches de gestion de base de données indifférenciées, telles que les sauvegardes, la sécurité, la conformité, la surveillance, etc. Pour les applications distribuées dans le monde entier, DynamoDB global tables est une base de données multirégionale et multiactive avec une disponibilité allant jusqu'à 99,999 % et offrant la plus grande résilience de base de données. Il prend en charge une forte cohérence multirégionale, garantissant que vos applications restent toujours disponibles et lisent toujours les mêmes données, quelle que soit la région, ce qui vous permet de créer des applications sans RPO. DynamoDB dispose d’un large éventail de contrôles de sécurité et de normes de conformité conçus pour répondre aux exigences des gouvernements, des banques internationales et d’autres organisations hautement sensibles.

Grâce à DynamoDB, les clients transfèrent sur AWS leurs tâches d’administration relatives à l’exploitation et à la mise à l’échelle de leurs bases de données distribuées, évitant ainsi toutes les contraintes relatives à l’approvisionnement en matériel, à l’installation et à la configuration, à la planification de la capacité de débit, à la réplication, à l’application de correctifs logiciels ou à la mise à l’échelle des clusters. Une base de données distribuée, non SQL peut désormais être déployée en quelques minutes. DynamoDB met automatiquement la capacité de débit à l’échelle pour répondre aux exigences de la charge de travail ; il partitionne et repartitionne vos données au fur et à mesure que la taille de votre table augmente. De plus, DynamoDB réplique les données de manière synchronisée sur trois zones de disponibilité (AZ) au sein d’une Région AWS, vous permettant ainsi de bénéficier d’une haute disponibilité et d’optimiser la durabilité des données.

Parmi les avantages uniques de DynamoDB, citons qu’il s’agit d’une base de données sans serveur approuvée, entièrement gérée et à mise à l’échelle jusqu’à zéro, qui fournit des performances inférieures à dix millisecondes et une disponibilité allant jusqu’à 99,999 %. Grâce à ses performances constantes à l’échelle, Amazon DynamoDB offre également la sécurité, la durabilité et la fiabilité intégrées requises pour les applications mondiales répondant aux exigences les plus strictes. Grâce à sa facilité d’utilisation DynamoDB est souvent choisi à la fois pour les nouvelles applications d’IA générative et basées sur les données, ainsi que pour les applications établies à l’échelle de l’Internet nécessitant des performances rapides et constantes avec une capacité de mise à l’échelle illimitée.

Les classes de tables DynamoDB sont des options d’optimisation des performances et des coûts pour les tables DynamoDB. Les deux classes de tables disponibles sont DynamoDB Standard (classe de table par défaut conçue pour les charges de travail nécessitant des performances maximales et convenant le mieux aux tables dont les charges de travail sont imprévisibles), et DynamoDB Standard-Infrequent Access (classe de table optimisée pour les tables dont le stockage est le facteur de coût dominant et idéale pour les tables qui stockent des données auxquelles on accède peu souvent). Les tables Standard ont des coûts de lecture et d’écriture inférieurs, mais des coûts de stockage plus élevés. Les tables Standard-IA ont des coûts de stockage inférieurs, mais des coûts de lecture et d’écriture plus élevés. Vous pouvez passer d’une classe de table à l’autre deux fois par période de 30 jours sans durée d’indisponibilité, ce qui vous permet d’optimiser vos coûts en fonction des habitudes d’utilisation de votre table. Le choix entre ces classes dépend des besoins spécifiques de votre application et des modèles d’accès à vos données.

Plusieurs facteurs doivent être pris en compte lors du choix d’une classe de table dans DynamoDB. Les facteurs les plus courants à prendre en compte sont les modèles d’accès à vos données, les considérations financières et la prévisibilité de la charge de travail. Vous pouvez passer d’une classe de table à l’autre sans aucun codage ni durée d’indisponibilité, afin de pouvoir ajuster votre choix si vos besoins évoluent au fil du temps.

Les tables DynamoDB Standard-IA (accès peu fréquent) fonctionnent parfaitement avec les fonctionnalités DynamoDB existantes. Elles utilisent les mêmes API que les tables DynamoDB classiques. Vous pouvez donc les utiliser avec des applications existantes sans modifier le code. Elles prennent en charge les tables globales pour la réplication multirégionale, la reprise ponctuelle (PITR), les sauvegardes à la demande, le chiffrement au repos à l’aide d’AWS Key Management Service (KMS), DynamoDB Streams, la durée de vie (TTL, Time To Live) avant suppression automatique des éléments et les opérations de lecture et d’écriture transactionnelles. Les tables Standard-IA sont compatibles avec DynamoDB Accelerator (DAX).

Amazon DynamoDB stocke les données dans des partitions. Une partition est une allocation de stockage pour une table, sauvegardée par des disques SSD et répliquée automatiquement dans plusieurs zones de disponibilité au sein d’une Région AWS. La gestion des partitions est entièrement gérée par DynamoDB. Vous n’avez jamais à gérer vous-même les partitions.

La taille maximale d’un élément pouvant être stocké dans une table DynamoDB est de 400 Ko. Il n’existe aucune limite de stockage prédéfinie.

Oui, DynamoDB peut stocker des objets BLOB ; toutefois, il n’est généralement pas adapté au stockage de documents ou d’images. Une meilleure architecture consiste à stocker des pointeurs vers des objets Amazon S3 dans une table DynamoDB.

Par défaut, aucune date d’expiration ou de suppression n’est définie pour les données stockées dans une table Amazon DynamoDB. Les données resteront dans la table indéfiniment, sauf si elles sont explicitement supprimées par le client ou par la fonctionnalité de durée de vie (TTL), si elle est activée.

Il n’existe aucune limite prédéfinie quant au nombre d’éléments pouvant être stockés dans une table DynamoDB. DynamoDB se met à l’échelle de centaines de téraoctets ou plus de données, quel que soit le nombre d’éléments.

Bien qu’il soit techniquement possible de stocker des images dans DynamoDB sous forme de données binaires (codées en base64), la taille limite des éléments de 400 Ko présente certaines limites et certains inconvénients. Au lieu de stocker les images directement dans DynamoDB, il est préférable de stocker les images dans Amazon S3 (Simple Storage Service), puis de stocker l’URL ou la clé de l’objet S3 dans DynamoDB.

Pour stocker une liste dans DynamoDB, vous devez utiliser l’un des types de données de liste de DynamoDB, à savoir List ou Set. Lorsque vous écrivez des éléments dans le tableau, la valeur de cet attribut peut être un tableau ou une collection de types de données scalaires (non liés à des objets) tels que des chaînes, des nombres, etc. DynamoDB se chargera automatiquement de sérialiser les données de la liste et de les stocker de manière à conserver la structure de la liste. Vous pouvez ensuite interroger l’attribut de table pour récupérer la liste complète. L’ajout, la mise à jour ou la suppression d’éléments de la liste fonctionnent de la même manière qu’une opération d’écriture normale.

Oui, DynamoDB prend en charge le stockage de cartes en tant que type de données d’attribut. 

Oui, DynamoDB prend en charge les autorisations IAM. Les autorisations IAM peuvent être définies dans des politiques basées sur l’identité, des politiques basées sur les ressources ou d’autres politiques AWS pour contrôler l’accès aux ressources DynamoDB. Vous pouvez associer des politiques IAM aux utilisateurs, groupes et rôles IAM, aux tables et aux flux DynamoDB, et les contrôler comme vous le souhaitez.

Avec AWS PrivateLink, vous pouvez simplifier la connectivité de réseau privé entre les clouds privés virtuels (VPC), DynamoDB et vos centres de données sur site à l’aide de points de terminaison de VPC d’interface et d’adresses IP privées. Avec PrivateLink, les tables DynamoDB sont accessibles depuis une connexion privée et les requêtes ne quittent pas le réseau Amazon. La sécurité s’en trouve renforcée, car le trafic passe par les passerelles réseau et l’accès peut être contrôlé à l’aide de politiques IAM et de groupes de sécurité. PrivateLink est utile pour les applications qui ont des exigences en matière de sécurité des données et nécessitent une faible latence. Il rend également les tables DynamoDB accessibles à partir d’environnements hybrides comprenant des réseaux sur site et AWS.

Oui, DynamoDB prend en charge les politiques basées sur les ressources pour les tables et les flux. Les politiques basées sur les ressources pour chaque table couvrent également les autorisations d’accès aux index de la table (index secondaires globaux et index secondaires locaux). Grâce à des politiques basées sur les ressources, les clients peuvent définir des autorisations d’accès précises pour les tables DynamoDB et d’autres ressources sans avoir à accorder un accès complet au niveau du compte AWS. Ces politiques permettent aux clients de contrôler quels utilisateurs, rôles et utilisateurs fédérés peuvent effectuer des actions telles que la lecture, l’écriture ou la suppression sur des tables, des index et des flux DynamoDB spécifiques. Les politiques basées sur les ressources sont associées et gérées au sein de chaque ressource DynamoDB.

Les politiques basées sur les ressources prennent en charge les intégrations avec l’analyseur d’accès AWS Identity and Access Management (IAM) et le blocage de l’accès public (BPA). L’analyseur d’accès IAM aide les clients à affiner les autorisations et à se conformer au principe du moindre privilège. Le BPA aide les clients à empêcher l’accès public aux tables, aux index et aux flux DynamoDB. Il est toujours activé dans DynamoDB.
 

DynamoDB prend en charge le contrôle d’accès basé sur les attributs, qui est généralement disponible pour les tables et les index DynamoDB.

Oui, vous pouvez utiliser Amazon DynamoDB à l’aide de points de terminaison d’un VPC. DynamoDB prend en charge deux types de points de terminaison de VPC : les points de terminaison de passerelle et l’utilisation d’AWS PrivateLink. Avec un point de terminaison de passerelle, vous pouvez accéder à DynamoDB depuis votre VPC, sans avoir besoin d’une passerelle Internet ou d’un périphérique NAT pour votre VPC. Cependant, les points de terminaison de passerelle n’autorisent pas l’accès depuis des réseaux sur site, depuis des VPC homologues dans d’autres Régions AWS ou via une passerelle de transit. Pour ces scénarios, vous devez utiliser AWS PrivateLink, disponible moyennant des frais supplémentaires.

Le contrôle précis des accès (FGAC, Fine-grained access control) donne au propriétaire d’une table DynamoDB un contrôle granulaire sur les données de la table grâce aux politiques et conditions d’AWS Identity and Access Management (IAM). Le FGAC permet au propriétaire de fournir des autorisations d’accès aux éléments ou aux attributs de la table et aux actions associées. Un contrôle d’accès précis est utilisé de concert avec AWS IAM, qui gère les informations d’identification de sécurité et les autorisations associées.

Oui, toutes les données utilisateur d’Amazon DynamoDB sont entièrement chiffrées en transit et au repos.

Le protocole HTTPS est utilisé pour protéger le trafic réseau à l’aide du chiffrement Secure Sockets Layer.

Le chiffrement DynamoDB au repos utilise des clés de chiffrement stockées dans AWS Key Management Service (AWS KMS). Les données au repos sont cryptées à l’aide de l’AES-256, la norme de référence qui exige les plus hauts niveaux de sécurité.

Les types de clés suivants sont disponibles pour chiffrer les données au repos :
1. Clés appartenant à AWS : elles sont entièrement gérées par AWS et sont utilisées par défaut si aucune autre option n’est spécifiée. Elles sont gratuites et ne nécessitent aucune configuration supplémentaire.
2. Clés gérées par AWS : il s’agit de clés principales client (CMK) stockées dans AWS Key Management Service (KMS) qui sont créées, gérées et utilisées pour le compte du client par AWS. Elles fournissent des fonctionnalités de contrôle et d’audit supplémentaires par rapport aux clés détenues par AWS.
3. Clés gérées par le client : il s’agit de clés CMK que vous créez, possédez et gérez dans AWS KMS. Elles offrent le plus haut niveau de contrôle sur les clés de chiffrement, notamment la possibilité de créer, de faire pivoter, de désactiver et de définir des contrôles d’accès.

Chacun de ces types de clés offre un équilibre différent en termes de commodité, de contrôle et de coût. Les clés détenues par AWS sont les plus simples à utiliser, tandis que les clés gérées par le client offrent le plus de contrôle, mais nécessitent des frais de gestion plus importants.

Le chiffrement au repos permet de protéger les données en chiffrant les fichiers contenant des informations sensibles lorsqu’ils sont inactifs. Lorsque les données sont chiffrées au repos, les parties non autorisées ne peuvent pas accéder au contenu en texte brut, même si elles peuvent accéder physiquement aux appareils qui stockent les données. Cela fournit un niveau de sécurité supplémentaire pour les données au-delà des simples contrôles d’accès et permet de garantir la confidentialité des informations, même en cas de perte ou de vol de l’appareil physique.

Oui, DynamoDB prend en charge la journalisation des audits pour les modifications au niveau des éléments dans les tables. DynamoDB est intégré à AWS CloudTrail, un service qui fournit un enregistrement des actions effectuées par un utilisateur, un rôle ou un service AWS dans DynamoDB au niveau de l’élément. Les données de journalisation supplémentaires capturées incluent les créations, les mises à jour, les suppressions et tout échec de vérification conditionnelle. Les clients peuvent accéder à ces enregistrements de journaux stockés dans CloudWatch Logs et créer des applications pour analyser les changements au niveau des articles à des fins d’audit, de surveillance ou toute autre raison. La journalisation des audits fournit une visibilité des modifications de données à un niveau granulaire sans affecter les performances normales de lecture/écriture de la table DynamoDB.

Oui, vous pouvez utiliser Amazon DynamoDB pour créer des applications conformes HIPAA et stocker des données de santé, notamment des données de santé protégées dans le cadre de l’exécution d’un accord de partenariat (BAA) avec AWS.

DynamoDB répond à de nombreuses certifications de conformité, notamment les certifications éligibles HIPAA, FedRAMP, ISO 27001, SOC 1/SSAE 16/ISAE 3402 (anciennement SAS 70) et SOC 2. Pour plus d’informations, consultez Validation de conformité par l’industrie pour DynamoDB. Les rapports de conformité AWS sont disponibles et téléchargeables sur AWS Artifact.

Les tables globales Amazon DynamoDB sont une base de données entièrement gérée, sans serveur, multirégion et multiactive. Les tables globales offrent une disponibilité de 99,999 %, une résilience accrue des applications et une meilleure continuité des activités. Elles répliquent automatiquement vos tables Amazon DynamoDB dans les Régions AWS de votre choix, vous ainsi permettant d’obtenir des performances en lecture et en écriture locales rapides. Les tables globales utilisent les mêmes API que les tables DynamoDB à région unique. Vous pouvez donc facilement rendre vos tables DynamoDB disponibles dans le monde entier sans modifier l’application.

Une table globale est un ensemble d’une ou plusieurs tables de réplication, toutes détenues par un seul compte AWS. Une seule table globale Amazon DynamoDB ne peut comporter qu’une seule table de réplication par Région AWS.

Vous pouvez utiliser des tables globales pour améliorer la résilience de votre application dans plusieurs régions. Les tables globales permettent également aux applications de maintenir une haute disponibilité dans le cas peu probable d’isolement ou de dégradation d’une région entière.

Deux versions des tables globales DynamoDB sont disponibles : la version 2019.11.21 (actuelle) et la version 2017.11.29 (ancienne). Les clients doivent utiliser la version 2019.11.21 (actuelle) pour toutes les nouvelles tables globales, car cette version est plus efficace et consomme moins de capacité d’écriture. Toute personne utilisant la version 2017.11.29 (ancienne) devrait mettre à niveau ses tables globales vers la version 2019.11.21 (Current).

Vous pouvez mettre à niveau la version d’une table globale en quelques clics dans la Console de gestion AWS. La mise à niveau de la version 2017.11.29 (ancienne) vers la version 2019.11.21 (Current) est une action unique et irréversible. Avant la mise à niveau, assurez-vous d’avoir examiné les différences de comportement entre les versions et d’avoir effectué tous les tests nécessaires. Pour plus d’informations, consultez Mise à niveau des tables globales de la version 2017.11.29 (ancienne) vers la version 2019.11.21 (actuelle).

Les tables globales DynamoDB utilisent la réplication multiactive entre les régions, où toutes les tables de réplication de toutes les régions d’une table globale prennent en charge le trafic de lecture et d’écriture. Une table globale ne possède pas de région principale et, par conséquent, aucun basculement de base de données n’est requis pour diriger le trafic de lecture et d’écriture vers une autre région. Dans le cas peu probable où une Région AWS serait isolée ou dégradée, votre application peut simplement lire et écrire à partir d’une table de répliques située dans une région non affectée. Pour plus d’informations, consultez Pratiques exemplaires en matière de conception de tables globales DynamoDB.

Une table de réplication est une table DynamoDB unique. Chaque table de réplication stocke le même ensemble d’éléments de données, possède le même nom de table et le même schéma de clé primaire. Lorsqu’une application écrit des données dans une table de réplique dans une région, DynamoDB propage automatiquement l’écriture dans les autres tables de réplique des autres Régions AWS.

Oui, les tables globales DynamoDB renforcent la continuité des activités en augmentant la résilience d’une application et en fournissant une cohérence solide pour une seule région. Grâce à une forte cohérence multirégionale, vous pouvez créer des applications avec zéro RPO et avec les plus hauts niveaux de résilience.

Vous pouvez créer une table globale à l’aide de la console DynamoDB, de l’interface de la ligne de commande AWS ou d’AWS CloudFormation grâce à ce guide étape par étape.

Avant d’ajouter une réplique supplémentaire dans une région différente à une table globale DynamoDB, DynamoDB Streams doit être activé sur la table, porter le même nom que toutes les autres répliques, avoir la même clé de partition que toutes les autres répliques et avoir les mêmes paramètres de capacité d’écriture spécifiés.

Toutes les tables répliquées d’une table globale DynamoDB doivent porter le même nom.

Comme d’autres bases de données, DynamoDB stocke les données dans des tables. Un tableau est un ensemble d’éléments, et chaque élément est un ensemble d’attributs. DynamoDB utilise des clés primaires pour identifier de manière unique chaque élément d’un tableau et possède des index secondaires pour offrir une plus grande flexibilité en matière de requêtes.

Oui, vous pouvez activer la restauration instantanée sur chaque réplique d’une table globale DynamoDB.

Oui, DynamoDB prend en charge la capture des données modifiées (CDC) qui est implémentée à l’aide d’un modèle de streaming permettant permet aux applications de capturer les modifications au niveau des éléments dans une table DynamoDB en temps quasi réel sous la forme d’un flux d’enregistrements de données. Le flux d’enregistrements de données CDC permet aux applications de traiter et de répondre efficacement aux modifications des données dans la table DynamoDB. DynamoDB propose deux modèles de streaming pour la CDC : DynamoDB Streams et Kinesis Data Streams pour DynamoDB. Pour vous aider à choisir la solution adaptée à votre application, consultez les options de streaming pour la capture des données modifiées.

Un flux DynamoDB est un flux ordonné d’informations concernant les modifications apportées aux éléments d’une table DynamoDB. DynamoDB Streams capture une séquence dédupliquée et chronologique des modifications au niveau de l’élément dans une table et stocke ces informations dans un journal pour une durée maximale de 24 heures. Par défaut, DynamoDB Streams met automatiquement la capacité à l’échelle, ce qui vous dispense de son allocation et de sa gestion. En fonction de votre configuration DynamoDB Streams, vous pouvez afficher les éléments de données tels qu’ils apparaissent avant et après leur modification. Vous pouvez créer des applications qui consomment ces événements de flux et invoquer des flux de travail en fonction du contenu du flux d’événements.

DynamoDB Streams est utile lorsque vous souhaitez réagir à des modifications de données à l’aide de déclencheurs à l’aide de l’intégration native avec AWS Lambda, suivre et analyser les interactions avec les clients ou surveiller les performances des applications en temps quasi réel, capturer des séquences ordonnées d’événements et améliorer la résilience des applications en répliquant les données transactionnelles au niveau des éléments.

Kinesis Data Streams capture les modifications au niveau de l’élément dans une table DynamoDB et les réplique dans un flux de données Kinesis. Vos applications peuvent accéder à ce flux et visualiser les modifications au niveau des éléments en temps quasi réel. Avec Kinesis Data Streams, vous pouvez créer des applications personnalisées qui traitent ou analysent des données de streaming pour des besoins spécifiques. Contrairement à DynamoDB Streams, Kinesis Data Streams pour DynamoDB ne fournit aucune garantie de classement des enregistrements ni de déduplication. Le classement et la déduplication des enregistrements doivent être mis en œuvre par les applications clientes, à l’aide du champ ApproximateCreationDateTime dans l’enregistrement au niveau de l’élément.

Kinesis Data Streams pour DynamoDB est utile si vous avez besoin d’une intégration aux capacités Kinesis au sens large (tel que la bibliothèque client Kinesis, le service géré Amazon pour Apache Flink ou Amazon Data Firehose), d’une conservation et d’une rejouabilité des données plus longues (jusqu’à 365 jours) et d’une gestion personnalisée des partitions pour la consommation en aval et l’analytique du streaming.

Lorsqu’un flux DynamoDB ou un flux de données Kinesis est activé sur une table DynamoDB, celle-ci envoie un enregistrement de données qui capture toutes les modifications apportées aux données de cette table. Cet enregistrement de données inclut l’heure précise à laquelle un élément a été récemment créé, mis à jour ou supprimé, la clé primaire de cet élément, une image de l’élément avant la modification et une image de l’élément après la modification.

Vous pouvez activer ou désactiver les flux sur une table DynamoDB existante à l’aide de la Console de gestion AWS, du SDK AWS, de l’interface de la ligne de commande AWS (AWS CLI) ou de la bibliothèque client Kinesis (KCL).

Choisissez DynamoDB Streams lorsque vous avez spécifiquement besoin de suivre les modifications apportées aux tables DynamoDB. Choisissez Kinesis Data Streams pour des besoins de streaming plus larges, des exigences de débit plus élevées ou lorsque vous avez besoin de périodes de conservation des données plus longues.

La fonctionnalité de durée de vie (TTL) d’Amazon DynamoDB supprime automatiquement les éléments périmés qui ne sont plus pertinents d’un tableau, réduisant ainsi l’utilisation de l’espace de stockage et les coûts. Avec la TTL, vous pouvez définir un horodatage par élément pour déterminer à quel moment un élément n’est plus nécessaire, et DynamoDB supprime automatiquement l’élément de votre table sans consommer de débit d’écriture. Chaque fois qu’un élément est créé ou mis à jour, vous pouvez calculer le délai d’expiration et l’enregistrer dans l’attribut TTL. La TTL est utile si vous stockez des éléments qui perdent leur pertinence après un certain temps.

DynamoDB prend en charge les opérations GET/PUT au moyen d’une clé primaire définie par l’utilisateur. La clé primaire est le seul attribut nécessaire pour les éléments d'une table. Vous spécifiez la clé primaire lors de la création d’une table, et cette clé identifie chaque élément individuellement. DynamoDB propose également une interrogation flexible des bases de données en vous permettant d’interroger des attributs de clé non primaires à l’aide d’index secondaires globaux et d’index secondaires locaux.

Une clé primaire peut être une clé de partition à attribut unique ou une clé composite de type partition-tri. UserID est un exemple de clé de partition à attribut unique. Une telle clé de partition à attribut unique permettrait une lecture et une écriture de données rapides pour un élément associé à un identifiant utilisateur donné.

DynamoDB indexe une clé composite de type partition-tri en tant qu'élément de clé de partition et en tant qu'élément de clé de tri. Cette clé à plusieurs composants maintient une hiérarchie entre la première et la seconde valeurs d’élément. Par exemple, une clé composite de type partition-tri peut être une combinaison des éléments suivants : UserID (partition) et Timestamp (tri). En maintenant la constance de l’élément de clé de partition, il est possible d’effectuer une recherche dans l’élément de clé de type tri afin d’extraire des éléments. Une recherche de la sorte vous permettrait d’utiliser l’API Query pour, par exemple, extraire tous les éléments associés à un identifiant UserID unique dans un intervalle d’horodatage.

DynamoDB prend en charge les clés primaires composées d’un maximum de huit attributs dans les index secondaires globaux (GSI), avec un maximum de quatre attributs chacun pour les clés de partition et de tri.

Après avoir créé une table à l’aide de la console DynamoDB ou de l’API CreateTable, vous pouvez utiliser l’API PutItem ou BatchWriteItem afin d’insérer des éléments. Pour extraire les éléments ajoutés à la table, vous pouvez ensuite utiliser GetItem ou BatchGetItem, ou l’API Query si les clés primaires composites sont activées et utilisées dans votre table.

Oui. DynamoDB est un service de cloud entièrement géré, accessible via l'API. DynamoDB peut-être utilisé par des applications fonctionnant sur n’importe quel système d’exploitation, par exemple Linux, Windows, iOS, Android, Solaris, AIX et HP-UX. Nous vous recommandons d’utiliser les kits SDK AWS pour découvrir DynamoDB.

L’intégration zéro ETL de DynamoDB à OpenSearch Service élimine la complexité opérationnelle liée à l’orchestration de la réplication des données d’un entrepôt de données transactionnelle vers un entrepôt de données de recherche. Les pipelines de données utilisés pour synchroniser les entrepôts de données transactionnelles et de recherche peuvent être difficiles et coûteux à créer et à gérer, et présenter des erreurs intermittentes difficiles à suivre. 

Cette intégration permet aux clients DynamoDB d’obtenir des résultats de recherche en temps quasi réel à partir de leurs données transactionnelles en proposant une solution entièrement gérée permettant de rendre les données transactionnelles de DynamoDB disponibles dans OpenSearch Service quelques secondes après leur rédaction. Les clients choisissent simplement les tables DynamoDB contenant les données qu’ils souhaitent analyser avec OpenSearch Service, et cette intégration zéro ETL reproduit de manière fluide le schéma et les données dans OpenSearch Service à l’aide des pipelines d’ingestion OpenSearch. Les clients peuvent répliquer les données de plusieurs tables DynamoDB dans un seul domaine géré par OpenSearch Service ou dans une collection sans serveur afin d’obtenir des informations holistiques sur plusieurs applications, tout en consolidant leurs principaux actifs analytiques, ce qui leur permet de réaliser d’importantes économies et de gagner en efficacité opérationnelle. 

Les clients peuvent commencer par utiliser la Console de gestion AWS pour DynamoDB, OpenSearch Service, l’interface de ligne de commande AWS, le kit SDK AWS ou AWS CloudFormation. Pour permettre une intégration, les clients choisissent d'abord la table DynamoDB dont les données doivent être répliquées. Les clients choisissent ensuite DynamoDB Streams pour une réplication en temps quasi réel ou DynamoDB Incremental Exports pour une réplication différée comme mécanisme CDC permettant de synchroniser les données entre les deux systèmes. 

Cette intégration zéro ETL met en place un pipeline d'ingestion OpenSearch dans le compte du client qui se charge de répliquer les données vers un cluster géré par OpenSearch Service ou une collection sans serveur. L'ingestion OpenSearch comprend la structure des tables DynamoDB, puis crée un domaine géré par OpenSearch Service équivalent ou une collection sans serveur et amorce la destination avec les données existantes des tables DynamoDB. Les clients peuvent éventuellement spécifier un schéma pour les index qui seront créés dans OpenSearch Service. 

Cette intégration zéro ETL vous fournit un tableau de bord sur lequel vous pouvez surveiller l’état de votre intégration de bout en bout à l’aide de métriques et de journaux en temps réel Amazon CloudWatch. Vous pouvez configurer des alertes en cas de dépassement des seuils définis par l'utilisateur. Cette intégration surveille également en permanence l’état des tables DynamoDB et des indices du service OpenSearch et avertit immédiatement les utilisateurs en cas de régressions avec l’une de ces entités.

Afin de garantir que l’ingestion OpenSearch dispose des autorisations nécessaires pour répliquer les données sur ces deux systèmes, l’intégration zéro ETL de DynamoDB à OpenSearch Service crée un rôle IAM doté des autorisations nécessaires pour lire les données des tables DynamoDB et les écrire dans un domaine ou une collection OpenSearch. Ce rôle est ensuite assumé par les pipelines d’ingestion OpenSearch afin de garantir que la bonne posture de sécurité est toujours maintenue lors du déplacement des données de la source vers la destination.

Cette intégration zéro ETL utilise les capacités natives de transformation des données des pipelines d’ingestion OpenSearch pour agréger et filtrer les données lorsqu’elles sont en mouvement. Lorsqu'ils déplacent les données d'une table DynamoDB, les clients peuvent souhaiter supprimer quelques champs ou en créer de nouveaux en fonction des agrégations entre les champs existants. 

En option, les clients peuvent également écrire une logique personnalisée pour l'ingestion OpenSearch afin d'obtenir une capacité de transformation sur mesure. Pour les autres utilisateurs, qui souhaitent simplement déplacer l’intégralité de leurs données de la source vers le récepteur, cette intégration zéro ETL fournira des plans d’ingestion OpenSearch prêts à l’emploi afin qu’ils puissent effectuer les intégrations en quelques clics.

Cette intégration zéro ETL fournit aux clients des options leur permettant de spécifier leur schéma de données personnalisé ainsi que les mappages d’index utilisés par l’ingestion OpenSearch lors de l’écriture de données depuis DynamoDB vers OpenSearch Service. Cette expérience est ajoutée à la console d’interface utilisateur de DynamoDB afin que les clients aient un contrôle total sur le format des index créés sur OpenSearch Service.

L’utilisation de l’intégration zéro ETL de DynamoDB à OpenSearch Service n’entraîne aucun coût supplémentaire en dehors du coût des composants sous-jacents existants. Cette intégration zéro ETL utilise l’ingestion OpenSearch pour lire les données des tables DynamoDB et les répliquer vers OpenSearch Service. Le coût lié à l’utilisation de l’intégration zéro ETL de DynamoDB à OpenSearch Service correspond au coût des unités de calcul OpenSearch (OCU) nécessaires à l’ingestion OpenSearch pour répliquer les données sur les systèmes. En outre, les clients ont la possibilité de choisir entre des flux DynamoDB ou des exportations incrémentielles auprès de CDC. Pour les exportations incrémentielles, des coûts sont associés à l'écriture de données dans des compartiments S3. Pour les flux DynamoDB, les clients se verraient facturer les frais standard liés à l’utilisation des flux DynamoDB.

L’intégration zéro ETL de DynamoDB à OpenSearch Service est disponible dans toutes les régions dans lesquelles l’ingestion OpenSearch est disponible aujourd’hui.

Oui, vous pouvez souscrire un Database Savings Plan pour votre utilisation d’Amazon DynamoDB et réduire vos coûts jusqu’à 18 % en vous engageant à utiliser un volume constant pendant une période d’un an. Vous trouverez des informations supplémentaires sur les utilisations éligibles sur la page de tarification des Database Savings Plans.

Oui, DynamoDB fournit une généreuse offre gratuite de 25 Go de stockage, ainsi que 25 unités de capacité d’écriture et 25 unités de capacité de lecture (WCU, RCU) provisionnées, ce qui est suffisant pour traiter 200 millions de demandes par mois.

DynamoDB est une base de données non relationnelle entièrement sans serveur. Par rapport à d’autres bases de données facturées en fonction de divers indicateurs, tels que le stockage, DynamoDB peut évoluer jusqu’à zéro, ce qui signifie que lorsque les clients utilisent le mode à la demande, ils ne paient que pour les ressources actives consommées.

En termes simples, la solution à la demande convient mieux aux clients qui préfèrent ne payer que pour ce qu’ils utilisent ou qui sont confrontés à des charges de travail imprévisibles. La capacité provisionnée est populaire auprès des clients dont les applications présentent un trafic constant ou prévisible et préfèrent prévoir les besoins en capacité afin de contrôler les coûts.

DynamoDB est unique en ce sens qu’il s’agit d’une base de données sans serveur qui offre aux clients la possibilité de ne payer que pour les ressources qu’ils consomment, tout en passant à zéro lorsqu’ils ne sont pas utilisés avec une tarification à la demande. Lorsque la base de données est en cours d’utilisation, les unités de demande d’écriture et les unités de demande de lecture sont utilisées pour calculer les frais.

DynamoDB inclut un large éventail d’options qui peuvent être ajoutées au service. Une liste partielle comprend :

• Une sauvegarde à la demande qui effectue des sauvegardes instantanées à des moments précis
• Des tables globales pour une réplication multirégionale et multiactive
• DynamoDB Accelerator (DAX), un service de mise en cache compatible avec Amazon DynamoDB, réduit la latence grâce au cache en mémoire
• Un flux DynamoDB pour des séquences chronologiques de modifications apportées à une table au niveau des éléments