Q : Qu'est-ce qu'Amazon DynamoDB ?

Amazon DynamoDB est un service de base de données NoSQL entièrement géré, offrant des performances exceptionnelles et prévisibles en termes de rapidité et d'évolutivité. Grâce à Amazon DynamoDB, les clients s'appuient totalement sur AWS pour l'exploitation et le dimensionnement 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, les correctifs logiciels ou encore le dimensionnement des clusters.

Q : Quelles opérations Amazon DynamoDB effectue-t-il à ma place ?

Grâce à Amazon DynamoDB les clients n'ont plus à gérer les problèmes majeurs liés au dimensionnement et à la gestion des bases de données, ainsi qu'à l'approvisionnement en matériel nécessaire pour les faire fonctionner. Une base de données non relationnelle peut désormais être déployée en quelques minutes. DynamoDB fait évoluer automatiquement la capacité de débit pour répondre aux exigences de la charge de travail, et il partitionne et repartitionne vos données au fur et à mesure que la taille de votre table augmente. De plus, Amazon DynamoDB réplique les données de manière synchronisée sur trois installations 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.

Q : Que signifie la cohérence de lecture ? Pourquoi devrais-je m'en soucier ?

Amazon DynamoDB répartit trois copies de tables sur plusieurs zones pour assurer la haute disponibilité et la durabilité des données. La cohérence de la lecture indique de quelle manière et à quel moment l'écriture ou la mise à jour réussie d'un élément de données est répercutée dans une opération ultérieure de lecture de ce même élément. Amazon DynamoDB expose une logique qui vous permet d'indiquer la cohérence des caractéristiques que vous désirez pour chaque demande de lecture dans votre application.

Q : En quoi consiste le modèle de cohérence d'Amazon DynamoDB ?

Lors de la lecture de données sur Amazon DynamoDB, les utilisateurs peuvent configurer une lecture cohérente à terme ou une lecture à cohérence forte :

Lectures cohérentes à terme (par défaut) – L'option de cohérence à terme vous permet de maximiser le débit de lecture. Cependant, une lecture cohérente à terme peut ne pas refléter les résultats d'une écriture récente. La cohérence de l'ensemble des copies de données est généralement atteinte en une seconde. Répéter une lecture après une courte pause renvoie généralement les données mises à jour.

Lectures à cohérence forte – En plus de l'option de cohérence à terme, Amazon DynamoDB vous offre la flexibilité et le suivi permettant de configurer une lecture à cohérence forte en fonction des besoins d'une partie ou de l'ensemble de votre application. Une lecture à cohérence forte renvoie un résultat indiquant toutes les écritures réussies avant la lecture.

Q : DynamoDB prend-il en charge les mises à jour atomiques intégrées ?

Amazon DynamoDB prend en charge les mises à jour intégrées rapides. Vous pouvez effectuer des opérations d'incrémentation et de décrémentation d'attribut numérique dans une ligne via un simple appel API. De même, vous pouvez ajouter ou supprimer de façon atomique des ensembles, des listes ou des cartes. Pour en savoir plus sur les mises à jour atomiques, consultez notre documentation.

Q : Pourquoi Amazon DynamoDB est-il développé sur des disques SSD ?

Amazon DynamoDB s'exécute exclusivement sur des disques SSD. Les disques SSD nous permettent d'assurer des temps de réponse à faible latence pour le stockage des données et l'accès à celles-ci à n'importe quelle échelle. Les performances E/S des disques SSD permettent également de traiter les gros volumes de requêtes efficacement et de refléter cette efficacité en proposant des tarifs bas pour les requêtes.

Q : Les coûts de stockage de DynamoDB semblent élevés. Ce service est-il rentable pour mon cas d'utilisation ?

Comme pour tous les produits, nous encourageons les potentiels clients d'Amazon DynamoDB à appréhender l'achat d'une solution dans sa globalité et pas uniquement d'un point de vue tarifaire. Le coût total du traitement de la charge de travail d'une base de données dépend des exigences en termes de trafic des requêtes et de volume des données stockées. En règle générale, les charges de travail de bases de données sont caractérisées par un trafic E/S dense (nombre élevé de lectures/seconde et d'écritures/seconde) par Go stocké. Amazon DynamoDB est développé sur des disques SSD, ce qui augmente le coût par Go stocké, relatif aux supports fonctionnant par rotation, mais permet également de proposer des requêtes à moindre coût. Notre expérience des charges de travail des bases de données classiques nous montre que le coût total de l'utilisation du service DynamoDB basé sur SSD est généralement plus faible que le coût d'utilisation d'une base de données classique relationnelle ou non relationnelle basé sur un support de rotation. Si votre cas d'usage implique le stockage d'une grande quantité de données rarement consultées, DynamoDB ne semble pas être la solution adaptée. Nous vous recommandons d'utiliser S3 pour ce type de cas d'usage.

Notez également que les coûts de stockage prennent en compte le stockage de plusieurs copies de chaque élément de données sur plusieurs installations au sein d'une région AWS.

Q : DynamoDB est-il uniquement destiné à des applications à grande échelle ?

Non. DynamoDB offre un dimensionnement transparent afin que vous puissiez évoluer automatiquement en suivant l'évolution des exigences de votre application. Si vous recherchez des hautes performances en matière de rapidité et de prévision à n'importe quelle échelle, DynamoDB semble être la solution idéale.

Q : Comment démarrer avec Amazon DynamoDB ?

Cliquez sur « S'inscrire » pour commencer à utiliser Amazon DynamoDB dès aujourd'hui. Vous pourrez alors commencer à interagir avec Amazon DynamoDB à l'aide d'AWS Management Console ou des API Amazon DynamoDB. Si vous utilisez AWS Management Console, vous pouvez créer une table avec Amazon DynamoDB et commencer à naviguer en seulement quelques clics.

Q : Quel type de fonctionnalité de requête DynamoDB prend-il en charge ?

Amazon DynamoDB prend en charge des opérations GET/PUT à l'aide d'une clé primaire définie par l'utilisateur. Unique attribut requis pour les éléments d'une table, la clé primaire identifie chaque élément de manière unique. Vous devez spécifier la clé primaire lors de la création de la table. Sachez par ailleurs que DynamoDB offre une grande flexibilité en vous permettant d'effectuer des requêtes portant sur des attributs autres que la clé primaire, à l'aide des index secondaires globaux et 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é primaire de partition à attribut unique. Celle-ci permet une lecture et une écriture de données rapides pour un élément associé à un identifiant utilisateur donné.

Une clé composite de type partition-tri est indexée en tant qu'élément de clé de partition et en tant qu'élément de clé de tri. Cette clé à plusieurs composants présente une hiérarchie entre la première et la seconde valeur d'élément. Par exemple, une clé composite de type partition-tri peut être une combinaison des éléments suivants : « UserID » (partition) et « Horodateur » (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 pour extraire des données. Vous pouvez ainsi utiliser l'API Query pour extraire tous les éléments associés à un identifiant UserID unique dans un intervalle d'horodateurs.

Pour en savoir plus sur les index secondaires globaux et sur les possibilités de requêtes offertes par cette fonctionnalité, consultez la section Index secondaires de cette page.

 

Q : Comment mettre à jour et interroger des éléments de données avec Amazon DynamoDB ?

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

Q : Amazon DynamoDB prend-il en charge les opérations conditionnelles ?

Oui, vous pouvez spécifier une condition à respecter pour permettre l'ajout, la mise à jour ou la suppression d'un élément. Pour procéder à une opération conditionnelle, vous pouvez définir une ExpressionCondition, construite de la façon suivante :

  • Fonctions booléennes : ATTRIBUTE_EXIST, CONTAINS, and BEGINS_WITH
  • Opérateurs de comparaison : =, <>, <, >, <=, >=, BETWEEN et IN
  • Opérateurs logiques : NOT, AND et OR. 

Vous pouvez construire une expression conditionnelle de forme libre qui combine plusieurs clauses conditionnelles, notamment des clauses imbriquées. Les opérations conditionnelles permettent aux utilisateurs de mettre en place des systèmes de contrôle d'accès concurrentiel optimiste dans DynamoDB. Pour plus d'informations sur les opérations conditionnelles, consultez notre documentation.

Q : Les expressions sont-elles prises en charge par les conditions clés ?

Oui, vous pouvez spécifier une expression dans le cadre de l'appel d'API Query pour filtrer des résultats en fonction des valeurs des clés primaires sur une table à l'aide du paramètre KeyConditionExpression.

Q : Les expressions sont-elles prises en charge par les clés de partition et de partition-tri ?

Oui, vous pouvez utiliser des expressions pour des clés de partition et de partition-tri. Reportez-vous à la page de documentation pour découvrir les expressions qui s'exécutent sur des clés de partition et de partition-tri.

Q : Amazon DynamoDB prend-il en charge les opérations d'incrémentation ou de décrémentation ?

Oui, Amazon DynamoDB prend en charge les opérations d'incrémentation et de décrémentation atomiques sur des valeurs scalaires.

Q : Dans quels cas est-il préférable d'utiliser Amazon DynamoDB à la place d'un moteur de base de données relationnelle sur Amazon RDS ou Amazon EC2 ?

Les applications Web actuelles génèrent et consomment un volume de données élevé. Par exemple, un jeu en ligne peut commencer avec quelques milliers d'utilisateurs et une faible charge de travail de base de données de 10 écritures par seconde et 50 lectures par seconde. Si toutefois ce jeu devient populaire, le nombre d'utilisateurs peut rapidement passer à quelques millions et générer des dizaines (voire des centaines) de milliers d'écritures et de lectures par seconde. Cela peut également générer des téraoctets de données par jour. Le développement d'applications sur Amazon DynamoDB vous permet d'accroître progressivement votre capacité de requêtes par table en fonction de l'évolution de vos besoins tout en évitant les temps d'arrêt. Les coûts liés à la capacité de requêtes allouée sont très rentables. Vous pouvez ainsi laisser Amazon DynamoDB gérer le partitionnement de vos données ainsi que le trafic en s'appuyant sur des capacités serveur suffisantes pour répondre à vos besoins. Amazon DynamoDB se charge de la gestion et de l'administration de la base de données afin que vous n'ayez qu'à stocker et interroger vos données. La réplication et le basculement automatiques garantissent la tolérance aux pannes, la haute disponibilité et la durabilité des données. Grâce à Amazon DynamoDB, votre base de données est entièrement gérée et peut évoluer au rythme des besoins de votre application.

Tandis qu'Amazon DynamoDB s'attaque aux problèmes majeurs liés à l'évolutivité, à la gestion, aux performances et à la fiabilité des bases de données, le système ne présente pas toutes les fonctionnalités d'une base de données relationnelle. En effet, les transactions ou les requêtes relationnelles complexes (par ex. : les jonctions) ne sont pas prises en charge. Si votre charge de travail requiert cette fonctionnalité, ou si vous recherchez une compatibilité avec un moteur relationnel existant, vous devrez peut-être exécuter un moteur relationnel sur Amazon RDS ou Amazon EC2. Alors que les moteurs de base de données relationnelle présentent des caractéristiques et fonctionnalités robustes, le dimensionnement d'une charge de travail sur plusieurs instances de base de données relationnelle est très complexe et requiert par conséquent le temps et l'expertise appropriés. Ainsi, si vous envisagez un dimensionnement de votre nouvelle application, et que vous n'avez pas besoin de fonctionnalités relationnelles, Amazon DynamoDB semble être la solution idéale.

Q : En quoi Amazon DynamoDB est-il différent d'Amazon SimpleDB ?

Lequel des deux dois-je utiliser ? Ces services sont tous deux des bases de données non relationnelles prenant en charge la gestion de votre base de données. Amazon DynamoDB a pour but principal d'offrir une évolutivité transparente, ainsi que des performances rapides et prévisibles. Son exécution sur des disques SSD (Solid State Disks) garantit des temps de réponse à faible latence et offre une capacité de requête ou de stockage illimitée pour une table donnée. Cela est possible car Amazon DynamoDB partitionne automatiquement vos données et votre charge de travail sur un nombre approprié de serveurs afin de respecter vos exigences en termes de dimensionnement. En revanche, une table créée dans Amazon SimpleDB présente une limite de stockage de 10 Go et une limite dans la capacité de requêtes pouvant être exécutées (généralement inférieure à 25 écritures par seconde). Vous êtes donc chargé de la gestion du partitionnement et du repartitionnement de vos données sur d'autres tables SimpleDB lorsqu'un dimensionnement supplémentaire est requis. Bien que proposant un système de dimensionnement limité, le service SimpleDB peut être adapté à des charges de travail moins conséquentes nécessitant une exécution flexible des requêtes. Amazon SimpleDB indexe automatiquement tous les attributs d'élément et prend ainsi en charge la flexibilité des requêtes au détriment des performances et du dimensionnement.

La publication de Werner Vogels, directeur technique d'Amazon sur le blog DynamoDB fournit des informations supplémentaires sur l'évolution de la technologie des bases de données non relationnelles chez Amazon.

Q : Dans quels cas est-il préférable d'utiliser Amazon DynamoDB à la place d'Amazon S3 ?

Amazon DynamoDB assure le stockage de données structurées, indexées par une clé primaire et offre un accès à faible latence en lecture et en écriture à des éléments compris entre 1 octet et 400 Ko. Permettant le stockage de blobs non structurés, Amazon S3 est adapté au stockage d'objets volumineux pouvant atteindre 5 To. Pour optimiser les coûts liés aux services AWS, nous vous recommandons de stocker les objets lourds ou les données peu consultées dans Amazon S3, et les plus petits éléments ou les pointeurs de fichier (possiblement vers des objets sur Amazon S3) sur Amazon DynamoDB.

Q : DynamoDB peut-il être utilisé par les applications s'exécutant sur n'importe quel système d'exploitation ?

Oui. DynamoDB est un service de cloud entièrement géré, accessible via l'API. DynamoDB peut être utilisé par les applications s'exécutant sur n'importe quel système d'exploitation (par ex. Linux, Windows, iOS, Android, Solaris, AIX, HP-UX, etc.). Nous vous recommandons d'utiliser les kits de développement logiciel AWS pour découvrir DynamoDB. Vous trouverez une liste complète des kits de développement logiciel AWS sur notre page Ressources pour développeurs. Si vous éprouvez des difficultés à installer ou à utiliser l'un de nos kits SDK, faites-le-nous savoir en publiant un commentaire sur le forum AWS concerné.


Q : Quel est le modèle de données utilisé ?

Le modèle de données d'Amazon DynamoDB est composé des éléments suivants :

Table : Une table est un ensemble d'éléments de données (de même qu'une table est un ensemble de lignes dans une base de données relationnelle). Chaque table peut contenir un nombre illimité d'éléments de données. Amazon DynamoDB ne suivant aucun schéma spécifique, les éléments de données d'une table n'ont pas nécessairement les mêmes attributs ni le même nombre d'attributs. Chaque table doit contenir une clé primaire. La clé primaire peut être une clé à attribut unique ou une clé à attribut composite combinant deux attributs. Les attributs que vous définissez comme clé primaire doivent être associés à chaque élément, les clés primaires identifiant chaque élément de la table individuellement.

Elément : Un élément est composé d'une clé primaire ou composite et d'un nombre variable d'attributs. Le nombre d'attributs associés à un élément individuel n'est pas limité, mais la taille globale d'un élément, comprenant notamment les noms et valeurs d'attribut, ne doit pas dépasser 400 Ko.

Attribut : Chaque attribut associé à un élément de données est composé d'un nom d'attribut (par ex. : « Couleur ») et d'une valeur ou d'un ensemble de valeurs (par ex. : « Rouge » ou « Rouge, Jaune, Vert »). Le nombre d'attributs individuels n'est pas limité mais la valeur totale d'un élément (noms et valeurs d'attributs compris) ne peut pas dépasser 400 Ko.

Q : La taille des éléments est-elle limitée ?

La taille maximale d'un élément, noms et valeurs d'attributs compris, est de 400 Ko.

Q : Le nombre d'attributs d'un élément est-il limité ?

Le nombre d'attributs pouvant être associés à un élément n'est pas limité. Cependant, la taille maximale d'un élément, valeurs et noms d'attributs compris, est de 400 Ko.

Q : Quelles sont les API utilisées ?

  • CreateTable – Permet de créer une table et de spécifier l'index primaire utilisé pour accéder aux données.
  • UpdateTable – Permet de mettre à jour les valeurs du débit réservé pour une table donnée.
  • DeleteTable – Permet de supprimer une table.
  • DescribeTable – Permet d'obtenir des informations relatives à la taille, au statut et à l'index de la table.
  • ListTables – Permet d'obtenir la liste des tables associées au compte et au point de terminaison actifs.
  • PutItem – Permet de créer un nouvel élément ou de remplacer un ancien élément (avec tous les attributs associés). Si la table spécifiée contient déjà un élément associé à la même clé primaire, le nouvel élément remplace l'élément existant. Vous pouvez également utiliser des opérateurs conditionnels pour remplacer un élément uniquement si ses attributs respectent certaines conditions ou pour insérer un nouvel élément uniquement s'il n'est pas déjà contenu dans la table.
  • BatchWriteItem – Permet d'insérer, de remplacer et de supprimer plusieurs éléments au sein de différentes tables à partir d'une même requête, mais via plusieurs transactions. Cette API prend en charge des lots de 25 éléments maximum de type Put ou Delete, avec une taille totale maximale de 16 Mo pour la requête.
  • UpdateItem – Permet de modifier les attributs d'un élément existant. Vous pouvez également utiliser des opérateurs conditionnels pour effectuer une mise à jour uniquement si les valeurs d'attribut de l'élément respectent certaines conditions.
  • DeleteItem – Permet de supprimer un seul élément d'une table par clé primaire. Vous pouvez également utiliser des opérateurs conditionnels pour supprimer un élément uniquement si les valeurs d'attribut de l'élément respectent certaines conditions.
  • GetItem – L'opération GetItem renvoie un ensemble d'attributs d'un élément correspondant à la clé primaire. L'opération GetItem permet par défaut d'effectuer une lecture cohérente à terme. Si votre application ne prend pas en charge les lectures cohérentes à terme, utilisez ConsistentRead.
  • BatchGetItem – L'opération BatchGetItem renvoie les attributs associés à plusieurs éléments depuis plusieurs tables à l'aide des clés primaires correspondantes. Chaque réponse est limitée à 16 Mo et renvoie 100 éléments maximum. Cohérence forte et à terme.
  • Query – Permet d'obtenir un ou plusieurs éléments à l'aide de la clé primaire de la table, ou de la clé de l'index secondaire en cas de requête dans un index secondaire. Vous pouvez restreindre l'étendue de la requête sur une table à l'aide d'opérateurs de comparaison ou d'expressions. Vous pouvez également appliquer des filtres à des attributs non clés. Cohérence forte et à terme. Une réponse simple a une taille limitée à 1 Mo.
  • Scan – Permet d'obtenir tous les éléments et attributs en effectuant une analyse complète de la table ou d'un index secondaire. Vous pouvez limiter le nombre de résultats renvoyés en appliquant des filtres sur un ou plusieurs attributs.

Q : Quel est le modèle de cohérence de l'opération d'analyse (Scan) ?

L'opération d'analyse prend en charge les lectures cohérentes et les lectures cohérentes à terme. Par défaut, l'opération d'analyse est cohérente à terme. Toutefois, vous pouvez modifier le modèle de cohérence à l'aide du paramètre optionnel ConsistentRead dans l'appel d'API Scan. Définir le paramètre ConsistentRead sur True vous permettra d'effectuer des lectures cohérentes à partir des opérations d'analyse. Pour plus d'informations, consultez la documentation relative à l'opération d'analyse.

Q : Comment fonctionne l'opération d'analyse (Scan) ?

L'opération d'analyse (Scan) fonctionne comme un itérateur. Lorsque la taille globale des éléments analysés pour une requête API Scan dépasse 1 Mo, la requête se termine et les résultats obtenus sont renvoyés avec LastEvaluatedKey (pour que l'analyse se poursuive au cours d'une opération ultérieure).

Q : Existent-ils des limites pour une opération d'analyse (Scan) ?

Une opération d'analyse (Scan) sur une table ou un index secondaire est limitée à 1 Mo de données par opération. Une fois la limite dépassée, l'opération se termine et renvoie les valeurs correspondantes à ce point avec LastEvaluatedKey (pour que l'analyse se poursuive au cours d'une opération ultérieure).

Q : Combien d'unités de capacité de lecture consomme une opération d'analyse (Scan) ?

Les unités de lecture requises sont le nombre d'octets extraits par l'opération d'analyse, arrondis à 4 Ko près et divisés par 4 Ko. L'analyse d'une table composée de lectures cohérentes consomme deux fois plus de capacité de lecture qu'une analyse de lectures cohérentes à terme.

Q : Quels sont les types de données pris en charge par DynamoDB ?

DynamoDB prend en charge quatre types de données scalaires : Nombres, chaînes, binaire et booléen. De plus, DynamoDB prend en charge les types de données de regroupement suivants : Ensemble de nombres, ensemble de chaînes, ensemble binaire, liste hétérogène et carte hétérogène. DynamoDB prend également en charge les valeurs NULL.

Q : Quels types de structures de données DynamoDB prend-il en charge ?

DynamoDB prend en charge les structures de données du document et clé-valeur.

Q : Qu'est-ce qu'un magasin clé-valeur ?

Un magasin clé-valeur est un service de base de données qui fournit une assistance pour stocker, rechercher et mettre à jour des collections d'objets qui sont identifiées à l'aide d'une clé et de valeurs, contenant le véritable contenu stocké.

Q : Qu'est-ce qu'un magasin de documents ?

Un magasin de documents fournit une assistance pour stocker, rechercher et mettre à jour des éléments dans un format de document tel que JSON, XML et HTML.

Q : DynamoDB dispose-t-il d'un type de données JSON ?

Non, mais vous pouvez utiliser le document SDK pour faire passer directement les données JSON dans DynamoDB. Les types de données DynamoDB constituent un surensemble de types de données pris en charge par JSON. Le document SDK mappera automatiquement les documents JSON sur les types de données DynamoDB natives.

Q : Puis-je utiliser AWS Management Console pour consulter et modifier des documents JSON ?

Oui. AWS Management Console offre une interface utilisateur simple permettant d'explorer et de modifier les données stockées dans vos tables DynamoDB, y compris les documents JSON. Pour consulter ou modifier des données dans votre table, connectez-vous à AWS Management Console, choisissez DynamoDB, sélectionnez la table que vous souhaitez afficher, puis cliquez sur le bouton « Explore Table » (Explorer la table).

Q : La recherche de données JSON est-elle différente dans DynamoDB ?

Non. Vous pouvez créer un index secondaire global ou local sur tout élément JSON de premier niveau. Imaginons par exemple que vous avez stocké un document JSON contenant les informations suivantes sur une personne : prénom, nom, code postal et une liste de tous ses amis. Le prénom, le nom et le code postal constituent les éléments JSON de premier niveau. Vous pouvez créer un index vous permettant de procéder à des recherches sur la base du prénom, du nom ou du code postal. La liste d'amis ne constitue pas un élément de premier niveau ; vous ne pouvez donc pas l'indexer. Pour en savoir plus sur les index secondaires globaux et sur les possibilités de requêtes offertes par cette fonctionnalité, consultez la section Index secondaires de cette FAQ.

Q : Si j'ai imbriqué des données JSON dans DynamoDB, puis-je récupérer uniquement un élément spécifique de ces données ?

Oui. Lorsque vous utilisez les API GetItem, BatchGetItem, Query ou Scan, vous pouvez définir une ExpressionProjection pour déterminer les attributs qui doivent être récupérés dans la table. Ces attributs peuvent contenir des scalaires, des ensembles ou des éléments d'un document JSON.

Q : Si j'ai imbriqué des données JSON dans DynamoDB, puis-je mettre à jour uniquement un élément spécifique de ces données ?

Oui. Lorsque vous mettez à jour une entrée DynamoDB, vous pouvez spécifier le sous-élément du document JSON que vous souhaitez mettre à jour.

Q : Qu'est-ce que le document SDK ?

Le document SDK est un wrapper de types de données pour JavaScript qui permet d'assurer facilement une interopérabilité entre des types de données JS et DynamoDB. Grâce à ce kit de développement logiciel, les demandes seront automatiquement « emballées » pour vous. Et en guise de réponses, les types de données seront ensuite « déballés ». Pour en savoir plus et télécharger le kit SDK, consultez ici notre répertoire GitHub.

 


Q : La quantité de données pouvant être stockées dans Amazon DynamoDB est-elle limitée ?

Non. Il n'y a aucune limite au volume de données que vous pouvez stocker dans une table Amazon DynamoDB. Lorsque la taille de votre jeu de données augmente, Amazon DynamoDB répartit automatiquement vos données sur les ressources appropriées afin de respecter vos exigences en termes de stockage.

Q : Le débit pouvant être atteint avec une seule table est-il limité ?

Non. Vous pouvez augmenter la limite de capacité maximum pour Auto Scaling ou augmenter le débit alloué manuellement pour votre table en utilisant l'API ou AWS Management Console. DynamoDB est capable de fonctionner à grande échelle et le débit maximum pouvant être atteint n'est pas limité. DynamoDB divise automatiquement la table en plusieurs partitions, chaque partition représentant une unité de calcul parallèle indépendante. Plus le nombre de partitions augmente, plus le rythme de débit assuré par DynamoDB augmente.

Pour obtenir un débit supérieur à 10 000 écritures ou lectures par seconde, contactez Amazon au préalable en remplissant ce formulaire en ligne.

Q : Amazon DynamoDB reste-t-il disponible lorsque Auto Scaling déclenche une augmentation ou lorsqu'il y a une réduction des capacités suite à une modification du débit alloué ?

Oui. Amazon DynamoDB est conçu pour faire évoluer son débit alloué à la hausse ou à la baisse tout en le laissant disponible, qu'il soit géré par Auto Scaling ou manuellement.

Q : Dois-je gérer le partitionnement côté client en plus d'Amazon DynamoDB ?

Non. Avec Amazon DynamoDB, vous n'avez pas besoin d'effectuer de partition dans les tables de bases de données pour assurer l'évolutivité du débit.

Q : Quel est le degré de haute disponibilité d'Amazon DynamoDB ?

Ce service s'exécute dans les centres de données haute disponibilité d'Amazon, dont la qualité n'est plus à démontrer. Ce service réplique les données sur trois installations au sein d'une région AWS afin de garantir une tolérance aux pannes en cas de défaillance du serveur ou de panne de la zone de disponibilité.

Q : Comment optimiser les temps de fonctionnement et la durabilité avec Amazon DynamoDB ?

Pour optimiser les temps de fonctionnement et la durabilité, Amazon DynamoDB réplique les données de manière synchronisée sur trois installations dans une région AWS.


Q : Qu'est-ce qu'Auto Scaling de DynamoDB ?

Auto Scaling de DynamoDB est une fonction entièrement gérée qui dimensionne à la hausse ou à la baisse les capacités de lecture et d'écriture allouées d'une table DynamoDB ou d'un index secondaire global, suivant si les demandes de l'application augmentent ou diminuent.

Q : Pourquoi utiliser Auto Scaling ?

Avec Auto Scaling, vous n'avez plus besoin de deviner la capacité adéquate à allouer lors de la création de nouvelles tables. Ainsi, il n'est plus nécessaire de surveiller constamment le débit consommé et d'ajuster manuellement la capacité allouée. Auto Scaling permet de garantir la disponibilité des applications et réduit les coûts provenant de capacités allouées non utilisées.

Q : Quels modèles de demande d'application et de charge de travail conviennent à Auto Scaling ?

Les modèles de demande qui conviennent le mieux à Auto Scaling sont uniformes, prévisibles, avec une utilisation de débit élevée et basse durable qui dure de quelques minutes à plusieurs heures.

Q : Comment puis-je activer Auto Scaling pour une table DynamoDB ou pour un index secondaire global ?

Lors de la création d'une nouvelle table depuis la console DynamoDB, laissez l'option « Use default settings » cochée afin d'activer Auto Scaling et d'appliquer les mêmes paramètres pour les index secondaires globaux pour la table. Si vous décochez « Use default settings », vous pouvez soit paramétrer manuellement la capacité allouée, soit activer Auto Scaling avec des valeurs personnalisées pour l'utilisation cible ainsi que pour les capacités minimales et maximales. Pour les tables existantes, vous pouvez activer Auto Scaling ou changer les paramètres Auto Scaling existants en allant dans l'onglet « Capacity ». Pour les index, vous pouvez activer Auto Scaling depuis l'onglet « Indexes ». Auto Scaling peut également être géré par un programme en utilisant l'interface de ligne de commande ou le kit SDK AWS. Pour en savoir plus, consultez le guide du développeur DynamoDB.

Q : Quels sont les paramètres configurables pour Auto Scaling ?

Il existe trois paramètres configurables pour Auto Scaling : l'utilisation cible (le pourcentage à un moment donné du débit consommé réel pour le débit alloué total), la capacité minimale (jusqu'où Auto Scaling peut dimensionner à la baisse) et la capacité maximale (jusqu'où Auto Scaling peut dimensionner à la hausse). Par défaut, la valeur pour l'utilisation cible est 70 % (la plage autorisée s'étend de 20 à 80 % dans des incréments d'un pourcentage), la capacité minimale est fixée à 1 unité et la capacité maximale correspond à la limite de table pour votre compte dans la région. Consultez la page Limites dans DynamoDB pour connaître les limites de table par défaut à l'échelle de la région.

Q : Est-il possible de changer les paramètres d'une politique Auto Scaling existante ?

Oui. Vous pouvez changer les paramètres d'une politique Auto Scaling existante à tout moment. Pour cela, accédez à l'onglet « Capacity » de la console de gestion ou faites-le par programme depuis l'interface de ligne de commande ou le kit SDK en utilisant les API AutoScaling.

Q : Comment fonctionne Auto Scaling ?

Lorsque vous créez une nouvelle politique Auto Scaling pour votre table DynamoDB, les alarmes Amazon CloudWatch sont créées avec des seuils pour l'utilisation cible que vous avez indiquée. Ceux-ci sont calculés par rapport aux métriques de capacité consommées et allouées publiées sur CloudWatch. Si l'utilisation réelle d'une table dévie de l'utilisation cible pendant une certaine période de temps, les alarmes CloudWatch activent Auto Scaling, qui évalue votre politique, puis adresse une demande d'API UpdateTable à DynamoDB afin d'augmenter (ou de diminuer) dynamiquement la capacité de débit alloué, pour que l'utilisation réelle soit plus proche de l'utilisation cible.

Q : Puis-je activer une seule politique Auto Scaling pour plusieurs tables dans plusieurs régions ?

Non. Une politique Auto Scaling peut être paramétrée uniquement pour une table ou un index secondaire global au sein d'une seule région.

Q : Puis-je forcer la politique Auto Scaling à faire une mise à l'échelle instantanée vers sa capacité maximale ou minimale ?


Non. Le dimensionnement instantané vers la capacité maximale ou minimale n'est pas pris en charge. A la place, vous pouvez désactiver temporairement Auto Scaling, paramétrer manuellement la capacité désirée dont vous avez besoin pour la durée requise et réactiver Auto Scaling ultérieurement.

Q : Où puis-je surveiller les actions de dimensionnement déclenchées par Auto Scaling ?

Vous pouvez surveiller les états des actions de dimensionnement déclenchées par Auto Scaling dans l'onglet « Capacity » de la console de gestion et depuis les graphiques CloudWatch dans l'onglet « Metrics ».

Q : Comment puis-je savoir si une table dispose d'une politique Auto Scaling ou non ?

Depuis la console DynamoDB, cliquez sur « Tables » dans le menu de gauche afin de faire apparaître la liste de toutes les tables DynamoDB de votre compte. Pour les tables disposant d'une politique Auto Scaling, la colonne « Auto Scaling » affiche READ_CAPACITY, WRITE_CAPACITY ou READ_AND_WRITE suivant si Auto Scaling est activé pour la lecture, l'écriture ou les deux. De plus, dans la section « Table details » de l'onglet « Overview » d'une table, la section dédiée à la capacité allouée indique si Auto Scaling est activé pour la lecture, l'écriture ou les deux.

Q : Que se passe-t-il au niveau de la politique Auto Scaling si je supprime une table ou un index secondaire global disposant d'une politique active ?

Lorsque vous supprimez une table ou un index secondaire global depuis la console, la politique Auto Scaling associée et les alarmes CloudWatch prises en charge sont également supprimées.

Q : L'utilisation d'Auto Scaling entraîne-t-elle des frais supplémentaires ?

Non. L'utilisation d'Auto Scaling n'entraîne pas de frais supplémentaires par rapport à ce que vous avez déjà payé pour DynamoDB et les alarmes CloudWatch. Pour en savoir plus sur la tarification de DynamoDB, consultez la page de tarification de DynamoDB.

Q : Comment fonctionne la capacité de débit gérée par Auto Scaling avec mes capacités réservées ?

Auto Scaling fonctionne avec les capacités réservées de la même manière que la capacité de débit alloué manuellement. Les capacités réservées sont appliquées au total de la capacité allouée pour la région dans laquelle vous les avez achetées. La capacité allouée par Auto Scaling consomme d'abord les capacités réservées, facturées à prix réduit. Toute capacité supplémentaire est facturée au prix standard. Pour limiter la consommation totale des capacités réservées que vous avez achetées, distribuez la limite de capacité maximale dans toutes les tables avec Auto Scaling activé afin que leur volume cumulé soit inférieur à vos capacités réservées.


Q : Qu'est-ce qu'un index secondaire global ?

Les index secondaires globaux sont des index contenant une partition ou des clés de partition et de tri pouvant être différentes de la clé primaire de la table.

Pour permettre un accès efficace aux données d'une table en particulier, Amazon DynamoDB crée et conserve des index pour les attributs de la clé primaire. Les applications peuvent ainsi accéder rapidement aux données en spécifiant des valeurs pour la clé primaire. Cependant, il serait utile pour de nombreuses applications de disposer d'une ou plusieurs clés secondaires (ou alternatives) permettant un accès efficace aux données présentant d'autres attributs que la clé primaire. Pour ce faire, vous pouvez créer un ou plusieurs index secondaires pour une table, et effectuer des requêtes Query portant sur ces index.

Amazon DynamoDB prend en charge deux types d'index secondaires :

  • Index secondaire local – index possédant la même clé de partition que la table, mais une clé de tri différente. Ce type d'index est appelé « local » car chaque partition de l'index est associée à une partition de la table possédant la même clé de partition.
  • Index secondaire global – index possédant une partition ou une clé de partition et de tri pouvant être différente de celles de la table. Ce type d'index est appelé « global » car les requêtes portant sur l'index peuvent couvrir tous les éléments de la table, sur l'ensemble des partitions. 

Les index secondaires sont automatiquement gérés par Amazon DynamoDB en tant qu'objets non denses. Les entrées apparaissent dans un index uniquement si elles existent dans la table pour laquelle l'index est défini. Les requêtes portant sur un index sont donc particulièrement efficaces, car le nombre d'entrées contenues dans l'index est souvent largement inférieur au nombre d'entrées de la table.

Les index secondaires globaux prennent en charge des attributs non uniques, ce qui permet une plus grande flexibilité au niveau des requêtes dans la mesure où celles-ci peuvent concerner n'importe quel attribut non-clé de la table.

Considérons, par exemple, une application de jeu stockant les informations concernant les joueurs dans une table DynamoDB, dont la clé primaire serait composée des éléments IdUtilisateur (partition) et TitreJeu (tri). Les entrées comportent notamment des attributs appelés MeilleurScore, Date et CodePostal. A la création de la table, DynamoDB fournit un index implicite (index primaire) pour la clé primaire, qui permet d'effectuer des requêtes efficaces renvoyant les meilleurs scores d'un utilisateur donné sur l'ensemble des jeux.

Cependant, si l'application doit accéder aux meilleurs scores des utilisateurs sur un jeu en particulier, cet index primaire ne sera pas suffisant, et il faudra alors procéder à une vérification sur l'ensemble de la table. Cependant, en définissant TitreJeu en tant qu'élément de la clé de partition et MeilleurScore en tant qu'élément de la clé de tri, l'application pourrait rapidement récupérer les meilleurs scores pour un jeu donné.

Il n'est pas obligatoire de définir un élément de clé de tri pour les index secondaires globaux. Par exemple, il serait possible de définir un index secondaire global dont la clé comporterait uniquement l'élément de partition TitreJeu. Dans l'exemple ci-dessus, l'index secondaire global ne comprend pas d'attributs projetés. Il retournera donc toutes les entrées (identifiées par leur clé primaire) dont l'un des attributs correspond à la valeur de TitreJeu faisant l'objet de la requête.

Q : Dans quels cas utiliser un index secondaire global ?

Les index secondaires globaux sont particulièrement indiqués pour suivre les liens entre des attributs présentant de nombreuses valeurs différentes. Par exemple, vous pourriez créer une table DynamoDB dont la clé de partition primaire serait IDClient, possédant un index secondaire global dont la clé de partition serait CodePostal, car il existe de nombreux codes postaux différents et vous avez sans doute de nombreux clients. A l'aide de la clé primaire, vous pourriez rapidement accéder à l'enregistrement de n'importe quel client. L'index secondaire global vous permettrait d'effectuer des requêtes efficaces afin d'identifier tous les clients correspondant à un même code postal.

Pour savoir comment utiliser au mieux les possibilités de votre index secondaire global, consultez notre documentation sur les bonnes pratiques concernant les charges de travail uniformes.

Q : Comment créer un index secondaire global pour une table DynamoDB ?

Les GSI associés à une table peuvent être spécifiés à tout moment. Pour obtenir des informations plus détaillées sur la création des tables et de leurs index, consultez ce document. Vous pouvez créer jusqu'à 5 index secondaires globaux par table.

Q : La version locale de DynamoDB prend-elle en charge les index secondaires globaux ?

Oui. La version locale de DynamoDB est particulièrement utile pour développer et tester des applications s'appuyant sur DynamoDB. Vous pouvez télécharger la version locale de DynamoDB ici.

Q : Que sont les attributs projetés ?

Les données de l'index secondaire sont composées d'attributs projetés (ou copiés) de la table vers l'index. Lorsque vous créez un index secondaire, vous définissez une clé alternative pour celui-ci, ainsi que les autres attributs que vous souhaitez projeter dans l'index. Amazon DynamoDB copie ces attributs dans l'index, ainsi que les attributs de la clé primaire de la table. Vous pouvez, ensuite, effectuer des requêtes portant sur l'index, comme vous le feriez pour une table.

Q : Une clé d'index secondaire global peut-elle être définie sur des attributs non uniques ?

Oui. Contrairement à la clé primaire d'une table, les attributs indexés d'un index secondaire global ne doivent pas nécessairement être uniques. Par exemple, un index secondaire global défini sur TitreJeu pourrait indexer toutes les entrées incluant les scores d'utilisateurs sur chaque jeu. Dans cet exemple, il est possible d'effectuer une requête sur l'index secondaire global pour obtenir la liste de tous les utilisateurs ayant joué au jeu « TicTacToe ».

Q : En quoi les index secondaires globaux sont-ils différents des index secondaires locaux ?

Les deux types d'index permettent une plus grande souplesse dans les requêtes. Un index secondaire local est lié à une valeur de partition spécifique de la clé primaire, tandis qu'un index secondaire global couvre toutes les valeurs de la clé de partition. Dans la mesure où les entrées qui partagent la même clé de partition pour la clé primaire se trouvent dans la même partition dans DynamoDB, l'index secondaire « local » couvre uniquement les entrées stockées ensemble (dans la même partition). Par conséquent, l'index secondaire local sert à effectuer des requêtes sur des entrées qui ont la même valeur de clé de partition pour la clé primaire, mais une clé de tri différente. Par exemple, considérons une table DynamoDB répertoriant des commandes de clients, dont la clé de partition est IdClient.

Un index secondaire local défini sur HeureCommande permet d'effectuer des requêtes efficaces afin de retrouver les derniers articles commandés par un client donné.

Un index secondaire global ne se limite pas aux entrées possédant la même valeur de clé de partition. Au contraire, il couvre tous les items de la table, de la même manière que la clé primaire. Dans le cas de la table décrite ci-dessus, un index secondaire global défini sur IdProduit peut être utilisé pour trouver efficacement toutes les commandes d'un produit donné. Notez que dans ce cas, aucune clé de tri n'est spécifiée pour l'index secondaire global : si plusieurs commandes correspondent au même IdProduit, elles seront stockées en tant qu'entrées séparées dans l'index secondaire global.

Pour permettre l'hébergement partagé des données de la table et de l'index sur la même partition, les index secondaires locaux imposent de limiter la taille totale de l'ensemble des éléments (tables et index) à 10 Go par valeur de clé de partition. Cette limite ne s'applique pas aux index secondaires globaux, qui ne requièrent pas l'hébergement partagé des données.

Lorsque vous écrivez dans une table, DynamoDB met à jour tous les index secondaires locaux concernés de manière atomique. Pour les index secondaires globaux de la table, les mises à jour sont cohérentes à terme.

Les index secondaires locaux permettent d'utiliser l'API Query pour accéder aux attributs ne faisant pas partie de la liste de projection. Ces opérations ne sont pas prises en charge par les index secondaires globaux.

Q : Comment fonctionnent les index secondaires globaux ?

Sur bien des points, le fonctionnement d'un index secondaire global s'apparente à celui d'une table DynamoDB. Vous pouvez effectuer des requêtes sur un index secondaire global en utilisant son élément de clé de partition, avec des filtres conditionnels portant sur son élément de clé d'intervalle. Cependant, contrairement à la clé primaire d'une table DynamoDB, qui doit être unique, une clé d'index secondaire global peut être identique pour plusieurs entrées. S'il existe plusieurs entrées présentant la même clé d'index secondaire global, elles sont enregistrées en tant qu'entrées séparées de cet index, et les requêtes les listeront toutes en tant qu'entrées indépendantes. En interne, DynamoDB assure la mise à jour du contenu des index secondaires globaux au fur et à mesure que des entrées sont ajoutées, supprimées ou actualisées.

DynamoDB stocke les attributs projetés de l'index secondaire global dans sa structure de données, de même que la clé de l'index secondaire global et les clés primaires des entrées correspondantes. Les index secondaires globaux consomment des capacités de stockage pour les entrées projetées existant dans la table source. Ainsi, les requêtes peuvent porter sur l'index secondaire global plutôt que sur la table, ce qui permet une plus grande flexibilité et une répartition optimale de la charge de travail. Les attributs faisant partie d'une entrée de la table mais n'étant pas inclus dans la clé de l'index secondaire global, dans la clé primaire de la table ou dans les attributs projetés ne sont donc pas renvoyés par les requêtes portant sur l'index secondaire global. Si des applications requièrent des données supplémentaires de la table après avoir effectué une requête sur l'index secondaire global, elles peuvent obtenir la clé primaire à partir de l'index secondaire global et utiliser les API GetItem ou BatchGetItem pour accéder aux attributs recherchés dans la table. Dans la mesure où les index secondaires globaux sont cohérents à terme, les applications qui utilisent cette procédure doivent s'adapter aux possibles suppressions d'entrées (d'une table) entre les appels à l'index secondaire global et les opérations GetItem/BatchItem. 

DynamoDB gère automatiquement les ajouts, mises à jour et suppressions d'entrées dans un index secondaire global lorsque ces changements ont été apportés dans la table. Lorsqu'une entrée (possédant des attributs clés dans l'index secondaire global) est ajoutée à la table, DynamoDB met à jour l'index en question de manière asynchrone pour y ajouter la nouvelle entrée. De même, lorsqu'une entrée est supprimée de la table, DynamoDB se charge de sa suppression dans l'index secondaire global concerné.

Q : Est-il possible de créer des index secondaires globaux pour des tables basées sur une fonction de partition ou suivant un schéma partition-tri ?

Oui, vous pouvez créer un index secondaire global quel que soit le type de clé primaire choisi pour la table DynamoDB. La clé primaire de la table peut inclure une clé de partition unique, ou comporter à la fois une clé de partition et une clé de tri.

Q : Quel est le modèle de cohérence des index secondaires globaux ?

Les index secondaires globaux suivent un modèle de cohérence à terme. Lorsque des entrées sont ajoutées ou mises à jour dans une table, les index secondaires globaux ne sont pas actualisés simultanément. Dans des conditions de fonctionnement normales, les changements sont propagés vers les index secondaires globaux en l'espace d'une fraction de seconde. Il arrive, rarement, que des erreurs entraînent des délais plus longs. Par conséquent, la logique de votre application doit être en mesure de traiter des résultats potentiellement obsolètes pour les requêtes sur des index secondaires globaux. Ce comportement est identique à celui des autres API DynamoDB prenant en charge les opérations de lecture cohérentes à terme.

Considérons, par exemple, une table regroupant les meilleurs scores, dans laquelle chaque entrée comprend les attributs IdUtilisateur, TitreJeu et MeilleurScore. La clé de partition est IdUtilisateur, et la clé de tri primaire est TitreJeu. Si l'application ajoute une entrée indiquant un nouveau meilleur score pour le TitreJeu « TicTacToe » et l'IdUtilisateur « GAMER123 », puis effectue une requête sur l'index secondaire global, il est possible que le nouveau score ne figure pas dans les résultats de cette requête. Cependant, une fois que les changements auront été propagés dans l'index secondaire global, la nouvelle entrée apparaîtra dans les requêtes concernant cet index.

Q : Puis-je allouer un débit séparé pour la table et pour chaque index secondaire global ?

Oui. Les index secondaires globaux gèrent leur débit indépendamment de la table à laquelle ils sont associés. Lorsque vous activez Auto Scaling pour une table nouvelle ou existante depuis la console, vous pouvez choisir d'appliquer les mêmes paramètres aux index secondaires globaux. Vous pouvez également allouer manuellement différents débits pour les tables et les index secondaires globaux.

Selon l'application utilisée, la charge de travail liée aux requêtes sur un index secondaire global peut présenter des différences importantes par rapport à celle d'une autre table ou d'autres index secondaires globaux. Voici quelques scénarios pouvant entraîner des différences :

  • Un index secondaire global contenant une petite partie des entrées de la table requiert un débit d'écriture bien moins important que celui de la table.
  • Un index secondaire global utilisé pour des recherches d'entrées peu fréquentes requiert un débit de lecture bien moins important que celui de la table.
  • Un index secondaire global utilisé pour une tâche de fond impliquant de nombreuses opérations de lecture risque de requérir un débit élevé en lecture chaque jour pendant quelques heures.

Vous pouvez modifier le débit alloué à un index secondaire global en fonction de vos besoins, indépendamment du débit alloué à la table.

Considérons une table DynamoDB comprenant un index secondaire global dans lequel tous les attributs sont projetés, et dont 50 % des entrées incluent la clé de l'index secondaire global. Dans ce cas, les unités de capacité en écriture prévues pour l'index secondaire global devraient correspondre à 50 % des unités de capacité en lecture allouées à la table. Le débit en lecture de l'index secondaire global peut être estimé en utilisant un raisonnement similaire. Pour plus de détails, consultez la documentation des index secondaires globaux DynamoDB.

Q : Quelles sont les répercussions de l'ajout d'un index secondaire global sur la table en termes de stockage et de débit alloué ?

Tout comme une table DynamoDB, un index secondaire global utilise une partie du débit alloué lorsque des opérations de lecture ou d'écriture sont effectuées. Une opération d'écriture ajoutant ou mettant à jour une entrée de l'index secondaire global consomme des unités de capacité en écriture en fonction de la taille de la mise à jour. Les capacités consommées pour l'écriture dans l'index secondaire global viennent s'ajouter à celles requises pour mettre à jour l'objet dans la table.

Notez que si vous ajoutez, supprimez ou mettez à jour une entrée dans une table DynamoDB, et qu'aucun changement n'est propagé dans l'index secondaire global, celui-ci ne consommera aucune unité de capacité en écriture. Ce cas de figure se produit lorsqu'une entrée ne comportant aucun des attributs clés de l'index secondaire global est ajoutée à la table DynamoDB, ou lorsqu'une entrée est mise à jour sans que la clé ni les attributs projetés de l'index secondaire global ne soient modifiés.

Toute requête interrogeant un index secondaire global consomme des unités de capacité en lecture, dépendant de la taille des entrées examinées par la requête.

Les coûts de stockage de l'index secondaire global sont calculés en fonction du nombre total d'octets stockés dans cet index. Cela inclut notamment la clé de l'index secondaire global, les attributs et valeurs projetés, ainsi qu'un supplément de 100 octets destinés à l'indexation.

Q : Est-il possible que DynamoDB restreigne les opérations d'écriture de mon application dans une table en raison du débit réservé pour un index secondaire global ?

Dans la mesure où tout ou partie des opérations d'écriture dans une table DynamoDB sont propagées dans les index secondaires globaux associés, il est possible que le débit alloué à un index secondaire global soit épuisé. Dans un tel cas, les opérations d'écriture ultérieures dans la table seront restreintes. Cette restriction peut être appliquée même si la table dispose d'unités de capacité en écriture.

Q : A quelle fréquence puis-je modifier le débit alloué au niveau des index ?

Les tables comportant des index secondaires globaux sont soumises aux mêmes limites quotidiennes que les autres tables en matière d'opérations de modification de débit.

Q : Quel est le système de facturation des index secondaires globaux DynamoDB ?

L'ensemble du débit alloué pour la table et ses index secondaires globaux est facturé à l'heure. Lorsque l'allocation est manuelle, l'ensemble du débit alloué pour la table et ses index secondaires globaux est facturé à l'heure sans que cela soit obligatoire. Par ailleurs, des frais sont appliqués pour le stockage des données de l'index secondaire global, ainsi que pour les transferts de données standard (externes). Si vous souhaitez changer la capacité de débit alloué de votre index secondaire global, vous pouvez le faire en utilisant la console DynamoDB, l'API UpdateTable ou l'API PutScalingPolicy pour mettre à jour les paramètres de la politique d'Auto Scaling.

Q : Puis-je désigner l'index secondaire global à utiliser pour une requête ?

Oui. Outre les paramètres de requête habituels, la commande Query d'un index secondaire global inclut explicitement le nom de l'index à interroger. La requête Query ne peut porter que sur un seul index secondaire global.

Q : Quelles sont les API prises en charge par les index secondaires globaux ?

Les appels d'API pris en charge par les index secondaires globaux sont Query et Scan. Une opération Query recherche uniquement les valeurs de l'attribut clé de l'index et permet d'utiliser un sous-ensemble d'opérateurs de comparaison. Dans la mesure où les index secondaires globaux sont mis à jour de manière asynchrone, vous ne pouvez pas utiliser le paramètre ConsistentRead pour cette requête. Consultez cette page pour en savoir plus sur l'utilisation des opérations d'interrogation (Query) et d'analyse (Scan) avec les index secondaires globaux.

Q : Quel est l'ordre des résultats de l'analyse sur un index secondaire global ?

Pour un index secondaire global avec un schéma de clé de partition uniquement, il n'y pas de classement. Pour un index secondaire global avec un schéma de clé de partition-tri, le classement des résultats pour une même clé de partition est basé sur l'attribut de la clé de tri.

Q : Puis-je modifier des index secondaires globaux une fois qu'une table a été créée ?

Oui. Les index secondaires globaux peuvent être modifiés à tout moment, même si la table a déjà été créée.

Q : Comment puis-je ajouter un index secondaire global à une table existante ?

Vous pouvez ajouter un index secondaire global à l'aide de la console ou par le biais d'un appel d'API. Dans la console DynamoDB, commencez par sélectionner la table à laquelle vous souhaitez ajouter un index secondaire global, puis cliquez sur le bouton « Create Index » pour ajouter un nouvel index. Suivez les étapes de l'assistant de création d'index et sélectionnez « Create » lorsque vous avez terminé. Vous pouvez également ajouter ou supprimer un index secondaire global en appelant l'API UpdateTable avec le paramètre GlobalSecondaryIndexes. Pour en savoir plus, consultez notre page de documentation.

Q : Comment puis-je supprimer un index secondaire global ?

Vous pouvez supprimer des index secondaires globaux à partir de la console ou par le biais d'un appel d'API. Dans la console DynamoDB, sélectionnez la table dans laquelle vous souhaitez supprimer un index secondaire global. Sélectionnez ensuite l'onglet « Indexes » sous « Table Items », puis cliquez sur le bouton « Delete » pour supprimer l'index. Vous pouvez également supprimer un index secondaire global en appelant l'API UpdateTable. Pour en savoir plus, consultez notre page de documentation.

Q : Puis-je ajouter ou supprimer plus d'un index en un seul appel d'API dans la même table ?

Vous ne pouvez ajouter ou supprimer qu'un seul index par appel d'API.

Q : Que se passe-t-il si je soumets plusieurs requêtes pour ajouter le même index ?

Seule la première requête d'ajout est acceptée. Toutes les requêtes d'ajout suivantes échoueront jusqu'à ce que la première requête d'ajout soit terminée.

Q : Puis-je ajouter ou supprimer plusieurs index simultanément dans la même table ?

Non. Il ne peut y avoir qu'une seule opération d'ajout ou de suppression d'index active à la fois dans une table.

Q : Dois-je allouer du débit supplémentaire pour ajouter un nouvel index secondaire global ?

Avec Auto Scaling, il vous est recommandé d'appliquer les mêmes paramètres pour l'index secondaire global comme pour la table. Lorsque vous réalisez manuellement l'allocation, bien que cela ne soit pas requis, nous vous recommandons fortement d'allouer du débit d'écriture supplémentaire séparé du débit prévu pour l'index. Si vous n'allouez pas de débit d'écriture supplémentaire, le débit d'écriture de l'index sera consommé lors de l'ajout du nouvel index. Cela aura un impact sur les performances d'écriture de l'index lorsque ce dernier sera en cours de création, et allongera le temps nécessaire pour créer le nouvel index.

Q : Dois-je réduire le débit supplémentaire alloué à un index secondaire global une fois que l'index a été créé ?

Oui. Une fois le processus terminé, vous devriez réduire le débit d'écriture supplémentaire que vous avez alloué pour l'ajout d'un index.

Q : Puis-je modifier le débit d'écriture qui est alloué pour l'ajout d'un index secondaire global ?

Oui. Vous pouvez augmenter ou réduire le débit d'écriture alloué pour la création de l'index à tout moment lors du processus de création.

Q : Lorsqu'un index secondaire global est en cours d'ajout ou de suppression, la table est-elle toujours disponible ?

Oui. La table est disponible lorsque l'index secondaire global est en cours de mise à jour.

Q : Lorsqu'un index secondaire global est en cours d'ajout ou de suppression, les index existants sont-ils toujours disponibles ?

Oui. Les index existants sont disponibles lorsque l'index secondaire global est en cours de mise à jour.

Q : Lorsqu'un index secondaire global est en cours de création, le nouvel index est-il disponible ?

Non. Le nouvel index n'est disponible qu'une fois le processus de création de l'index terminé.

Q : Combien de temps faut-il pour ajouter un index secondaire global ?

La durée nécessaire dépend de la taille de la table et du montant de débit d'écriture supplémentaire alloué pour la création de l'index secondaire global. Le processus d'ajout ou de suppression d'index peut varier de quelques minutes à plusieurs heures. Par exemple, imaginons que vous disposez d'une table de 1 Go dotée de 500 unités de capacité d'écriture et que vous avez alloué 1 000 unités de capacité d'écriture pour l'index et la création du nouvel index. Si le nouvel index inclut tous les attributs dans la table et que la table utilise toutes les unités de capacité d'écriture, nous estimons que la création de l'index prendra approximativement 30 minutes.

Q : Combien de temps faut-il pour supprimer un index secondaire global ?

La suppression d'un index se fait généralement en quelques minutes. Par exemple, supprimer un index contenant 1 Go de données prendra généralement moins d'une minute.

Q : Comment puis-je suivre la progression de l'opération d'ajout ou de suppression d'un index secondaire global ?

Vous pouvez utiliser la console DynamoDB ou l'API DescribeTable pour afficher le statut de tous les index associés à la table. Pendant que l'index est créé lors d'une opération d'ajout d'index, son statut sera « CREATING ». Une fois la création de l'index terminée, l'état de l'index passera de « CREATING » à « ACTIVE ». Pour une opération de suppression d'index, une fois la requête terminée, l'index supprimé aura disparu.

Q : Puis-je obtenir une notification lorsque le processus de création d'index pour l'ajout d'un index secondaire global est terminé ?

Vous pouvez demander qu'une notification confirmant que l'ajout de l'index a bien été effectué vous soit envoyée à votre adresse e-mail. Lorsque vous ajoutez un index par le biais de la console, vous pouvez demander une notification lors de la dernière étape avant la création de l'index. Lorsque la création de l'index est terminée, DynamoDB envoie alors une notification SNS à votre adresse e-mail.

Q : Que se passe-t-il si j'essaie d'ajouter d'autres index secondaires globaux alors que j'en ai déjà 5 ?

La limitation actuelle est de 5 GSI. L'opération « Add » échouera et vous obtiendrez une erreur.

Q : Puis-je réutiliser un nom pour un index secondaire global après avoir supprimé un index du même nom ?

Oui. Une fois qu'un index secondaire global a été supprimé, le nom de cet index peut être utilisé à nouveau lors de l'ajout d'un nouvel index.

Q : Puis-je annuler l'ajout d'un index lors de sa création ?

Non. Une fois que la création d'index démarre, le processus ne peut être annulé.

Q : Les attributs clés de l'index secondaire global sont-ils obligatoires pour toutes les entrées de la table DynamoDB ?

Non. Les index secondaires globaux sont des index non denses. Chaque entrée d'une table DynamoDB doit avoir une clé primaire, mais il n'est pas nécessaire qu'elle inclue les clés des index secondaires globaux. Si une clé d'index secondaire global contient à la fois des éléments de partition et de tri, et qu'une entrée de la table ne contient aucun de ces éléments, alors cette entrée ne sera pas indexée par l'index correspondant. Par conséquent, un index secondaire global peut s'avérer très utile pour identifier efficacement les entrées qui possèdent des attributs peu fréquents.

Q : Puis-je accéder à tous les attributs d'une table DynamoDB à partir d'un index secondaire global ?

Une requête portant sur un index secondaire global peut uniquement renvoyer les attributs inclus dans cet index à la création de la table. Les attributs inclus dans l'index secondaire global sont ceux qui sont projetés par défaut, comme les attributs clés de l'index et les attributs de clé primaire de la table, ainsi que les attributs définis par l'utilisateur pour la projection. Une requête effectuée sur un index secondaire global ne renverra donc pas les attributs des entrées faisant partie de la table mais qui ne sont pas incluses dans l'index. Si un index secondaire global spécifie tous les attributs en tant qu'attributs projetés, il peut être utilisé pour accéder à n'importe quel attribut de la table. Cliquez ici pour consulter la documentation sur l'utilisation des index secondaires globaux à des fins de requêtes.

Q : Comment afficher la liste des index secondaires globaux associés à une table ?

Vous pouvez utiliser l'API DescribeTable pour obtenir des informations détaillées sur les index secondaires globaux de la table.

Q : Quels sont les types de données pouvant être indexés ?

Toutes les données de type scalaire (nombre, chaîne, binaire et boléen) peuvent être utilisées pour l'élément de clé de tri de la clé de l'index secondaire local. Les types d'ensembles, de listes et de cartes ne peuvent pas être indexés.

Q : Est-il possible de créer des index à partir d'attributs composés ?

Non. Vous pouvez, néanmoins, concaténer les attributs dans une même chaîne, et utiliser celle-ci en tant que clé.

Q : Quels sont les types de données pouvant être inclus dans les attributs projetés d'un index secondaire global ?

Vous pouvez projeter des attributs correspondant à tous les types de données (y compris les données de type fixe) vers votre index secondaire global.

Q : Quels sont les points à prendre en compte pour assurer l'évolutivité des index secondaires globaux ?

Les recommandations concernant les performances des clés primaires de tables DynamoDB sont également valables pour les clés d'index secondaires globaux. Le modèle d'accès aux clés des index secondaires globaux est relativement aléatoire. Pour exploiter au mieux le débit alloué à l'index secondaire, il est recommandé de sélectionner un attribut de clé de partition possédant un grand nombre de valeurs distinctes pour l'index secondaire global, et un attribut de clé de tri faisant l'objet de demandes relativement uniformes, et ce, de manière aussi aléatoire que possible.

Q : Quelles nouvelles mesures CloudWatch seront mises à disposition pour les index secondaires globaux ?

Des mesures globales seront disponibles pour les tables comportant des index secondaires globaux, ainsi que des mesures détaillées distinguant la table et chaque index secondaire.

Les rapports concernant chaque index secondaire global incluront un sous-ensemble des mesures CloudWatch s'appliquant aux tables, parmi lesquels :

  • Capacité en lecture (capacité en lecture allouée, capacité en lecture consommée)
  • Capacité en écriture (capacité en écriture allouée, capacité en écriture consommée)
  • Opérations de lecture ayant subi des restrictions
  • Opérations d'écriture ayant subi des restrictions

Pour plus d'informations sur les mesures concernant les tables et index DynamoDB, consultez cette page.

Q : Comment puis-je analyser un index secondaire global ?

Les index secondaires globaux peuvent être analysés via la console ou l'API Scan.

Pour analyser un index secondaire global, ajoutez une référence explicite à l'index en plus du nom de la table à analyser. Vous devez indiquer le nom et la valeur de l'attribut de partition de l'index. Vous pouvez, éventuellement, définir une condition pour l'attribut de tri de la clé de l'index.

Q : Une analyse d'un index secondaire global permet-elle de spécifier le renvoi des attributs non projetés dans les résultats ?

L'analyse des index secondaires globaux ne prend pas en charge l'extraction des attributs non projetés.

Q : Une analyse parallèle sera-t-elle prise en charge pour les index ?

Oui, une analyse parallèle sera prise en charge pour les index, et la sémantique sera identique que pour la table principale.


Q : Qu'est-ce qu'un index secondaire local ?

Les index secondaires locaux permettent d'exécuter de manière plus rapide et plus efficace certaines requêtes courantes, qui nécessiteraient autrement d'extraire un grand nombre d'éléments, puis de filtrer les résultats. Vos applications peuvent donc s'appuyer sur des requêtes plus souples, reposant sur une base plus large d'attributs.

Avant le lancement des index secondaires locaux, lorsque vous recherchiez des éléments spécifiques au sein d'une partition (éléments partageant la même clé de partition), DynamoDB récupérait tous les objets partageant une même clé de partition avant de filtrer les résultats en conséquence. Imaginons par exemple une application de e-commerce stockant les données concernant les commandes des clients dans une table DynamoDB, avec le schéma partition-tri suivant : id client-horodatage commande. Sans index secondaire local, pour répondre à la question « Afficher toutes les commandes du client X sur les 30 derniers jours, avec leur date d'expédition et triées par date d'expédition », il fallait utiliser l'API Query pour extraire tous les objets sous la clé de partition « X », trier les résultats par date d'expédition, puis éliminer les enregistrements plus anciens par filtrage.

Avec les index secondaires locaux, cette expérience devient beaucoup plus simple. Vous pouvez maintenant créer un index sur l'attribut « date d'expédition » et exécuter cette requête efficacement, en n'extrayant que les éléments nécessaires. Cela permet de diminuer significativement la latence et le coût de vos requêtes, car seuls les éléments correspondant à vos critères spécifiques sont extraits. Le modèle de programmation en sera également simplifié puisque vous n'aurez plus à écrire la logique du client pour filtrer les résultats. Nous considérons que ce nouvel index secondaire fonctionne de manière « locale » dans la mesure où il est utilisé avec la clé de partition, et vous permet donc d'effectuer des recherches locales au sein d'un bucket (compartiment) de clé de partition. Jusqu'à maintenant, vous pouviez uniquement effectuer une recherche avec la clé de partition et la clé de tri. A présent, vous pouvez aussi utiliser un index secondaire en remplacement de la clé de tri, ce qui augmente également le nombre d'attributs utilisables pour procéder à des requêtes efficaces.

Des copies redondantes des attributs de données sont copiées dans les index secondaires locaux définis. Ces attributs incluent les clés de partition et de tri de la table, ainsi que la clé de tri alternative que vous avez définie. Vous pouvez également stocker de manière redondante d'autres attributs de données dans l'index secondaire local, afin de pouvoir accéder à ces attributs sans passer par la table elle-même.

Les index secondaires locaux ne sont pas adaptés à toutes les applications. Ils entraînent notamment des contraintes en termes de volume de données pouvant être stocké dans une unique valeur de clé de partition. Pour en savoir plus, consultez les questions ci-dessous concernant les collections d'éléments.

Q : Qu'est-ce qu'une projection ?

L'ensemble d'attributs copié vers un index secondaire local est appelé projection. La projection détermine les attributs que vous pourrez extraire avec le plus d'efficacité. Lorsque vous interrogez un index secondaire local, Amazon DynamoDB peut accéder à tous les attributs de la projection avec le même niveau de performances que si ces attributs se trouvaient dans une table dédiée. Si vous devez extraire des attributs ne faisant pas partie de la projection, Amazon DynamoDB les récupère automatiquement dans la table.

Lorsque vous définissez un index secondaire local, vous devez indiquer quels attributs feront l'objet d'une projection dans l'index. Chaque entrée de l'index doit comporter au minimum les éléments suivants : (1) la valeur de la clé de partition de la table, (2) un attribut qui servira de clé de tri de l'index et (3) la valeur de la clé de tri de la table.

En plus de ces informations, vous pouvez aussi définir une liste personnalisée d'attributs supplémentaires non clés à projeter dans l'index. Vous pouvez même choisir de projeter tous les attributs dans l'index, auquel cas l'index comprend les mêmes données que la table elle-même, mais organisées selon la clé de tri alternative que vous aurez indiquée.

Q : Comment puis-je créer un index secondaire local ?

Vous devez créer l'index secondaire local au moment de créer votre table. Il est actuellement impossible d'en ajouter un par la suite. Pour créer un index secondaire local, définissez les deux paramètres suivants :

Clé de tri indexée – l'attribut qui sera indexé et fera l'objet de requêtes.

Attributs projetés – la liste des attributs de la table qui seront copiés directement dans l'index secondaire local, afin qu'ils puissent être renvoyés plus rapidement sans qu'il y ait besoin de récupérer des données dans l'index primaire, qui contient tous les éléments de la table. En l'absence d'attributs projetés, l'index secondaire local contient uniquement les clés primaires et secondaires de l'index.

Q : Quel est le modèle de cohérence pour les index secondaires locaux ?

Les index secondaires locaux sont mis à jour automatiquement à chaque mise à jour de l'index primaire. Comme les index primaires, les index secondaires locaux proposent deux options de cohérence de lecture : la cohérence à terme et la cohérence forte.

Q : Les index secondaires locaux contiennent-ils des références à tous les éléments de la table ?

Non, pas nécessairement. Les index secondaires locaux ne référencent que les éléments contenant la clé de tri indexée de cet index secondaire. Avec le schéma flexible de DynamoDB, il n'est pas nécessaire que tous les éléments contiennent tous les attributs.

Les index secondaires locaux peuvent donc contenir relativement peu d'éléments par rapport à l'index primaire. Dans la mesure où les index secondaires locaux contiennent moins de données, ils sont particulièrement efficaces pour les requêtes concernant des attributs peu courants.

Par exemple, dans l'exemple des commandes décrit plus haut, il se peut qu'un client possède des attributs supplémentaires pour certains éléments, présents uniquement en cas d'annulation de la commande (comme AnnulationDateHeure, AnnulationMotif). Pour les requêtes concernant les éléments annulés, il serait particulièrement efficace de disposer d'un index secondaire local sur l'un de ces attributs : ainsi, les seuls éléments référencés dans l'index seraient ceux qui possèdent ces attributs.

Q : Comment puis-je interroger un index secondaire local ?

Les index secondaires locaux peuvent uniquement être interrogés via l'API Query.

Pour interroger un index secondaire local, ajoutez une référence explicite à l'index en plus du nom de la table à interroger. Vous devez indiquer le nom et la valeur de l'attribut de partition de l'index. Vous pouvez, éventuellement, définir une condition pour l'attribut de tri de la clé de l'index.

Votre requête peut extraire des attributs ne faisant pas partie de la projection et se trouvant donc dans l'index primaire via une opération d'extraction dans la table, moyennant des frais pour les unités de capacité de lecture supplémentaires.

Les deux options de lecture (cohérence à terme et cohérence forte) sont prises en charge dans le cadre de requêtes utilisant un index secondaire local.

Q : Comment puis-je créer un index secondaire local ?

Les index secondaires locaux doivent être définis au moment de la création de la table. L'index primaire de la table doit utiliser une clé composite de type partition-tri.

Q : Puis-je ajouter des index secondaires locaux à une table existante ?

Non, il est actuellement impossible d'ajouter des index secondaires locaux à des tables existantes. Cette fonctionnalité est en cours de développement et sera disponible à l'avenir. Lorsque vous créez une table avec un index secondaire local, vous pouvez choisir de créer cet index pour une utilisation future en définissant un élément de clé de tri n'étant pas utilisé à ce moment. Dans la mesure où l'index secondaire local ne contient que peu de données, il n'entraîne aucun coût jusqu'à ce que vous commenciez à l'utiliser.

Q : Combien d'index secondaires locaux puis-je créer pour une même table ?

Chaque table peut comporter jusqu'à cinq index secondaires locaux.

Q : Combien d'attributs projetés non clés puis-je créer pour une même table ?

Chaque table peut comporter jusqu'à 20 attributs projetés non clés au total sur l'ensemble des index secondaires locaux de la table. Chaque index peut également spécifier une projection de tous les attributs non clés de l'index primaire.

Q : Puis-je modifier l'index après sa création ?

Non, une fois créé, un index ne peut plus être modifié. Cette fonctionnalité devrait être rendue disponible à l'avenir.

Q : Puis-je supprimer des index secondaires locaux ?

Non, il est actuellement impossible de supprimer les index secondaires locaux d'une table. Il sont cependant supprimés si vous décidez de supprimer la table entière. Cette fonctionnalité est en cours de développement et sera disponible à l'avenir.

Q : Quelle est la consommation des index secondaires locaux en matière de capacité allouée ?

Il est inutile de mettre en service des capacités spécifiques pour un index secondaire local. Sa consommation est intégrée à la consommation de capacité mise en service de la table à laquelle il est associé.

La lecture à partir des index secondaires locaux et l'écriture dans les tables avec des index secondaires locaux consomment tous deux de la capacité selon la formule standard d'1 unité par Ko de données, avec les différences suivantes :

Lorsque les opérations d'écriture contiennent des données liées à un ou plusieurs index secondaires locaux, ces écritures sont mises en miroir sur les index secondaires locaux appropriés. Dans de tels cas, la capacité d'écriture est décomptée pour la table elle-même, et des capacités d'écriture supplémentaires sont utilisées pour chaque index supplémentaire local concerné.

Les mises à jour remplaçant un élément existant peuvent impliquer deux opérations (suppression et insertion) et donc consommer des unités de capacité d'écriture supplémentaires pour chaque Ko de données.

Lorsqu'une requête de lecture nécessite des attributs n'ayant pas été projetés dans l'index secondaire local, DynamoDB extrait ces attributs de l'index primaire. Cette utilisation d'une requête GetItem implicite consomme une unité de capacité de lecture par tranche de 4 Ko de données d'élément extraits.

Q : Quelle est la capacité de stockage utilisée par les index secondaires locaux ?

Les index secondaires locaux utilisent des capacités de stockage pour les noms et valeurs d'attributs de chaque clé primaire et d'index de l'index secondaire local, pour tous les attributs projetés non clés, ainsi que 100 octets par élément reflété dans l'index secondaire local.

Q : Quels sont les types de données pouvant être indexés ?

Toutes les données de type scalaire (nombre, chaîne, binaire) peuvent être utilisées pour l'élément de clé de tri de la clé de l'index secondaire local. Les données de type fixe ne peuvent pas être utilisées.

Q : Quels sont les types de données pouvant faire l'objet d'une projection dans un index secondaire local ?

Tous les types de données (y compris le type fixe) peuvent faire l'objet d'une projection dans un index secondaire local.

Q : Que sont les collections d'éléments et quelle est leur relation avec les index secondaires locaux ?

Dans Amazon DynamoDB, le terme « collection d'éléments » désigne tout groupe d'éléments possédant la même clé de partition au sein d'une table et de l'ensemble de ses index secondaires locaux. Dans les systèmes de bases de données relationnelles partitionnées (ou shardées) classiques, le terme équivalent serait partition, qui désigne l'ensemble des éléments ou lignes de la base de données stockés sous une même clé de partition.

Les collections d'éléments sont créées et gérées automatiquement pour chaque table comportant des index secondaires locaux. DynamoDB stocke chaque collection d'éléments dans une partition de disque unique.

Q : Existe-t-il des limites concernant la taille d'une collection d'éléments ?

Dans Amazon DynamoDB, la taille limite pour une collection d'éléments est de 10 gigaoctets. Pour toute valeur de clé de partition distincte, la taille totale des éléments de la table ajoutée à la taille totale des éléments contenus dans les index secondaires locaux de cette table ne doit pas dépasser 10 Go.

Cette limite de 10 Go ne s'applique pas aux tables ne comprenant pas d'index secondaires locaux, elle concerne uniquement les tables comportant au moins un index secondaire local.

Bien que chaque collection d'éléments soit soumise à une limite de taille, la taille de stockage allouée à l'ensemble de la table et de ses index secondaires locaux n'est pas limitée. En pratique, la taille totale d'une table indexée dans Amazon DynamoDB n'est soumise à aucune limite, à condition que la taille de stockage totale (table et index) pour chaque valeur clé de partition ne dépasse pas 10 Go.

Q : Comment puis-je contrôler la taille d'une collection d'éléments ?

Les API d'écriture de DynamoDB (PutItem, UpdateItem, DeleteItem et BatchWriteItem) comportent une option permettant d'inclure une estimation de la taille de la collection d'éléments concernée dans la réponse de l'API. Cette estimation inclut les estimations basse et haute du volume de données pour une collection d'éléments spécifique, mesurées en gigaoctets.

Nous vous recommandons d'équiper votre application de sorte qu'elle surveille la taille de vos collections d'éléments. Vos applications doivent alors examiner les réponses d'API concernant la taille des collections et enregistrer un message d'erreur à chaque fois qu'une collection d'éléments dépasse la limite de taille définie par l'utilisateur (par exemple, 8 Go). Vous disposez ainsi d'un système d'avertissement anticipé qui vous permet d'être informé lorsque la taille d'une collection d'éléments augmente et vous laisse suffisamment de temps pour y remédier.

Q : Que se passe-t-il si une collection d'éléments dépasse la taille limite de 10 Go ?

Si une collection d'éléments dépasse la limite de 10 Go, vous ne pourrez plus procéder à l'écriture de nouveaux éléments, ou augmenter la taille d'éléments existants pour la clé de partition concernée. Les opérations de lecture et d'écriture permettant de diminuer la taille de la collection d'éléments restent autorisées. Cette situation n'a aucune répercussion sur les autres collections d'éléments de la table.

Pour résoudre ce problème, vous pouvez supprimer des éléments ou réduire leur taille dans la collection concernée. Vous avez également la possibilité d'intégrer les nouveaux éléments sous une nouvelle valeur de clé de partition afin de contourner le problème. Si votre table comprend des données d'historique rarement consultées, vous pouvez envisager d'archiver ces données via Amazon S3, Amazon Glacier ou une autre solution de stockage des données.

Q : Comment puis-je analyser un index secondaire local ?

Pour analyser un index secondaire local, ajoutez une référence explicite à l'index en plus du nom de la table à analyser. Vous devez indiquer le nom et la valeur de l'attribut de partition de l'index. Vous pouvez, éventuellement, définir une condition pour l'attribut de tri de la clé de l'index.

Votre analyse peut extraire des attributs ne faisant pas partie de la projection et se trouvant donc dans l'index primaire via une opération d'extraction dans la table, moyennant des frais pour les unités de capacité de lecture supplémentaires.

Q : Une analyse d'un index secondaire local permet-elle de spécifier le renvoi des attributs non projetés dans les résultats ?

L'analyse des index secondaires locaux prend en charge l'extraction des attributs non projetés.

Q : Quel est l'ordre des résultats d'une analyse sur un index secondaire local ?

Pour les index secondaires locaux, le classement au sein d'une collection est basé sur l'ordre de l'attribut indexé.


Q : Qu'est-ce que la fonction de contrôle précis des accès DynamoDB ?

La fonction de contrôle précis des accès (FGAC, Fine Grained Access Control) permet au propriétaire d'une table DynamoDB de disposer d'un niveau de contrôle élevé sur les données de cette table. Le propriétaire peut, notamment, indiquer qui (who) peut accéder à quels (which) éléments ou attributs de la table et quelles (what) actions (en lecture/écriture) cet utilisateur peut effectuer. La fonction FGAC s'utilise conjointement à AWS Identity and Access Management (IAM), qui gère les identifiants de sécurité et les autorisations qui leur sont associées.

Q : Quels sont les cas d'utilisation courants de la fonction FGAC pour DynamoDB ?

La fonction FGAC est particulièrement adaptée aux applications de suivi des informations d'une table DynamoDB, lorsque l'utilisateur final (ou toute application client agissant pour le compte d'un utilisateur final) souhaite lire ou modifier la table directement, sans passer par un service intermédiaire. Par exemple, si vous avez développé une application mobile appelée Acme, vous pouvez utiliser FGAC pour assurer le suivi du meilleur score de chaque utilisateur Acme dans une table DynamoDB. Avec FGAC, le client de l'application peut uniquement modifier le meilleur score de l'utilisateur exécutant actuellement l'application.

Q : Puis-je utiliser la fonction de contrôle précis des accès avec les documents JSON ?

Oui. Vous pouvez utiliser le contrôle précis des accès (FGAC, Fine Grained Access Control) pour limiter l'accès à vos données sur la base des attributs de premier niveau de votre document. Vous ne pouvez pas utiliser la fonction FGAC pour limiter l'accès sur la base d'attributs imbriqués. Imaginons par exemple que vous avez stocké un document JSON contenant les informations suivantes sur une personne : ID, prénom, nom et une liste de tous ses amis. Vous pouvez utiliser le contrôle précis des accès pour limiter l'accès selon l'ID, le prénom ou le nom de la personne, mais pas selon sa liste d'amis.

Q : Comment les développeurs peuvent-ils assurer un contrôle d'accès au niveau élément sans utiliser FGAC ?

Pour parvenir à ce niveau de contrôle sans FGAC, les développeurs doivent opter pour une des autres méthodes existantes, qui peuvent s'avérer très coûteuses. En voici quelques exemples :

  1. Proxy : Le client de l'application envoie une demande à un proxy intermédiaire qui se charge d'authentifier et d'autoriser l'accès. Une telle solution rend l'architecture système plus complexe, et peut accroître le coût total de possession (TCO).
  2. Table par client : Chaque client d'application possède sa propre table. Dans la mesure où les clients d'application accèdent à des tables différentes, ils sont protégés les uns des autres. Cette méthode peut nécessiter de créer des millions de tables, ce qui rend la gestion des bases de données extrêmement difficile pour le développeur.
  3. Jeton intégré pour chaque client : Un jeton secret est intégré au client d'application. L'inconvénient de cette solution est qu'il est difficile de modifier le jeton et de gérer ses effets sur les données stockées. Dans ce cas, la clé des éléments accessibles par ce client doit contenir le jeton secret.

Q : Comment fonctionne la fonction FGAC pour DynamoDB ?

Avec FGAC, une application demande un jeton de sécurité l'autorisant à accéder uniquement à certains éléments d'une table DynamoDB donnée. Grâce à ce jeton, l'agent de l'application utilisateur peut envoyer des demandes directement à DynamoDB. A la réception de la demande, les informations d'identification sont d'abord examinées par DynamoDB, lequel s'appuie sur IAM pour authentifier la demande et déterminer les ressources auxquelles l'utilisateur peut accéder. Si la demande de l'utilisateur est refusée, FGAC empêche l'accès aux données.

Q : Quel est le coût de la fonction FGAC pour DynamoDB ?

Il n'y a pas frais supplémentaires pour FGAC. Comme pour les autres services, vous payez uniquement le débit réservé et les capacités de stockage nécessaires à la table DynamoDB.

Q : Comment bénéficier du service ?

Consultez la section Fine-Grained Access Control du guide du développeur DynamoDB pour savoir comment créer une politique d'accès et un rôle IAM pour votre application (par exemple, un rôle appelé AcmeFacebookUsers pour un app_id Facebook de 34567), et attribuer la politique au rôle créé. La politique de confiance du rôle définit les fournisseurs d'identité acceptés (ex. : connexion avec Amazon, Facebook ou Google) et la politique d'accès indique les ressources AWS accessibles (ex. : une table DynamoDB). Avec ce rôle, votre application peut alors obtenir des identifiants temporaires pour DynamoDB en appelant l'API AssumeRoleWithIdentityRequest d'AWS Security Token Service (STS).

Q : Comment autoriser mes utilisateurs à interroger un index secondaire local, tout en les empêchant de déclencher une extraction de table qui permettrait de récupérer des attributs non projetés ?

Certaines opérations d'interrogation « Query » sur les index secondaires locaux peuvent s'avérer plus coûteuses que d'autres si elles font appel à des attributs qui n'ont pas été projetés dans un index. Vous pouvez réduire le risque de telles opérations de récupération potentiellement coûteuses, en limitant les autorisations aux attributs projetés. Pour ce faire, utilisez la clé contextuelle « dynamodb:Attributes ».

Q : Comment empêcher les utilisateurs d'accéder à certains attributs ?

Pour éviter l'accès à certains attributs en particulier, il est recommandé de suivre le principe du moindre privilège, en autorisant l'accès uniquement à des attributs spécifiques.

Vous avez également la possibilité d'utiliser une politique de refus (Deny) pour cibler les attributs auxquels l'utilisateur n'est pas autorisé à accéder. Cependant, cette méthode est déconseillée pour les raisons suivantes :

  1. Avec une politique Deny , l'utilisateur peut découvrir les noms des attributs masqués en envoyant à plusieurs reprises des demandes pour tous les noms d'attributs possibles, jusqu'à ce que l'accès lui soit refusé.
  2. Les politiques Deny sont plus vulnérables, car il est possible que DynamoDB en vienne à intégrer de nouvelles fonctions d'API, lesquelles pourraient permettre de nouveaux modes d'accès contournant ceux que vous aviez prévu de bloquer.

Q : Comment empêcher les utilisateurs d'ajouter des données incorrectes à une table ?

Les options de contrôle FGAC disponibles indiquent quels contenus et quels attributs peuvent être lus ou modifiés. Les utilisateurs peuvent ajouter de nouveaux éléments ne dépendant pas de ces attributs bloqués, et agir sur les valeurs de tous les attributs modifiables.

Q : Est-il possible d'accorder l'accès à plusieurs attributs sans en faire la liste exhaustive ?

Oui. Le langage des politiques IAM prend en charge un vaste ensemble d'opérations de comparaison, notamment StringLike et StringNotLike.  Pour en savoir plus, consultez la page IAM Policy Reference

Q : Comment créer une politique adaptée ?

Nous vous conseillons d'utiliser le générateur de politiques DynamoDB disponible dans la console DynamoDB. Vous pouvez également comparer votre politique à celles figurant dans le guide du développeur Amazon DynamoDB pour vous assurer qu'elle respecte bien les modèles recommandés. Enfin, vous pouvez publier des politiques sur les forums AWS pour connaître l'avis des membres de la communauté DynamoDB.

Q : Puis-je accorder l'accès à un ID utilisateur canonique plutôt qu'à des ID distincts dépendant du fournisseur d'identité qui a permis la connexion ?

Pas sans exécuter un distributeur automatique de jetons (« Token Vending Machine »). Si un utilisateur obtient un accès fédéré à votre rôle IAM en utilisant directement des identifiants Facebook avec STS, ces informations d'identification temporaires n'incluent que les informations correspondant aux identifiants Facebook de l'utilisateur, mais pas à ses identifiants Amazon ou Google. Si vous souhaitez stocker en interne un mapping de chacun de ces identifiants de connexion à votre propre identifiant stable, vous pouvez exécuter un service que l'utilisateur devra contacter pour se connecter, puis effectuer un appel STS pour leur fournir des informations d'identification définies pour la valeur de clé de partition que vous choisissez en tant qu'ID canonique.

Q : Quelles informations FGAC ne permet-il pas de masquer aux yeux des utilisateurs ?

A l'heure actuelle, il est impossible d'empêcher l'utilisateur réalisant un appel d'API d'accéder à certaines informations concernant les éléments de la table :

  • Mesures portant sur les collections d'éléments. L'utilisateur peut demander une estimation du nombre d'éléments, et la taille en octets de la collection d'éléments.
  • Débit utilisé. L'utilisateur peut demander une synthèse ou la répartition détaillée du débit réservé utilisé par les différentes opérations.
  • Cas de validation. Dans certains cas, l'utilisateur peut découvrir l'existence et le schéma de clé primaire d'une table, alors que vous n'aviez pas l'intention de l'y autoriser. Pour éviter une telle situation, veillez à respecter le principe du moindre privilège en autorisant uniquement l'accès aux tables et aux actions souhaitées.
  • Si vous refusez l'accès à certains attributs au lieu de les placer sur liste blanche, l'utilisateur pourra, en théorie, déterminer le nom des attributs masqués en se basant sur la logique « autoriser tous sauf ». Il est donc plus sûr de créer une liste blanche de noms d'attributs spécifiques.

Q : Amazon DynamoDB prend-il en charge les autorisations IAM ?

Oui, DynamoDB prend en charge les autorisations au niveau des API via l'intégration du service AWS Identity and Access Management (IAM).

Pour obtenir des informations supplémentaires sur IAM, consultez les ressources suivantes :

Q : Je souhaite réaliser une analyse de sécurité ou un dépannage opérationnel de mes tables DynamoDB. Puis-je obtenir un historique de tous les appels d'API DynamoDB effectués depuis mon compte ?

Oui. AWS CloudTrail est un service Web qui enregistre les appels d'API AWS pour votre compte et vous les présente sous forme de fichier journal. L'historique des appels d'API AWS généré par AWS CloudTrail permet de réaliser une analyse de sécurité, un suivi des modifications au niveau des ressources, ainsi que des audits de conformité. Des informations concernant la prise en charge de DynamoDB par CloudTrail sont disponibles ici. Pour en savoir plus sur ce service, consultez la page de présentation détaillée d'AWS CloudTrail, et pour l'activer, rendez-vous sur la page d'accueil d'AWS Management Console pour CloudTrail.


Q : Comment l'utilisation d'Amazon DynamoDB me sera-t-elle facturée ?

Chaque table DynamoDB est associée à un débit de lecture et d'écriture. Ce débit vous est facturé à l'heure si vous avez dépassé le niveau d'accès gratuit.

Veuillez noter que vous êtes facturé à l'heure pour la capacité de débit, que vous envoyez ou non des requêtes vers votre table. Pour modifier la capacité de débit alloué d'une table, vous pouvez utiliser AWS Management Console, l'API UpdateTable ou l'API PutScalingPolicy pour Auto Scaling.

Par ailleurs, le stockage de données indexées avec DynamoDB vous sera également facturé. Des frais standard de transfert de données Internet sont également applicables.

Pour en savoir plus sur la tarification de DynamoDB, consultez la page de tarification DynamoDB.

Q : Avez-vous des exemples de tarification ?

Voici un exemple détaillant la méthode de calcul de vos frais liés au débit, fondé sur la tarification de la région USA Est (Virginie du Nord). Pour afficher les tarifs d'autres régions, consultez notre page de tarification.

Si vous créez une table et demandez un débit réservé correspondant à 10 unités de capacité d'écriture et 200 unités de capacité de lecture vous serez facturé comme suit :

0,01 USD + (4 x 0,01 USD) = 0,05 USD par heure

Si vos besoins en termes de débit évoluent et que votre débit réservé passe à 10 000 unités de capacité d'écriture et 50 000 unités de capacité de lecture, le montant de la facture sera calculé comme suit :

(1 000 x 0,01 USD) + (1 000 x 0,01 USD) = 20 USD/heure

Pour en savoir plus sur la tarification de DynamoDB, consultez la page de tarification DynamoDB.

Q : Vos prix sont-ils toutes taxes comprises ?

Pour obtenir plus d'informations sur les taxes, consultez la page d'aide sur les taxes d'Amazon Web Services.

Q : Qu'est-ce que le débit alloué ?

Auto Scaling d'Amazon DynamoDB ajuste la capacité de débit automatiquement suivant les changements de volume de requêtes en se basant sur l'utilisation cible désirée et sur les limites de capacité maximale et minimale. Auto Scaling permet également d'indiquer le débit de requête que votre table doit pouvoir atteindre manuellement. Le service gère l'approvisionnement des ressources en arrière-plan afin de parvenir au rythme de débit demandé. Ainsi vous n'avez pas à vous soucier des instances, du matériel ou autres facteurs pouvant avoir une incidence sur le rythme du débit. Il ne vous reste qu'à prévoir le niveau de débit auquel vous souhaitez parvenir. Voici en quoi consiste le modèle de service de débit réservé.

Lors de la création d'une nouvelle table ou d'un nouvel index secondaire global, Auto Scaling est activé par défaut avec les paramètres de base pour l'utilisation cible ainsi que pour les capacités minimale et maximale. Vous pouvez également indiquer manuellement vos besoins en capacité de lecture et d'écriture. Dans ce cas-là, Amazon DynamoDB partitionne et réserve automatiquement la bonne quantité de ressources afin de répondre à vos exigences en matière de débit.

Q : De quelle manière le choix d'une clé primaire affecte-t-il le degré d'évolutivité ?

Lorsque vous stockez des données, Amazon DynamoDB divise la table en plusieurs partitions et répartit les données en fonction de l'élément de clé de partition de la clé primaire. Pendant l'attribution de ressources de capacité, Amazon DynamoDB exécute un modèle d'accès relativement aléatoire sur toutes les clés primaires. Nous vous recommandons de configurer votre modèle de données afin que vos requêtes entraînent une répartition équitable du trafic sur les clés primaires. Lorsqu'une table comporte peu d'éléments ou un seul élément de clé de partition fréquemment utilisé(s), le trafic est centré sur un nombre réduit de partitions ou encore sur une partition unique. Si la charge de travail est fortement déséquilibrée, c'est-à-dire concentrée sur une seule partition, l'exécution des opérations ne pourra atteindre le niveau général de débit réservé. Pour tirer le meilleur parti du débit d'Amazon DynamoDB, créez des tables dans lesquelles l'élément de clé de partition comporte plusieurs valeurs différentes. Les requêtes doivent être exécutées de manière uniforme sur l'ensemble des valeurs et de façon aléatoire. CustomerID est un bon exemple de clé primaire si le nombre de clients de l'application est élevé et si les requêtes exécutées sur plusieurs enregistrements sont plus ou moins uniformes. « Nom de catégorie du produit » est un exemple de clé primaire incorrecte, car certaines catégories de produits ont plus de succès que d'autres.

Q : Qu'est-ce qu'une unité de capacité de lecture/d'écriture ?

Comment déterminer le nombre d'unités de capacité de lecture et d'écriture nécessaire à mon application ? Une unité de capacité d'écriture vous permet d'effectuer une écriture par seconde pour les éléments de 1 Ko maximum. De même, une unité de capacité de lecture vous permet d'effectuer une lecture à cohérence forte par seconde (ou deux lectures cohérentes à terme par seconde) d'éléments de 4 Ko maximum. Les éléments plus volumineux requièrent une capacité plus importante. Vous pouvez calculer le nombre d'unités de capacité de lecture et d'écriture nécessaire en faisant une estimation du nombre de lectures ou d'écritures souhaité par seconde et en multipliant par la taille de vos éléments (arrondie au Ko le plus proche).

Unités de capacité requises pour les écritures = nombre d'écritures d'élément par seconde x taille d'élément par blocs de 1 Ko

Unités de capacité requises pour les lectures* = nombre de lectures d'élément par seconde x taille d'élément par blocs de 4 Ko

* L'utilisation de lectures cohérentes à terme permet d'obtenir un débit deux fois plus élevé en termes de lectures par seconde.

Si la taille de vos éléments est inférieure à 1 Ko, chaque unité de capacité de lecture vous permettra d'obtenir 1 lecture à cohérence forte/seconde et chaque unité de capacité d'écriture vous permettra d'obtenir une capacité d'1 écriture/seconde. Par exemple, si la taille des éléments est de 512 octets et que vous souhaitez effectuer 100 lectures d'éléments par seconde à partir de votre table, vous devez réserver 100 unités de capacité de lecture.

Si la taille des éléments est supérieure à 4 Ko, calculez le nombre d'unités de capacité de lecture et d'écriture dont vous avez besoin. Par exemple, si la taille des éléments est de 4,5 Ko et que vous souhaitez effectuer 100 lectures à cohérence forte/seconde, vous devez réserver 100 (lectures par seconde) x 2 (nombre de blocs de 4 Ko requis pour stocker 4,5 Ko) = 200 unités de capacité de lecture.

Notez que le nombre requis d'unités de capacité de lecture est déterminé par le nombre d'éléments lus par seconde et non par le nombre d'appels d'API. Par exemple, pour effectuer 500 lectures d'éléments par seconde à partir d'une table, et si la taille des éléments est inférieure ou égale à 4 Ko, alors vous avez besoin de 500 unités de capacité de lecture. Passer 500 appels GetItem individuels ou 50 appels BatchGetItem renvoyant 10 éléments chacun revient au même.

Q : Mon niveau de débit réservé pourra-t-il toujours être atteint ?

Amazon DynamoDB exécute un modèle d'accès relativement aléatoire sur toutes les clés primaires. Nous vous recommandons de configurer votre modèle de données afin que vos requêtes entraînent une répartition équitable du trafic sur les clés primaires. Le niveau de débit réservé peut ne pas être atteint si votre modèle d'accès est particulièrement déséquilibré ou incorrect.

Lorsque vous stockez des données, Amazon DynamoDB divise la table en plusieurs partitions et répartit les données en fonction de l'élément de clé de partition de la clé primaire. Le débit réservé associé à une table est également divisé au sein des partitions ; le débit de chaque partition est géré de manière indépendante en fonction du quota alloué. Aucun partage de débit réservé ne s'effectue au niveau des partitions. Ainsi, une table créée dans Amazon DynamoDB est plus susceptible d'atteindre les niveaux de débit réservé si la charge de travail est uniformément répartie au niveau des valeurs de clé de partition. La répartition des requêtes au niveau des valeurs de clé de partition entraîne la répartition des requêtes sur les partitions, vous permettant ainsi d'atteindre le niveau de débit réservé.

Si le modèle de charge de travail n'est pas équilibré au niveau des clés primaires et que vous ne parvenez pas à atteindre le niveau de débit réservé, vous pourrez peut-être respecter vos exigences en augmentant encore plus le niveau de débit réservé, ce qui permettra d'accroître le débit de chaque partition. Nous vous recommandons toutefois d'envisager la modification de votre modèle de requête ou modèle de données afin d'exécuter un modèle d'accès relativement aléatoire au niveau des clés primaires.

Q : Si je ne récupère qu'un seul élément d'un document JSON, serai-je facturé pour la lecture de l'entrée complète ?

Oui. Lorsque vous lisez des données en dehors de DynamoDB, vous consommez le débit nécessaire pour lire l'entrée complète.

Q : Quel débit maximum puis-je mettre en service pour une seule table DynamoDB ?

DynamoDB permet un dimensionnement illimité. Cependant, si vous souhaitez que le débit soit supérieur à 10 000 unités de capacité d'écriture ou 10 000 unités de capacité de lecture par table, contactez au préalable Amazon en remplissant ce formulaire en ligne. Pour mettre en service plus de 20 000 unités de capacité d'écriture ou de lecture depuis le compte d'un seul abonné, contactez-nous en remplissant le formulaire présenté ci-dessus.

Q : Quel débit minimum puis-je mettre en service pour une seule table DynamoDB ?

Le débit alloué le plus petit que vous pouvez demander est d'une unité de capacité d'écriture et d'une unité de capacité de lecture, que ce soit avec Auto Scaling ou une allocation manuelle.

Ce débit est compris dans le niveau gratuit proposant 25 unités de capacité d'écriture et 25 unités de capacité de lecture. Notez que le niveau gratuit est défini pour un compte et non pour chaque table. En d'autres termes, si vous additionnez la capacité mise en service pour chacune de vos tables et que cette capacité totale est inférieure à 25 unités de capacité d'écriture et à 25 unités de capacité de lecture, vous ne dépassez pas le niveau gratuit.

Q : Y a-t-il une limite pour la modification de mon débit réservé avec un seul appel API ?

Vous pouvez augmenter la capacité de débit réservée à votre table et choisir la quantité que vous souhaitez à l'aide de l'API UpdateTable. Par exemple, vous pouvez augmenter la capacité en écriture allouée à votre table de 1 unité de capacité d'écriture à 10 000 unités de capacité d'écriture grâce à un simple appel API. Votre compte est toujours soumis aux limites de capacité concernant la table et le compte, comme décrit dans notre page de documentation. Si vous avez besoin d'augmenter vos limites de capacité réservées, vous pouvez accéder à notre Centre de support, cliquer sur « Open a new case » (Créer un nouveau dossier), puis faire une demande d'augmentation de la limite de service.

Q : Combien coûte le service de débit réservé ?

Chaque table Amazon DynamoDB dispose des ressources réservées nécessaires pour atteindre le rythme de débit demandé. Vous serez facturé à l'heure pendant la durée de stockage de ces ressources dans la table. Pour obtenir la liste complète des prix avec des exemples, consultez la page des tarifs DynamoDB.

Q : Comment modifier le débit réservé d'une table DynamoDB existante ?

Vous pouvez mettre à jour le débit réservé d'une table Amazon DynamoDB de deux manières. Vous pouvez effectuer la modification dans la console de gestion ou appeler l'API UpdateTable. Dans tous les cas, Amazon DynamoDB reste disponible pendant l'augmentation ou la diminution de votre débit réservé.

Q : A quelle fréquence puis-je modifier mon débit réservé ?

Le nombre d'augmentations de votre débit alloué n'est pas limité. Il est possible de diminuer le débit alloué jusqu'à quatre fois par jour. Une date est définie sur le fuseau horaire GMT. De plus, si aucune diminution ne s'est produite lors des quatre dernières heures, une réduction supplémentaire est autorisée, ce qui augmente à neuf le nombre de diminutions autorisées par jour (quatre diminutions lors des quatre premières heures, puis une diminution pour chaque période de quatre heures suivante dans la journée).

N'oubliez pas que vous ne pouvez pas modifier le débit réservé si le processus de réponse à votre dernière demande de modification du débit est toujours en cours dans la table Amazon DynamoDB. Utilisez la console de gestion ou l'API DescribeTables pour vérifier le statut de votre table. Si le statut est « CREATING », « DELETING » ou « UPDATING », vous ne pourrez pas ajuster le débit de votre table. Patientez jusqu'à ce que le statut d'une table soit « ACTIVE », puis réessayez.

Q : Le niveau de cohérence a-t-il une incidence sur le rythme du débit ?

Oui. Pour une allocation de ressources donnée, le rythme de lecture pouvant être atteint par une table DynamoDB est différent pour les lectures à cohérence forte et les lectures cohérentes à terme. Si vous demandez « 1 000 unités de capacité de lecture », DynamoDB allouera les ressources suffisantes pour atteindre 1 000 lectures à cohérence forte par seconde d'éléments de 4 Ko maximum. Pour effectuer 1 000 lectures, cohérentes à terme, d'éléments de 1 Ko, vous aurez besoin de 2 fois moins de capacité, c'est-à-dire 500 unités de capacité de lecture. Pour plus de conseils sur le choix d'un rythme de débit approprié à votre table, consultez notre guide consacré au débit réservé.

Q : La taille de l'élément a-t-elle une incidence sur le rythme du débit ?

Oui. Pour un volume de ressources allouées donné, le rythme de lecture pouvant être atteint par une table DynamoDB dépend effectivement de la taille de l'élément. Lorsque vous spécifiez le débit de lecture réservé souhaité, DynamoDB prépare ses ressources en supposant que la taille des éléments sera inférieure à 4 Ko. Toute augmentation de 4 Ko maximum augmentera de façon linéaire les ressources nécessaires pour atteindre le débit réservé souhaité. Par exemple, si vous avez réservé une table DynamoDB avec 100 unités de capacité de lecture, cela signifie que celle-ci peut traiter 100 lectures de 4 Ko par seconde, 50 lectures de 8 Ko par seconde, 25 lectures de 16 Ko par seconde, etc.

De même, le rythme d'écriture pouvant être atteint par une table DynamoDB dépend de la taille de l'élément. Lorsque vous spécifiez le débit d'écriture réservé souhaité, DynamoDB prépare ses ressources en supposant que la taille des éléments sera inférieure à 1 Ko. Toute augmentation de 1 Ko maximum augmentera de façon linéaire les ressources nécessaires pour atteindre le débit réservé souhaité. Par exemple, si vous avez mis en service une table DynamoDB avec 100 unités de capacité d'écriture, cela signifie que celle-ci peut traiter 100 écritures de 1 Ko par seconde, 50 écritures de 2 Ko par seconde ou 25 écritures de 4 Ko par seconde, etc.

Pour plus de conseils sur le choix d'un rythme de débit approprié à votre table, consultez notre guide consacré au débit réservé.

Q : Que se passe-t-il si mon application effectue plus d'opérations de lecture ou d'écriture que la capacité réservée ?

Si votre application effectue plus de lectures ou écritures par seconde que la limite de débit réservé définie pour la table, les requêtes dépassant cette limite seront bloquées et vous recevrez des messages d'erreur code 400. Par exemple, si vous tentez d'effectuer 1 500 écritures/secondes d'éléments de 1 Ko alors que vous disposez de 1 000 unités de capacité d'écritures, DynamoDB autorisera le traitement de 1 000 écritures/seconde et vous recevrez des messages d'erreur code 400 pour les autres requêtes. Nous vous recommandons d'utiliser CloudWatch pour effectuer un suivi de vos requêtes afin de vous assurer que le débit réservé est adapté à la fréquence des requêtes.

Q : Comment savoir si je dépasse ma capacité de débit réservé ?

DynamoDB vous informe de la capacité de débit consommée via le système de mesure de CloudWatch. Vous pouvez configurer une alerte sur le système de mesure pour recevoir un avertissement lorsque votre capacité réservée est bientôt épuisée.

Q : Combien de temps dure une modification du niveau de débit réservé d'une table ?

En règle générale, les diminutions de débit durent quelques secondes, voire quelques minutes. Les augmentations de débit peuvent prendre quelques minutes ou quelques heures.

Nous vous recommandons vivement de ne pas attendre que la capacité de débit soit épuisée pour procéder à une augmentation de débit. Réservez le débit nécessaire bien à l'avance afin de disposer des capacités appropriées lorsque vous en avez besoin.

Q : En quoi consistent les capacités réservées ?

Il s'agit d'une fonctionnalité de facturation qui vous permet d'obtenir des remises sur votre capacité de débit réservé en contrepartie :

  • d'un paiement ponctuel initial,
  • d'un engagement par rapport à un niveau d'utilisation mensuel minimal pour la durée de l'accord.

Les capacités réservées s'appliquent à une seule région AWS et peuvent être achetées pour une durée d'un an ou de trois ans. Chaque table DynamoDB est associée à une capacité de débit alloué, qu'elle soit gérée par Auto Scaling ou allouée manuellement lorsque vous créez ou modifiez une table. Ces capacités déterminent le débit en lecture et en écriture que votre table DynamoDB pourra atteindre. Les capacités réservées constituent un mode de facturation et n'ont aucun impact direct sur les performances ou capacités de vos tables DynamoDB. Par exemple, si vous achetez des capacités réservées pour 100 unités de capacité en écriture, vous acceptez de payer pour cette quantité de capacités au cours de la durée de l'accord (1 an ou 3 ans) en contrepartie de tarifs réduits.

Q : Comment acheter des capacités réservées ?

Connectez-vous à AWS Management Console, rendez-vous sur la page de la console DynamoDB, puis cliquez sur « Reserved Capacity ». Vous accédez alors à la page « Reserved Capacity Usage ». Cliquez sur « Purchase Reserved Capacity » pour accéder à un formulaire que vous pouvez remplir afin d'acheter des capacités réservées. Vérifiez que vous avez sélectionné la région AWS dans laquelle vous utiliserez les capacités réservées. Une fois que vous avez terminé l'achat des capacités réservées, votre achat apparaît dans la page « Reserved Capacity Usage ».

Q : Puis-je annuler l'achat de capacités réservées ?

Non, vous ne pouvez pas annuler vos capacités réservées et le paiement ponctuel n'est pas remboursable. Vous continuerez de payer chaque heure de la période définie pour vos capacités réservées, quelle que soit votre utilisation.

Q : Quelle est la quantité minimale de capacités réservées pouvant être achetée ?

L'offre la plus basse concernant les capacités réservées comprend 100 unités de capacité (en écriture ou lecture).

Q : Existe-t-il des API permettant d'acheter des capacités réservées ?

Pas encore. Nous allons, par la suite, mettre au point des API et ajouter de nouvelles options pour les capacités réservées.

Q : Puis-je déplacer des capacités réservées d'une région vers une autre ?

Non. Les capacités réservées sont associées à une seule région.

Q : Puis-je mettre en service une capacité de débit supérieure à mes capacités réservées ?

Oui. Lorsque vous achetez des capacités réservées, vous vous engagez par rapport à un niveau d'utilisation mininal et vous bénéficiez d'un prix réduit pour ce niveau d'utilisation. Si vous mettez en service plus de capacités que le niveau minimal convenu, vous payez simplement les prix standard applicables en contrepartie de ces capacités supplémentaires.

Q : Comment utiliser mes capacités réservées ?

Les capacités réservées sont automatiquement prises en compte dans votre facture. Par exemple, si vous avez acheté des capacités réservées pour 100 unités de capacité en écriture et que vous en mettez 300 en service, votre achat de capacités réservées couvrira automatiquement le coût correspondant à 100 unités de capacité en écriture et vous payez les prix standard applicables pour les 200 autres unités.

Q : Que se passe-t-il si je mets en service une capacité de débit inférieure à mes capacités réservées ?

L'achat de capacités réservées est un engagement à payer un montant minimum pour une capacité de débit réservé et ce, pour toute la durée de l'accord et en contrepartie de tarifs réduits. Si votre utilisation réelle est inférieure à vos capacités réservées, vous payez, chaque mois, le montant minimum convenu pour la capacité de débit réservé.

Q : Puis-je utiliser mes capacités réservées pour plusieurs tables DynamoDB ?

Oui. Les capacités réservées portent sur une capacité totale mise en service au sein de la région dans laquelle vous achetez les capacités réservées. Par exemple, si vous achetez des capacités réservées pour 5 000 unités de capacité en écriture, vous pouvez ensuite vous en servir pour une table avec 5 000 unités de capacité en écriture ou sur 100 tables avec, chacune, 50 unités, ou encore sur 1 000 tables avec, chacune, 5 unités, etc.

Q : Les capacités réservées s'appliquent-elles à l'utilisation de DynamoDB pour les comptes à Facturation Consolidée ?

Oui. Si vous possédez plusieurs comptes à Facturation consolidée, les unités de capacité réservée achetées au niveau du compte payant ou du compte lié sont partagées avec tous les comptes associés au compte payant. Les capacités réservées seront d'abord appliquées au compte les ayant achetées. Toute capacité inutilisée sera ensuite appliquée aux autres comptes liés.

 

Q : En quoi consiste la réplication entre régions DynamoDB ?

La réplication entre régions DynamoDB vous permet de conserver des copies identiques (appelées réplicas) d'une table DynamoDB (appelée table principale) dans une ou plusieurs régions AWS. Une fois la réplication entre régions activée pour une table, des copies identiques de la table sont créées dans d'autres régions AWS. Les écritures dans la table seront automatiquement propagées sur tous les réplicas.

 

Q : Dans quels cas utiliser la réplication entre régions ?

Vous pouvez utiliser la réplication entre régions dans le cadre des scénarios suivants.

  • Reprise après sinistre efficace : en répliquant les tables dans plusieurs centres de données, vous pouvez basculer sur les tables DynamoDB d'une autre région en cas de défaillance d'un centre de données.
  • Lectures plus rapides : si vous avez des clients dans plusieurs régions, vous pouvez leur fournir plus rapidement des données en lisant la table DynamoDB située dans le centre de données AWS le plus proche.
  • Gestion facilitée du trafic : grâce aux réplicas, vous pouvez distribuer la charge de travail de lecture entre plusieurs tables et réduire ainsi la consommation de capacité de lecture dans la table principale.
  • Migration régionale facilitée : créer un réplica en lecture dans une nouvelle région et le promouvoir ensuite pour le transformer en table principale vous permet de migrer votre application dans cette région plus facilement.
  • Migration des données en temps réel : pour déplacer une table DynamoDB d'une région à une autre, vous pouvez créer un réplica de la table située dans la région source dans la région de destination. Lorsque les tables sont synchronisées, vous pouvez basculer votre application pour écrire dans la région de destination.

Q : Quels sont les modes de réplication entre régions pris en charge ?

La réplication entre régions prend actuellement en charge le mode table principale unique. Dans ce mode, il n'y a qu'une table principale et une ou plusieurs tables répliquées.

Q : Comment puis-je configurer une table pour la réplication entre régions basée sur une table principale unique ?

Vous pouvez créer des réplicas entre régions à l'aide de la bibliothèque de réplication entre régions DynamoDB.

Q : De quelle manière puis-je savoir que l'amorçage est terminé ?

Dans l'application de gestion de la réplication, l'état de la réplication passe de Amorçage à Active.

Q : Puis-je avoir plusieurs réplicas pour une seule table principale ?

Oui, le nombre de réplicas d'une table principale unique n'est pas limité. Un lecteur de flux DynamoDB est créé pour chaque table répliquée et copie les données à partir de la table principale, assurant ainsi la synchronisation des réplicas.

Q : Combien coûte la configuration de la réplication entre régions pour une table ?

La réplication entre régions DynamoDB est activée à l'aide de la bibliothèque de réplication entre régions DynamoDB. Aucuns frais supplémentaires ne vous sont facturés pour la bibliothèque de réplication entre régions. Vous payez les tarifs habituels pour les ressources suivantes utilisées par le processus. Les éléments suivants feront l'objet de frais :

  • Débit réservé (écritures et lectures) et stockage pour les tables répliquées.
  • Transfert de données d'une région à une autre.
  • Lecture des données à partir de la fonction Flux de DynamoDB pour synchroniser les tables.
  • Instances EC2 réservées pour héberger le processus de réplication. Le coût des instances dépendra du type d'instance que vous choisirez, ainsi que de la région hébergeant ces instances.

Q : Dans quelle région l'instance Amazon EC2 hébergeant la réplication entre régions est-elle exécutée ?

L'application de réplication entre régions est hébergée dans une instance Amazon EC2 située dans la même région où l'application de réplication entre régions a été lancée à l'origine. Le prix de l'instance dans cette région vous sera facturé.

Q : L'instance Amazon EC2 se dimensionne-t-elle automatiquement en fonction des modifications apportées à la taille et au débit de la table principale et des tables répliquées ?

Pour le moment, nous ne dimensionnons pas automatiquement l'instance EC2. Vous devrez sélectionner la taille de l'instance pendant la configuration de la réplication entre régions de DynamoDB.

Q : Que se passe-t-il si l'instance Amazon EC2 gérant la réplication échoue ?

L'instance Amazon EC2 est exécutée derrière un groupe Auto Scaling, ce qui signifie que l'application est automatiquement basculée vers une autre instance. L'application située en dessous utilise la bibliothèque client Kinesis (KCL), qui crée un point de contrôle pour la copie. En cas de défaillance de l'instance, l'application est capable de trouver le point de contrôle et reprend à partir de celui-ci.

Q : Puis-je continuer à utiliser ma table DynamoDB lors de la création d'un réplica en lecture ?

Oui, la création d'un réplica est une opération effectuée en ligne. Votre table restera disponible pour les lectures et les écritures pendant la création du réplica en lecture. L'amorçage utilise l'opération d'analyse pour effectuer une copie à partir de la table source. Nous vous recommandons de réserver une capacité de lecture suffisante pour prendre en charge l'opération d'analyse.

 

Q : Combien de temps faut-il pour créer un réplica ?

Le temps nécessaire pour copier initialement la table principale vers la table répliquée dépend de la taille de la table principale et de la capacité réservée pour celle-ci et pour la table répliquée. Le temps nécessaire pour propager une modification au niveau des éléments de la table principale sur la table répliquée dépend de la capacité réservée de la table principale et des tables répliquées, ainsi que de la taille de l'instance Amazon EC2 exécutant l'application de réplication.

Q : Si je modifie la capacité réservée de ma table principale, celle réservée pour ma table répliquée sera-t-elle également mise à jour ?

Une fois la réplication créée, toute modification apportée à la capacité réservée de la table principale n'entraînera pas de mise à jour de la capacité de débit de la table répliquée.

 

Q : Mes tables répliquées disposeront-elles des mêmes index que la table principale ?

Si vous choisissez de créer la table répliquée à partir de l'application de réplication, les index secondaires de la table principale ne seront PAS créés automatiquement sur la table répliquée. L'application de réplication ne propagera pas les modifications apportées aux index secondaires de la table principale sur les tables répliquées. Vous devrez ajouter, mettre à jour ou supprimer les index dans chacune des tables répliquées à partir d'AWS Management Console, comme vous le feriez avec des tables DynamoDB classiques.

 

Q : Mes réplicas disposeront-ils de la même capacité de débit réservée que ma table principale ?

Lors de la création d'une table répliquée, nous vous recommandons d'allouer au moins la même capacité de lecture que la table principale, afin de vous assurer qu'elle dispose de la capacité suffisante pour gérer les écritures entrantes. Vous pouvez attribuer n'importe quelle valeur à la capacité de lecture réservée de votre table répliquée en fonction des besoins de votre application.

 

Q : Quel est le modèle de cohérence pour les tables répliquées ?

Les réplicas sont mis à jour de manière asynchrone. DynamoDB reconnaîtra une opération d'écriture comme réussie une fois qu'elle aura été acceptée par la table principale. L'écriture sera alors propagée à chaque réplica. Cela signifie qu'il y aura un léger délai avant qu'une écriture ne soit propagée à l'ensemble des tables répliquées.

Q : Existe-t-il des mesures CloudWatch pour la réplication entre régions ?

Des mesures CloudWatch sont disponibles pour chaque configuration de réplication. Vous pouvez afficher les mesures en sélectionnant le groupe de réplication et en accédant à l'onglet Surveillance. Des mesures en matière de débit et d'enregistrements traités sont disponibles. Vous pouvez surveiller tout écart entre le débit de la table principale et celui des tables répliquées.

Q : Puis-je disposer d'un réplica dans la même région que la table principale ?

Oui, tant que la table répliquée et la table principale ont des noms différents, les deux tables peuvent exister dans la même région.

Q : Puis-je ajouter ou supprimer un réplica après la création d'un groupe de réplication ?

Oui, vous pouvez ajouter ou supprimer un réplica de ce groupe de réplication à tout moment.

Q : Puis-je supprimer un groupe de réplication après sa création ?

Oui, la suppression du groupe de réplication supprimera l'instance EC2 pour ce groupe. Toutefois, vous devrez supprimer la table de métadonnées DynamoDB.

Q : Qu'est-ce que la fonction Déclencheurs de DynamoDB ?

La fonction Déclencheurs de DynamoDB vous permet d'exécuter des actions personnalisées en fonction des mises à jour apportées au niveau des éléments dans une table DynamoDB. Vous pouvez spécifier l'action personnalisée sous la forme de code.

Q : Que puis-je faire avec les déclencheurs DynamoDB ?

Il existe différents scénarios d'application pour lesquels les déclencheurs DynamoDB peuvent être utiles. Les cas d'utilisation courants comprennent l'envoi de notifications, la mise à jour d'une table d'agrégation et la connexion de tables DynamoDB à d'autres sources de données.

Q : Comment fonctionnent les déclencheurs DynamoDB ?

La logique personnalisée pour un déclencheur DynamoDB est stockée dans une fonction AWS Lambda sous forme de code. Pour créer un déclencheur pour une table donnée, vous pouvez associer une fonction AWS Lambda au flux (via la fonction Flux de DynamoDB) dans une table DynamoDB. Lorsque la table est mise à jour, les mises à jour sont publiées dans les flux DynamoDB. AWS Lambda lit alors les mises à jour du flux associé et exécute le code dans la fonction.

Q : Combien coûte l'utilisation de la fonction Déclencheurs de DynamoDB ?

Avec la fonction Déclencheurs de DynamoDB, vous ne payez que le nombre de requêtes pour votre fonction AWS Lambda, ainsi que la durée nécessaire à l'exécution de cette fonction. Pour en savoir plus sur la tarification AWS Lambda, cliquez ici. Les lectures effectuées par la fonction AWS Lambda sur le flux associé à la table (via la fonction Flux de DynamoDB) ne vous sont pas facturées.

Q : Le nombre de déclencheurs pour une table est-il limité ?

Le nombre de déclencheurs pour une table n'est pas limité.

Q : Quels sont les langages pris en charge par la fonction Déclencheurs de DynamoDB ?

À l'heure actuelle, la fonction Déclencheurs de DynamoDB prend en charge JavaScript, Java et Python pour les fonctions de déclencheur.

Q : Existe-t-il un support d'API pour la création, la modification ou la suppression de déclencheurs DynamoDB ?

Non. Actuellement, il n'existe aucune API d'origine permettant de créer, modifier ou supprimer des déclencheurs DynamoDB. Vous devez utiliser la console AWS Lambda pour créer une fonction AWS Lambda et l'associer à un flux dans la fonction Flux de DynamoDB. Pour plus d'informations, consultez la FAQ sur AWS Lambda.

Q : Comment puis-je créer un déclencheur DynamoDB ?

Vous pouvez créer un déclencheur en concevant une fonction AWS Lambda et en associant la source d'événement pour la fonction à un flux dans la fonction Flux de DynamoDB. Pour plus d'informations, consultez la FAQ sur AWS Lambda.

Q : Comment puis-je supprimer un déclencheur DynamoDB ?

Vous pouvez supprimer un déclencheur en supprimant la fonction AWS Lambda associée. Vous pouvez supprimer une fonction AWS Lambda à partir de la console AWS Lambda ou par le biais d'un appel d'API AWS Lambda. Pour plus d'informations, consultez la FAQ sur AWS Lambda et la page de documentation.

Q : Je possède déjà une fonction AWS Lambda. Comment puis-je créer un déclencheur DynamoDB à l'aide de cette fonction ?

Vous pouvez modifier la source d'événement de la fonction AWS Lambda pour la rediriger vers un flux dans la fonction Flux de DynamoDB. Vous pouvez faire cela à partir de la console DynamoDB. Dans la table pour laquelle le flux est activé, sélectionnez le flux, cliquez sur le bouton « Associate Lambda Function » (associer fonction Lambda), puis choisissez la fonction que vous souhaitez utiliser pour le déclencheur DynamoDB à partir de la liste des fonctions Lambda disponibles.

Q : Dans quelles régions la fonction Déclencheurs de DynamoDB est-elle disponible ?

La fonction Déclencheurs de DynamoDB est disponible dans toutes les régions AWS où AWS Lambda et DynamoDB sont mis à disposition.

Q : Qu'est-ce que la fonction Flux de DynamoDB ?

La fonction Flux de DynamoDB fournit une séquence classée par ordre chronologique, reprenant les modifications au niveau des éléments apportées aux données d'un tableau au cours des dernières 24 heures. Vous pouvez accéder à un flux à l'aide d'un simple appel d'API et l'utiliser pour mettre les autres magasins de données à jour avec les dernières modifications apportées à DynamoDB ou prendre des mesures en fonction des changements effectués dans votre table.

Q : Quels sont les avantages de la fonction Flux de DynamoDB ?

A l'aide des API de la fonction Flux de DynamoDB, les développeurs sont en mesure d'appliquer des mises à jour et recevoir les données des items avant et après la modification de ces derniers. Cette fonctionnalité peut être utilisée pour créer des extensions créatives pour vos applications à partir de DynamoDB. Par exemple, un développeur concevant un jeu multijoueur mondial à l'aide de DynamoDB peut utiliser les API de la fonction Flux de DynamoDB pour créer une topologie multi-utilisateurs et synchroniser les utilisateurs en ayant recours à la fonction Flux de DynamoDB pour chaque utilisateur et en répétant les mises à jour dans les utilisateurs à distance. Autre exemple, les développeurs peuvent utiliser les API de la fonction Flux de DynamoDB pour développer des applications mobiles qui envoient automatiquement des notifications sur les appareils mobiles de tous les amis d'un cercle dès qu'un utilisateur télécharge un nouveau selfie. Les développeurs peuvent également se servir de la fonction Flux de DynamoDB pour synchroniser les outils d'entreposage de données, tels qu'Amazon Redshift, avec toutes les modifications apportées à leur table DynamoDB afin de réaliser des analyses en temps réel. DynamoDB est également intégré à Elasticsearch à l'aide du module d'extension Logstash d'Amazon DynamoDB, ce qui permet aux développeurs de bénéficier de la fonction de recherche de texte libre pour le contenu DynamoDB.

Consultez notre documentation pour obtenir plus d'informations sur la fonction Flux de DynamoDB.

Q : Pendant combien de temps les modifications apportées à ma table DynamoDB sont-elles disponibles via DynamoDB Streams ?

DynamoDB Streams conserve les enregistrements de toutes les modifications effectuées à une table pendant 24 heures. Une fois ce délai écoulé, ils seront effacés.

Q : Comment puis-je activer DynamoDB Streams ?

La fonction Flux de DynamoDB doit être activée sur chacune des tables. Pour activer DynamoDB Streams pour une table DynamoDB existante, sélectionnez la table via AWS Management Console, accédez à l'onglet « Overview », cliquez sur le bouton « Manage Stream », sélectionnez un type de vue, puis cliquez sur « Enable ».

Pour en savoir plus, reportez-vous à la documentation.

Q : Comment puis-je vérifier que la fonction Flux de DynamoDB a été activée ?

Une fois la fonction Flux de DynamoDB activée, vous pouvez consulter le flux dans AWS Management Console. Sélectionnez votre table, puis cliquez sur l'onglet « Overview ». Sous « Stream details », vérifiez que l'option « Stream enabled » est activée (Yes).

Q : Comment accéder à la fonction Flux de DynamoDB ?

Vous pouvez accéder à un flux disponible via la fonction Flux de DynamoDB avec un simple appel d'API à l'aide du kit SDK DynamoDB ou de la bibliothèque client Kinesis (KCL). KCL vous aide à utiliser et traiter les données provenant du flux, gérer des tâches telles que l'équilibrage de charge sur plusieurs lecteurs, la réaction aux instances défaillantes et l'enregistrement de points de contrôle pour les enregistrements traités.

Pour plus d'informations sur l'accès à la fonction Flux de DynamoDB, consultez notre documentation.

Q : Le service DynamoDB Streams affiche-t-il toutes les modifications apportées à ma table DynamoDB dans l'ordre ?

Les modifications effectuées sur chaque élément apparaissent dans le bon ordre. Les modifications effectuées sur plusieurs éléments peuvent apparaitre dans la fonction Flux de DynamoDB dans un ordre différent de celui dans lequel elles ont été reçues.

Par exemple, imaginons que vous disposez d'une table DynamoDB suivant les meilleurs scores et que chaque élément dans la table représente un seul joueur. Si vous effectuez les trois modifications suivantes dans cet ordre :

  • Mise à jour 1 : changement du meilleur score du joueur 1 qui passe à 100 points
  • Mise à jour 2 : changement du meilleur score du joueur 2 qui passe à 50 points
  • Mise à jour 3 : changement du meilleur score du joueur 1 qui passe à 125 points

Les mises à jour 1 et 3 modifient toutes les deux le même élément (le joueur 1). Par conséquent, la fonction Flux de DynamoDB vous indiquera que la mise à jour 3 est apparue après la mise à jour 1. Vous pouvez ainsi récupérer le dernier meilleur score de chaque joueur. Le flux n'affichera peut-être pas les trois mises à jour dans le même ordre que celui dans lequel elles ont été effectuées (par exemple, la mise à jour 2 est survenue après la mise à jour 1 et avant la mise à jour 3). Cependant, les mises à jour du score de chaque joueur apparaitront dans le bon ordre.

Q : Dois-je gérer la capacité d'un flux dans la fonction Flux de DynamoDB ?

Non, la capacité pour votre flux est gérée automatiquement dans la fonction Flux de DynamoDB. Si vous augmentez de façon considérable le trafic vers votre table DynamoDB, DynamoDB ajustera automatiquement la capacité du flux afin qu'il continue à accepter toutes les mises à jour.

Q : A quel rythme puis-je lire les mises à jour depuis la fonction Flux de DynamoDB ?

Vous pouvez lire les mises à jour depuis votre flux dans la fonction Flux de DynamoDB, à un rythme jusqu'à deux fois plus rapide que la capacité en écriture réservée de votre table DynamoDB. Par exemple, si vous avez réservé suffisamment de capacité pour mettre à jour 1 000 éléments par seconde dans votre table DynamoDB, vous pourrez lire jusqu'à 2 000 mises à jour par seconde à partir de votre flux.

Q : Si j'efface ma table DynamoDB, le flux est-il également supprimé dans la fonction Flux de DynamoDB ?

Non, pas immédiatement. Le flux sera conservé dans la fonction Flux de DynamoDB pendant 24 heures pour vous donner la possibilité de lire les dernières mises à jour apportées à votre table. Après 24 heures, le flux sera automatiquement supprimé de la fonction Flux de DynamoDB.

Q : Que se passe-t-il si je désactive la fonction Flux de DynamoDB pour ma table ?

Si vous désactivez la fonction Flux de DynamoDB, le flux sera conservé pendant 24 heures, mais ne sera pas mis à jour avec les modifications supplémentaires apportées à votre table DynamoDB.

Q : Que se passe-t-il si je désactive DynamoDB Streams, puis que je l'active de nouveau ?

Lorsque vous désactivez DynamoDB Streams, le flux sera conservé pendant 24 heures, mais ne sera pas mis à jour avec les modifications supplémentaires apportées à votre table DynamoDB. Si vous activez de nouveau la fonction Flux de DynamoDB, un nouveau flux sera créé dans la fonction Flux de DynamoDB et contiendra les modifications apportées à votre table DynamoDB à partir de la création du nouveau flux.

Q : La fonction Flux de DynamoDB présentera-t-elle des doublons ou des failles ?

Non. La fonction Flux de DynamoDB est conçue pour que chaque mise à jour apportée à votre table apparaisse une seule fois dans le flux.

Q : Quelles informations la fonction Flux de DynamoDB contient-elle ?

Un flux DynamoDB contient des informations concernant la valeur précédente et la valeur modifiée de l'élément. Le flux inclut également le type de modification apportée (insertion, suppression et modification), ainsi que la clé principale pour l'élément qui a été modifié.

Q : De quelle façon puis-je choisir les informations contenues dans la fonction Flux de DynamoDB ?

Pour les nouvelles tables, utilisez l'appel d'API CreateTable et spécifiez le paramètre ViewType pour choisir quelles informations vous souhaitez inclure dans le flux.
Pour une table existante, utilisez l'appel d'API UpdateTable et spécifiez le paramètre ViewType pour choisir quelles informations seront incluses dans le flux.

Le paramètre ViewType accepte les valeurs suivantes :

ViewType: {
                    { KEYS_ONLY,
                      NEW_IMAGE,
                      OLD_IMAGE,
                      NEW_AND_OLD_IMAGES}
                }

Les valeurs ont la signification suivante : KEYS_ONLY :seul le nom de la clé des éléments qui ont été modifiés est inclus dans le flux.

  • NEW_IMAGE : le nom de la clé et l'élément après la mise à jour (nouvel élément) sont inclus dans le flux.
  • OLD_IMAGE : le nom de la clé et l'élément avant la mise à jour (ancien élément) sont inclus dans le flux.
  • NEW_AND_OLD_IMAGES : le nom de la clé et l'élément avant (ancien élément) et après (nouvel élément) la mise à jour sont inclus dans le flux.

Q : Puis-je utiliser ma bibliothèque client Kinesis pour accéder à la fonction Flux de DynamoDB ?

Oui. Les développeurs familiarisés avec les API Kinesis seront en mesure d'utiliser facilement la fonction Flux de DynamoDB. Vous pouvez avoir recours à l'adaptateur DynamoDB Streams, qui met en œuvre l'interface Amazon Kinesis, pour permettre à vos applications d'utiliser les bibliothèques clients Amazon Kinesis (KCL) pour accéder à DynamoDB Streams. Pour plus d'informations sur l'utilisation de la bibliothèque client Kinesis pour accéder à DynamoDB Streams, consultez notre documentation.

Q : Puis-je modifier le type d'informations contenues dans la fonction Flux de DynamoDB ?

Si vous souhaitez modifier le type d'informations stockées dans un flux une fois ce dernier créé, vous devez désactiver le flux et en créer un nouveau à l'aide de l'API UpdateTable.

Q : Lorsque j'apporte des modifications à ma table DynamoDB, sous quel délai ces changements apparaissent-ils dans un flux DynamoDB ?

Les modifications sont généralement prises en compte dans le flux DynamoDB en moins d'une seconde.

Q : Si je supprime un élément, cette modification sera-t-elle incluse dans la fonction Flux de DynamoDB ?

Oui. Chaque mise à jour dans un flux DynamoDB contient un paramètre qui indique si la mise à jour concerne l'insertion d'un nouvel élément, la suppression ou la modification d'un élément existant. Pour plus d'informations sur les types de mise à jour, consultez notre documentation.

Q : Une fois la fonction Flux de DynamoDB activée pour ma table, quand puis-je commencer à lire les mises à jour depuis le flux ?

Vous pouvez utiliser l'API DescribeStream pour obtenir l'état actuel du flux. Une fois que l'état du flux devient « ENABLED », toutes les mises à jour apportées à votre table seront représentées dans le flux.

Vous pouvez commencer à les lire depuis le flux dès que vous avez créé ce dernier. Cependant, le flux ne comprendra peut-être pas toutes les mises à jour effectuées dans la table tant que son statut ne sera pas passé à « ENABLED ».

Q : Qu'est-ce que le module d'extension Logstash d'Amazon DynamoDB pour Elasticsearch ?

Elasticsearch est un moteur d'analyse et de recherche couramment utilisé et à code source libre, conçu pour simplifier la recherche en temps réel et les analyses Big Data. Logstash est un pipeline de données à code source libre qui fonctionne avec Elasticsearch afin de vous aider à traiter vos journaux et autres données d'événements. Le module d'extension Logstash d'Amazon DynamoDB facilite l'intégration des tables DynamoDB aux clusters Elasticsearch.

Q : Quel est le coût du module d'extension Logstash d'Amazon DynamoDB ?

Le téléchargement et l'utilisation du module d'extension Logstash d'Amazon DynamoDB sont gratuits.

Q : Comment puis-je télécharger et installer le module d'extension Logstash d'Amazon DynamoDB ?

Le module d'extension Logstash d'Amazon DynamoDB est disponible sur GitHub. Consultez notre page de documentation pour en savoir plus sur l'installation et l'exécution du module d'extension.


Q : Qu'est-ce que le back-end de stockage DynamoDB pour Titan ?

Le back-end de stockage DynamoDB pour Titan est un module d'extension qui vous permet d'utiliser DynamoDB comme couche de stockage sous-jacente pour la base de données orientée graphe Titan. Il s'agit d'une solution côté client, qui met en place une adjacence sans recours à un index pour parcourir rapidement les graphes sur DynamoDB.

Q : Qu'est-ce qu'une base de données orientée graphe ?

Une base de données orientée graphe est une réserve de nœuds et d'arcs dirigés qui relient ces nœuds. Les nœuds et les arcs peuvent posséder des propriétés, stockées sous la forme de paires clé-valeur.

Une base de données orientée graphe utilise des listes d'adjacence pour le stockage des nœuds afin de faciliter la traversée. Un graphe contenu dans une base de données orientée graphe peut être traversé le long de types d'arcs spécifiques ou à travers le graphe tout entier. Les bases de données orientées graphe représentent la manière dont les entités sont reliées entre-elles grâce aux actions, à la propriété, aux liens de parenté, etc.

Q : Quelles applications sont adaptées aux bases de données orientées graphe ?

Dès lors que les connexions ou les relations entre des entités constituent le cœur des données que vous essayez de modéliser, le choix doit naturellement se porter sur une base de données orientée graphe. Par conséquent, les bases de données orientées graphe sont utiles pour modéliser et interroger les réseaux sociaux, les relations professionnelles, les dépendances, les mouvements d'expédition, et bien plus.

Q : Comment puis-je faire mes premiers pas dans le back-end de stockage DynamoDB pour Titan ?

Le moyen le plus facile de faire vos premiers pas consiste à lancer une instance EC2 exécutant Gremlin Server avec le back-end de stockage DynamoDB pour Titan, en utilisant les templates CloudFormation indiqués sur cette page de documentation. Vous pouvez également cloner le projet à partir du répertoire GitHub et commencer par suivre les didacticiels Marvel et Graph-Of-The-Gods sur votre propre ordinateur, en vous référant aux instructions indiquées dans cette documentation. Lorsque vous êtes prêt à élargir votre test ou à commencer la production, vous pouvez changer de back-end afin d'utiliser le service DynamoDB. Pour plus d'informations, consultez la documentation AWS.

Q : En quoi le back-end de stockage DynamoDB est-il différent des autres back-ends de stockage Titan ?

DynamoDB est un service géré. De ce fait, l'utiliser comme back-end de stockage pour Titan vous permet d'exécuter des charges de travail de graphe sans avoir à gérer votre propre cluster pour stocker les graphes.

Q : Le back-end de stockage DynamoDB pour Titan est-il un service entièrement géré ?

Non. Le back-end de stockage DynamoDB pour Titan gère la couche de stockage pour votre charge de travail Titan. Cependant, le module d'extension ne s'occupe pas de la mise en service et de la gestion côté client. Pour mettre en service Titan facilement, nous avons développé un template CloudFormation qui configure le back-end de stockage DynamoDB pour Titan avec Gremlin Server ; les instructions sont disponibles ici.

Q : Combien coûte l'utilisation du back-end de stockage DynamoDB pour Titan ?

Vous êtes facturé selon les frais habituels associés au stockage et au débit DynamoDB. Aucuns frais supplémentaires ne s'appliquent à l'utilisation de DynamoDB comme back-end de stockage pour une charge de travail de graphe Titan.

Q : Le back-end DynamoDB offre-t-il une compatibilité complète avec l'ensemble de fonctionnalités de Titan sur les autres back-ends ?

Un tableau comparant les ensembles de fonctionnalités des différents back-ends de stockage Titan est disponible dans la documentation.

Q : Quelles versions de Titan le module d'extension prend-il en charge ?

Nous proposons des modules d'extension de back-end de stockage DynamoDB pour les versions 0.5.4 et 1.0.0 de Titan.

Q : J'utilise actuellement Titan avec un autre back-end. Puis-je migrer vers DynamoDB ?

Tout à fait. Le back-end de stockage DynamoDB pour Titan met en place l'interface Titan KCV Store afin que vous puissiez passer d'un autre back-end de stockage à DynamoDB sans avoir à apporter de changements importants à votre application. Pour obtenir une comparaison complète des back-ends de stockage pour Titan, veuillez consulter notre documentation.

Q : J'utilise actuellement Titan avec un autre back-end. Comment puis-je migrer vers DynamoDB ?

Vous pouvez utiliser le chargement par lots pour copier votre graphe du back-end de stockage actuel au back-end de stockage DynamoDB pour Titan.

Q : Comment puis-je connecter mon instance Titan à DynamoDB via le plugin ?

Si vous créez un graphe et une instance de serveur Gremlin avec le back-end de stockage DynamoDB pour Titan installé, tout ce que vous avez à faire pour connecter DynamoDB est de fournir un ensemble d'informations d'identification/d'entités de sécurité à la chaîne du fournisseur d'informations d'identification AWS par défaut. Pour ce faire, utilisez le profil d'une instance EC2, les variables d'environnement ou le fichier d'informations d'identification de votre dossier principal. Enfin, vous devez choisir un point de terminaison DynamoDB auquel vous connecter.

Q : Quelle est la résistance de mes données avec le back-end de stockage DynamoDB pour Titan ?

Lorsque vous utilisez le back-end de stockage DynamoDB pour Titan, vos données bénéficient du haut niveau de protection de DynamoDB, qui s'exécute sur les centres de données éprouvés et à haute disponibilités d'Amazon. Ce service réplique les données sur trois installations au sein d'une région AWS afin de garantir une tolérance aux pannes en cas de défaillance du serveur ou de panne de la zone de disponibilité.

Q : À quel point le back-end de stockage DynamoDB pour Titan est-il sécurisé ?

Le back-end de stockage DynamoDB pour Titan stocke les données de graphe dans plusieurs tables DynamoDB, et bénéficie ainsi d'un niveau de sécurité aussi élevé que celui disponible sur toutes les charges de travail DynamoDB. Le contrôle précis des accès, les rôles IAM et les ensembles d'informations d'identification/d'entités de sécurité AWS contrôlent l'accès aux tables DynamoDB et aux éléments qu'elles contiennent.

Q : Comment le back-end de stockage DynamoDB pour Titan se met-il à l'échelle ?

Le back-end de stockage DynamoDB pour Titan se met à l'échelle de la même manière que toute autre charge de travail DynamoDB. Vous pouvez choisir d'augmenter ou de réduire le débit requis à tout moment.

Q : Combien de nœuds et d'arcs mon graphe peut-il contenir ?

Tant que vous utilisez le modèle à plusieurs éléments pour stocker les arcs, vous êtes soumis aux limites de Titan de (2^60) en ce qui concerne le nombre maximal d'arcs pouvant être contenus dans un graphe, le nombre maximal de nœuds étant égal à la moitié du nombre d'arcs. Si vous utilisez le modèle à un seul élément, le nombre d'arcs que vous pouvez stocker sur une clé hors summit spécifique est limité à la taille d'élément maximale de DynamoDB, qui est actuellement de 400 Ko.

Q : Quelle peut être la taille maximale des propriétés de mes arcs et de mon summit ?

Dans le modèle à plusieurs éléments, la somme de toutes les propriétés d'arc ne peut excéder 400 Ko, la taille maximale d'un élément. Dans ce même modèle, chaque propriété de summit peut aller jusqu'à 400 Ko. Dans le modèle à un seul élément, la taille totale de l'élément (contenant les propriétés du summit, les arcs et les propriétés des arcs) ne peut excéder 400 Ko.

Q : Combien de modèles de données existe-t-il ? En quoi sont-ils différents ?

Il existe deux modèles de stockage différents pour le back-end de stockage DynamoDB pour Titan : le modèle à un seul élément et le modèle à plusieurs éléments. Dans le modèle de stockage de données à un seul élément, les nœuds, les propriétés du summit et les arcs sont stockés au sein d'un élément. Dans le modèle de données à plusieurs éléments, les nœuds, les propriétés du summit et les arcs sont stockés dans différents éléments. Dans les deux cas, les propriétés des arcs sont stockées dans les mêmes éléments que les arcs auxquels elles correspondent.

Q : Quel modèle de données dois-je utiliser ?

En général, nous vous recommandons d'utiliser le modèle de données à plusieurs éléments pour le stockage des arcs et les tables d'index de graphe. Sinon, vous pouvez soit limiter le nombre d'arcs/de propriétés de summit que vous pouvez stocker pour un summit externe, soit limiter le nombre d'entités qui peuvent être indexées sur une paire nom-valeur spécifique dans l'index de graphe. Vous pouvez généralement utiliser le modèle de données à un seul élément pour les 4 autres KCV Stores des versions 0.5.4 et 1.0.0 de Titan, car la taille des éléments qui y sont stockés est habituellement inférieure à 400 Ko. Pour obtenir une liste complète des tables créées par le module d'extension Titan sur DynamoDB, veuillez consulter cette page.

Q : Dois-je créer un schéma pour les bases de données orientées graphe Titan ?

Titan prend en charge la création automatique de type. Par conséquent, les nouvelles étiquettes et propriétés d'arcs/de summit seront enregistrées dans la foulée (cliquez ici pour en savoir plus) de la première utilisation. La structure Gremlin (Edge labels=MULTI, Vertex properties=SINGLE) est utilisée par défaut.

Q : Puis-je modifier le schéma d'une base de données orientée graphe Titan ?

Oui, mais vous ne pouvez pas modifier le schéma des étiquettes et propriétés de summit/d'arcs existantes. Cliquez ici pour en savoir plus.

Q : Comment le back-end de stockage DynamoDB pour Titan traite-t-il les super-nœuds ?

DynamoDB traite les super-nœuds via le partitionnement des étiquettes de summit. Si vous définissez une étiquette de summit comme partitionnée dans le système de gestion lors de sa création, vous pouvez adapter plusieurs sous-ensembles de propriétés d'arcs et de summit, provenant d'un summit, avec différentes clés de partition de l'espace réservé aux clés de partition-tri dans la table du stockage d'arcs. Cela engendre généralement le stockage des partitions d'étiquettes de summit virtuelles dans différentes partitions DynamoDB physiques, tant que votre stockage d'arcs dispose de plusieurs partitions physiques. Pour estimer le nombre de partitions physiques derrière votre table de stockage d'arcs, veuillez consulter les instructions de la documentation.

Q : Le back-end de stockage DynamoDB pour Titan prend-il en charge les opérations de graphe par lot ?

Oui, le back-end de stockage DynamoDB pour Titan prend en charge les graphes par lots, grâce à l'implémentation Blueprints BatchGraph et aux options de configuration du chargement par lots de Titan.

Q : Le back-end de stockage DynamoDB pour Titan prend-il en charge les transactions ?

Le back-end de stockage DynamoDB pour Titan prend en charge le verrouillage optimiste. Cela signifie qu'il peut conditionner les écritures des paires clé-colonne individuelles (dans le modèle à plusieurs éléments) ou les clés individuelles (dans le modèle à un seul élément) sur la valeur existante de la paire clé-colonne ou de la clé en question.

Q : Puis-je disposer d'une instance Titan dans une région et accéder à DynamoDB dans une autre ?

Il est possible d'accéder à un point de terminaison DynamoDB dans une autre région que celle de l'instance EC2 Titan, mais cela n'est pas recommandé. Lorsque vous exécutez Gremlin Server en dehors d'EC2, nous vous conseillons de vous connecter au point de terminaison DynamoDB correspondant à la région de votre instance EC2, afin de réduire la latence qu'impliquent les requêtes entre régions. Nous vous recommandons également d'exécuter l'instance EC2 dans un VPC pour améliorer les performances du réseau. Le modèle CloudFormation effectue l'intégralité de cette configuration à votre place.

Q : Puis-je utiliser ce module d'extension avec d'autres fonctionnalités de DynamoDB, comme les flux de mise à jour et la réplication entre régions ?

Vous pouvez utiliser la réplication entre régions avec la fonctionnalité Flux DynamoDB afin de créer des réplicas en lecture seule de vos tables de graphe dans d'autres régions.


Q : Est-ce qu'Amazon DynamoDB présente les mesures CloudWatch ?

Oui, Amazon DynamoDB présente plusieurs tables de mesures sur CloudWatch. Vous pouvez prendre des décisions opérationnelles concernant vos tables Amazon DynamoDB et réaliser des actions spécifiques, par exemple programmer des alarmes, en fonction de ces mesures. Pour consulter la liste complète des mesures présentées, consultez la section Monitoring DynamoDB with CloudWatch de notre documentation.

Q : Comment puis-je consulter les mesures CloudWatch d'une table Amazon DynamoDB ?

Sur la console Amazon DynamoDB, sélectionnez la table dont vous souhaitez consulter les mesures CloudWatch, puis sélectionnez l'onglet Metrics.

Q : À quelle fréquence les mesures sont-elles présentées ?

La plupart des mesures CloudWatch pour Amazon DynamoDB sont présentées à des intervalles d'une minute, tandis que le reste des mesures est présenté des intervalles de 5 minutes. Pour en savoir plus, consultez la section Monitoring DynamoDB with CloudWatch de notre documentation.


Q : Qu'est-ce qu'une balise ?

Une balise est une étiquette que vous affectez à une ressource AWS. Chaque balise est constituée d'une clé et d'une valeur que vous pouvez définir. AWS se sert des balises comme d'un mécanisme pour organiser les coûts de vos ressources sur votre rapport de répartition des coûts. Pour en savoir plus sur le balisage, consultez le manuel AWS Billing and Cost Management User Guide.

Q : Quelles ressources DynamoDB puis-je baliser ?

Vous pouvez baliser des tables DynamoDB. Les index secondaires locaux et les index secondaires globaux associés aux tables balisées se voient automatiquement attribuer les mêmes balises. Les coûts des index secondaires locaux et des index secondaires globaux s'affichent sous les balises utilisées pour la table DynamoDB correspondante.

Q : Pourquoi utiliser le balisage pour DynamoDB ?

Vous pouvez utiliser le balisage pour DynamoDB pour la répartition des coûts. L'utilisation de balises pour la répartition des coûts vous permet d'étiqueter vos ressources DynamoDB de manière à pouvoir suivre facilement leurs coûts par rapport aux projets ou à d'autres critères afin de refléter votre propre structure de coût.

Q : Comment utiliser des balises pour la répartition des coûts ?

Vous pouvez utiliser des balises de répartition des coûts pour classer vos coûts AWS par catégorie et en effectuer le suivi. L'Explorateur de coûts AWS et les rapports de facturation détaillés donnent la possibilité de ventiler les coûts AWS par balise. En général, les clients utilisent des balises métier telles que le centre de coûts/l'unité commerciale, le client ou le projet, pour associer les coûts AWS aux aspects traditionnels de la répartition des coûts. Cependant, un rapport de répartition des coûts peut inclure n'importe quelle balise. Cela vous permet d'associer facilement des coûts à des aspects techniques ou de sécurité, tels que des applications, des environnements ou des programmes de conformité spécifiques.

Q : Comment voir quels coûts sont alloués à mes ressources AWS balisées ?

Vous pouvez voir quels coûts sont alloués à vos ressources AWS balisées via l'Explorateur de coûts ou votre rapport de répartition des coûts.

L'Explorateur de coûts est un outil AWS gratuit qui vous permet de consulter vos coûts des 13 derniers mois et de prévoir le montant de vos dépenses pour les trois prochains mois. Vous pouvez consulter les coûts associés à des balises spécifiques à l'aide du filtre « Tag », puis choisir la clé et la valeur de balise (sélectionnez l'option « No tag » si aucune valeur de balise n'est spécifiée).

Le rapport de répartition des coûts inclut tous vos coûts AWS correspondant à chaque période de facturation. Le rapport comprend les ressources balisées et non balisées pour vous permettre d'organiser clairement les frais associés aux ressources. Par exemple, si vous balisez des ressources avec le nom d'une application, vous pouvez suivre le coût total d'une application unique exécutée sur ces ressources. Pour plus d'informations sur la répartition des coûts, consultez le manuel AWS Billing and Cost Management User Guide.

Q : L'utilisation des flux DynamoDB peut-elle être balisée ?

Non, l'utilisation des flux DynamoDB ne peut pas être balisée pour le moment.

Q : L'utilisation des capacités réservées apparaîtra-t-elle sous mes balises de table sur ma facture ?

Oui, des frais DynamoDB applicables aux capacités réservées par table apparaîtront sous les balises correspondantes. Veuillez noter que les capacités réservées s'appliquent à l'utilisation de DynamoDB selon le principe du premier arrivé, premier servi, et sur tous les comptes AWS associés. Ainsi, si votre utilisation de DynamoDB entre les tables et index est similaire d'un mois sur l'autre, vous pouvez constater des différences sur vos rapports de répartition des coûts par balise, car les capacités réservées seront réparties en fonction des ressources DynamoDB mesurées en premier.

Q : Les frais d'utilisation de données apparaîtront-ils sous mes balises de table sur ma facture ?

Non, les frais d'utilisation de données DynamoDB ne sont pas balisés. En effet, l'utilisation des données est facturée au niveau du compte et non au niveau de la table.

Q : Mes balises nécessitent-elles un attribut de valeur ?

Non, les valeurs de balise peuvent être nulles.

Q : Les balises sont-elles sensibles à la casse ?

Oui, les clés et valeurs de balise sont sensibles à la casse.

Q : Combien de balises puis-je ajouter à une table DynamoDB ?

Vous pouvez ajouter jusqu'à 50 balises à une table DynamoDB. Les balises commençant par le préfixe « aws: » ne peuvent pas être créées manuellement et ne sont pas prises en compte dans la limite de balises par ressource.

Q : Puis-je appliquer des balises rétroactivement à mes tables DynamoDB ?

Non, les balises commencent à organiser et à suivre les données le jour où vous les appliquez. Si vous créez une table le 1er janvier, mais que vous ne lui attribuez une balise que le 1er février, l'utilisation de cette table au mois de janvier restera non balisée.

Q : Si je supprime une balise de ma table DynamoDB avant la fin du mois, cette balise apparaîtra-t-elle sur ma facture ?

Oui, si vous créez un rapport sur vos dépenses suivies pour une période déterminée, vos rapports de coûts afficheront les coûts des ressources qui ont été balisées pendant cette période.

Q : Que deviennent les balises existantes lorsqu'une table DynamoDB est supprimée ?

Lors de la suppression d'une table DynamoDB, ses balises sont automatiquement supprimées.

Q : Que se passe-t-il si j'ajoute une balise dont la clé est identique à celle d'une balise existante ?

Dans une table DynamoDB, deux balises ne peuvent pas être associées à la même clé. Si vous ajoutez une balise dont la clé est identique à celle d'une balise existante, cette dernière est mise à jour avec la nouvelle valeur.


Q : Qu'est-ce que la fonction de durée de vie (TTL) de DynamoDB ?

La fonction de durée de vie (TTL) de DynamoDB est un mécanisme permettant de définir une estampille temporelle précise pour la suppression des éléments contenus dans vos tables. Une fois l'estampille temporelle expirée, l'élément correspondant est considéré comme expiré, et il est ensuite supprimé de la table. Grâce à cette fonctionnalité, il n'est plus nécessaire de chercher et de supprimer manuellement les données arrivées à expiration. La fonction TTL permet de limiter l'espace de stockage utilisé et de réduire les coûts du stockage de données obsolètes.

Q : Pourquoi utiliser la fonction TTL ?

La fonction TTL est utile dans deux grands cas d'utilisation :

  • La suppression de données obsolètes (journaux d'événements, historique d'utilisation, données de session, etc.) qui s'accumulent progressivement sur le système, bien qu'elles ne soient plus nécessaires. Il vaut alors mieux supprimer ces données expirées et économiser le coût de leur stockage.
  • Il peut être nécessaire de conserver des données dans DynamoDB pendant une période donnée, afin de se conformer aux politiques de rétention et de gestion des données en vigueur. Il serait alors possible de supprimer ces données dès la fin de la période de rétention imposée. Cependant, gardez à l'esprit que la fonction TTL travaille au fur et à mesure en fonction des capacités, afin de réserver de la puissance de calcul pour les autres opérations critiques. DynamoDB tentera de supprimer les éléments expirés dans un délai de deux jours. Le délai réel peut être long en fonction de la taille des données.

Q : Comment fonctionne la fonction TLL pour DynamoDB ?

Pour activer la fonction TTL pour une table, commencez par vérifier l'existence d'un attribut pouvant stocker l'estampille temporelle d'expiration pour chaque élément de la table. Cette estampille doit être exprimée au format temporel epoch. Cette mesure a pour objectif d'éviter tout écart dû aux différences de fuseau horaire entre les clients et les serveurs.

DynamoDB analyse tous les éléments en arrière-plan. Si l'estampille temporelle a expiré, le processus désigne l'élément comme étant expiré et le place dans une file d'attente en vue de sa suppression future.

Remarque : la fonction TTL nécessite un attribut de table DynamoDB numérique contenant une estampille temporelle au format epoch pour spécifier la période d'expiration des données. Assurez-vous de saisir la bonne valeur pour l'attribut de la fonction TTL, car une valeur erronée pourrait provoquer la suppression de l'élément plus rapidement que souhaité.

Q : Comment activer la fonction TTL ?

Pour activer la fonction TTL, commencez par activer le paramètre TTL sur la table et par spécifier l'attribut qui servira de valeur TTL. Quand vous ajoutez des éléments à la table, vous pouvez spécifier un attribut TTL pour que DynamoDB les supprime automatiquement lorsqu'ils arrivent à expiration. Cette valeur correspond au délai d'expiration, exprimé au format temporel epoch. DynamoDB s'occupe du reste. La fonction TTL peut être activée depuis la console, dans l'onglet de vue d'ensemble de la table. Les développeurs ont également la possibilité d'invoquer l'API TTL pour configurer la fonction TTL pour la table. Consultez notre documentation et notre guide d'API.

Q : Puis-je activer la fonction TTL pour des tables existantes ?

Oui. Si une table a déjà été créée et possède un attribut pouvant être utilisé comme valeur TTL pour ses éléments, il suffit d'activer la fonction TTL pour la table et de désigner l'attribut approprié pour la fonction. Si la table ne possède pas d'attribut pouvant être utilisé pour la fonction TTL, vous devrez en créer un et mettre à jour les éléments avec les valeurs TTL.

Q : Puis-je supprimer une table dans son intégralité en définissant une fonction TTL pour toute la table ?

Non. Même s'il est nécessaire de définir un attribut TTL à l'échelle de la table, la granularité de suppression des données est calculée au niveau de chaque élément. Cela signifie que chaque élément devant être supprimé après son expiration dans une table doit être associé à une valeur définie pour l'attribut TTL. Aucune option de suppression de toute la table n'est disponible.

Q : Puis-je n'activer la fonction TTL que pour un sous-ensemble d'éléments dans une table ?

Oui. La fonction TTL est uniquement active pour les éléments présentant une valeur définie dans l'attribut TTL. Les autres éléments dans la table ne sont pas affectés.

Q : Quel est le format utilisé pour activer la fonction TTL ?

La valeur TTL doit être exprimée au format temporel epoch, qui correspond au nombre de secondes écoulées depuis le 1er janvier 1970 UTC. Si la valeur spécifiée dans l'attribut TTL pour un élément ne présente pas le bon format, elle est ignorée et l'élément n'est pas supprimé. 

Q : Comment puis-je lire la valeur TTL pour les éléments de ma table ?

La valeur TTL est semblable aux autres attributs d'un élément. Elle peut être lue de la même manière que les autres attributs. Afin de faciliter la confirmation visuelle des valeurs TTL, la console DynamoDB permet de survoler les attributs TTL avec le curseur pour en afficher l'équivalent dans le fuseau horaire local et le fuseau UTC.

Q : Puis-je créer un index basé sur les valeurs TTL attribuées aux éléments d'une table ?

Oui. La fonction TTL est semblable aux autres attributs d'un élément. Vous pouvez créer des index de la même manière que pour d'autres attributs.

Q : L'attribut TTL peut-il être projeté sur un index ?

Oui. Il est possible de projeter un attribut TTL sur un index, comme avec les autres attributs.

Q : Puis-je modifier une valeur d'attribut TTL ayant déjà été définie pour un élément ?

Oui. Vous pouvez modifier la valeur de l'attribut TTL comme pour n'importe quel autre attribut d'un élément.

Q : Puis-je modifier l'attribut TTL pour une table ?

Oui. Si la fonction TTL est déjà activée pour une table et que vous désirez spécifier un autre attribut TTL, vous devez commencer par désactiver la fonction TTL pour la table. Vous pouvez ensuite la réactiver avec un nouvel attribut TTL. La désactivation de la fonction TTL sur toutes les partitions peut prendre jusqu'à une heure et vous ne pourrez pas la réactiver tant que cette opération ne sera pas terminée.

Q : Puis-je utiliser AWS Management Console pour afficher et modifier les valeurs TTL ?

Oui. AWS Management Console permet d'afficher, de configurer et de modifier facilement les valeurs TTL.

Q : Puis-je définir un attribut dans un document JSON comme attribut TTL ?

Non. Il est actuellement impossible de définir un attribut dans un document JSON comme attribut TTL. Pour activer la fonction TTL, il faut ajouter explicitement l'attribut TTL à chaque élément.

Q : Puis-je activer la fonction TTL pour un élément spécifique dans un document JSON ?

Non. Les valeurs TTL ne peuvent être définies que pour le document dans son ensemble. Il est impossible de supprimer un élément spécifique arrivé à expiration dans un document JSON.

Q : Que faire si je dois désactiver la fonction TTL pour certains éléments ?

Pour désactiver la fonction TTL, il suffit de supprimer la valeur de l'attribut TTL ou de supprimer l'attribut en lui-même pour un élément.

Q : Que se passe-t-il si la valeur de l'estampille temporelle de TTL correspond à un instant dans le passé ?

La mise à jour des éléments présentant des valeurs TTL antérieures est autorisée. Quand le processus d'arrière-plan contrôle la présence d'éléments expirés, il identifie, marque et supprime les éléments concernés. Cependant, si la valeur de l'attribut TTL contient une valeur epoch pour une estampille temporelle située plus de 5 ans dans le passé, DynamoDB ignore l'estampille et l'élément n'est pas supprimé. Cela permet d'éviter toute suppression accidentelle d'éléments quand l'attribut TTL contient des valeurs particulièrement basses.

Q : Quel est le délai entre l'expiration de la valeur TTL pour un élément et la suppression effective de cet élément ?

La fonction TTL analyse et supprime les éléments expirés au moyen d'un processus exécuté en arrière-plan et reposant sur la capacité disponible dans le système. Il est donc possible que l'élément expiré ne soit pas immédiatement supprimé de la table. DynamoDB tente de supprimer les éléments expirés dans un délai de deux jours, en faisant au mieux en fonction des capacités disponibles, afin de garantir la disponibilité du système pour les autres opérations de données. Le délai exact avant la suppression d'un élément arrivé à expiration dépend de la nature de la charge et de la taille de la table.

Q : Que se passe-t-il si je tente d'interroger ou d'analyser des éléments désignés comme expirés par la fonction TTL ?

Il peut y avoir un délai entre l'expiration d'un élément et sa suppression par le processus en arrière-plan. Ainsi, si vous tentez de lire des éléments arrivés à expiration mais n'ayant pas encore été supprimés, les résultats renvoyés incluront les éléments expirés. Ces éléments peuvent être filtrés en fonction de la valeur TTL s'il n'est pas souhaitable de les voir affichés.

Q : Que se passe-t-il si les données de mon index secondaire local (LSI) sont expirées ?

L'effet est identique à celui d'une opération de suppression normale. L'index secondaire local est stocké dans la même partition que l'élément en lui-même. Si un élément est supprimé, il est donc immédiatement retiré de l'index secondaire local.

Q : Que se passe-t-il si les données de mon index secondaire global (GSI) sont expirées ?

L'effet est identique à celui d'une opération de suppression normale. Un index secondaire global (GSI) est cohérent à terme. Même si l'élément d'origine arrivé à expiration a été supprimé, il peut s'écouler un certain temps avant la mise à jour du GSI.

Q : Comment fonctionne la fonction TTL avec DynamoDB Streams ?

L'expiration des données dans une table suite au déclenchement d'une purge par la valeur TTL est enregistrée comme une opération de suppression. Par conséquent, la fonction Streams comportera également l'opération de suppression. Cette opération est associée à un qualificatif supplémentaire, afin de distinguer vos propres suppressions et celles exécutées par la fonction TTL. L'entrée de flux sera créée au moment de la suppression et non pas au point d'expiration de la fonction TTL, afin de correspondre à l'heure de suppression exacte de l'enregistrement. Consultez notre documentation et notre guide d'API.

Q : Quand est-il plus intéressant d'utiliser une opération de suppression au lieu de la fonction TTL ?

La fonction TTL est idéale pour supprimer des éléments expirés dans une table. Cependant, elle est conçue pour fonctionner au mieux et vous aider dans la suppression des données indésirées, sans fournir de garantie sur les délais de suppression. Par conséquent, si des données de votre table doivent être supprimées dans un délai bien précis (ou instantanément, comme dans la plupart des cas), nous recommandons d'exécuter la commande de suppression.

Q : Puis-je contrôler les personnes pouvant configurer ou mettre à jour la valeur TTL ?

Oui. L'attribut TTL fonctionne comme les autres attributs d'une table. Vous pouvez contrôler l'accès à chaque attribut dans une table. L'attribut TTL applique les politiques de contrôle d'accès en vigueur pour la table.

Q : Est-il possible de récupérer des données expirées et supprimées par la fonction TTL ?

Non. Les éléments expirés ne sont pas sauvegardés avant leur suppression. La fonction DynamoDB Streams peut être utilisée pour suivre les modifications apportées à une table et restaurer les valeurs si nécessaire. L'acte de suppression est accessible dans Streams pendant 24 heures après la suppression de l'élément.

Q : Comment savoir si la fonction TTL est activée dans une table ?

Le statut de la fonction TTL peut être consulté à tout moment en invoquant l'API DescribeTable ou en affichant les détails de la table dans la console DynamoDB. Consultez notre documentation et notre guide d'API.

Q : Comment suivre les éléments supprimés par TTL ?

Si la fonction DynamoDB Streams est activée, toutes les suppressions réalisées par la fonction TTL apparaissent dans les flux DynamoDB et sont désignées comme étant réalisées par le système, afin de les distinguer des suppressions que vous avez exécutées vous-même. Les éléments peuvent être lus et traités depuis les flux si nécessaire. Il est également possible d'écrire une fonction Lambda pour archiver l'élément séparément. Consultez notre documentation et notre guide d'API.

Q : Dois-je payer des frais spécifiques pour activer la fonction TTL pour mes données ?

Non. L'activation de la fonction TTL n'entraîne pas de frais supplémentaires.

Q : Quel est l'impact de l'activation de la fonction TTL sur mon débit provisionné ?

Les opérations d'analyse et de suppression nécessaires pour la fonction TTL sont exécutées par le système et ne sont pas comptabilisées dans votre débit provisionné.

Q : Dois-je payer pour les opérations d'analyse exécutées par la fonction TTL ?

Non. Les opérations d'analyse internes servant à identifier les éléments expirés ne vous sont pas facturées. De plus, ces opérations n'affectent pas votre débit provisionné pour la table.

Q : Les éléments expirés font-ils l'objet de frais de stockage avant leur suppression ?

Oui. Quand un élément est arrivé à expiration, il est ajouté à la file d'attente de suppression en attendant d'être supprimé. Cependant, avant cette suppression, il est considéré comme un élément normal pouvant être lu ou mis à jour, et il fait donc l'objet de frais de stockage.

Q : Les requêtes pour des éléments expirés sont-elles comptabilisées dans ma capacité de lecture ?

Oui. Ce comportement est similaire aux envois de requêtes pour des éléments n'existant pas dans une table.


Q : Qu'est-ce qu'Amazon DynamoDB Accelerator (DAX) ?

Amazon DynamoDB Accelerator (DAX) est un cache en mémoire entièrement géré et hautement disponible pour DynamoDB qui vous permet de bénéficier de performances en mémoire rapides pour les applications exigeantes. DAX améliore les performances des charges de travail DynamoDB qui demandent beaucoup d'opérations de lecture, si bien que la lecture répétée des données mises en cache peut être traitée immédiatement avec une latence très faible sans qu'il soit nécessaire d'adresser une nouvelle requête à DynamoDB. DAX récupère automatiquement les données dans les tables DynamoDB en cas de défaut de cache. Les écritures sont dites simultanées (les données sont d'abord écrites dans DynamoDB et ensuite mises à jour dans le cache).

A l'instar de DynamoDB, DAX est tolérant aux pannes et évolutif. Un cluster DAX est constitué d'un nœud principal et de plusieurs nœuds de réplica en lecture (le cas échéant). En cas de panne du nœud principal, DAX bascule automatiquement et choisit un nouveau nœud principal. Vous pouvez ajouter ou retirer des réplicas en lecture à des fins de dimensionnement.

Pour commencer, créez un cluster DAX et téléchargez le kit SDK DAX pour Java ou Node.js (compatible avec les API DynamoDB). Modifiez votre application de sorte qu'elle utilise le client DAX plutôt que le client DynamoDB. Enfin, faites pointer le client DAX vers le point de terminaison du cluster DAX. Vous n'avez pas besoin de mettre en place une logique de mise en cache supplémentaire dans votre application, car le client DAX met en œuvre les mêmes appels d'API que DynamoDB.

Q : Que signifie « compatible avec DynamoDB » ?

Cela signifie que la majeure partie du code, des applications et des outils que vous utilisez déjà aujourd'hui avec DynamoDB peut être utilisée avec DAX avec peu ou pas de modifications. Le moteur DAX est conçu pour prendre en charge les API DynamoDB pour la lecture et la modification des données dans DynamoDB. Les opérations de gestion des tables telles que CreateTable/DescribeTable/UpdateTable/DeleteTable ne sont pas prises en charge.

Q : En quoi consiste la mise en cache en mémoire et quel en est l'intérêt pour mes applications ?

La mise en cache permet d'améliorer les performances des applications en stockant dans la mémoire les données critiques afin d'offrir un accès à faible latence et à débit élevé. Dans le cas de DAX, le résultat des opérations DynamoDB est mis en cache. Lorsqu'une application demande des données stockées dans le cache, DAX peut fournir ces données immédiatement sans avoir à exécuter une requête sur les tables DynamoDB standard. Les données sont datées ou expulsées de DAX en spécifiant une valeur de durée de vie (TTL) pour les données ou, une fois que toute la mémoire disponible est épuisée, les éléments sont expulsés selon l'algorithme LRU (moins récemment utilisé).

Q : En quoi consiste le modèle de cohérence de DAX ?

Lorsque les données sont lues à partir de DAX, les utilisateurs peuvent indiquer s'ils souhaitent que la lecture soit cohérente à terme ou à cohérence forte :

Lectures cohérentes à terme (par défaut) : l'option de cohérence à terme permet d'optimiser le débit de lecture et de limiter la latence. En cas de succès de cache, le client DAX retourne directement le résultat du cache. En cas de défaut de cache, DAX interroge DynamoDB, met à jour le cache, puis retourne le jeu de résultats. Il est à noter qu'une lecture cohérente à terme peut ne pas refléter les résultats d'une écriture réalisée récemment. Si votre application a besoin d'une cohérence totale, nous vous suggérons d'utiliser des lectures à cohérence forte.

Lectures à cohérence forte : outre la cohérence à terme, DAX vous offre également la possibilité et la souplesse de demander une lecture à cohérence forte si votre application, ou un élément de celle-ci, le nécessite. Une lecture à cohérence forte contourne DAX, ne met pas en cache les résultats dans DAX et retourne un résultat qui reflète toutes les écritures ayant reçu une réponse positive dans DynamoDB avant la lecture.

Q : Quels sont les cas d'utilisation courants pour DAX ?

DAX peut être utilisé dans de nombreux cas qui ne sont pas mutuellement exclusifs :

Les applications qui ont besoin des temps de réponse les plus rapides possible pour les opérations de lecture. C'est notamment le cas des applications d'enchères en temps réel, de jeux sociaux et de trading. DAX offre des performances de lecture en mémoire élevées pour ces cas d'utilisation.

Les applications qui lisent un petit nombre d'éléments plus souvent que d'autres. Prenons l'exemple d'un système d'e-commerce qui propose une promotion d'un jour pour un produit à succès. Pendant la durée de promotion, la demande pour ce produit (et ses données dans DynamoDB) augmente brusquement par rapport à celle de tous les autres produits. Pour limiter les conséquences de la forte activité et d'une distribution de données non uniforme, vous pouvez décharger l'activité de lecture sur un cache DAX jusqu'à ce que la promotion d'un jour se termine.

Les applications qui demandent beaucoup d'opérations de lecture, mais qui sont également sensibles aux coûts. Avec DynamoDB, vous allouez le nombre d'opérations de lecture par seconde dont a besoin votre application. Si l'activité de lecture s'accroît, vous pouvez augmenter le débit de lecture alloué de votre table (moyennant un coût supplémentaire). Il est également possible de décharger l'activité de votre application sur un cluster DAX et de réduire le nombre d'unités de capacité de lecture que vous auriez normalement achetées.

Les applications qui imposent des opérations de lecture à répétition dans un ensemble de données volumineux. Une application de ce type peut potentiellement détourner les ressources de base de données d'autres applications. Par exemple, une analyse prolongée de données météorologiques régionales pourrait consommer temporairement toutes les capacités de lecture dans une table DynamoDB, ce qui aurait un impact négatif sur les autres applications qui ont besoin d'accéder à ces mêmes données. Avec DAX, l'analyse météorologique peut être effectuée sur des données mises en cache.

Fonctionnement

Q : Quelles sont les opérations gérées par DAX à ma place ?

DAX est un cache entièrement géré pour DynamoDB. Il assure le travail qui a trait à la configuration de nœuds de mise en cache dédiés, de l'allocation des ressources serveur jusqu'à l'installation du logiciel DAX. Une fois que votre cluster de cache DAX est configuré et opérationnel, le service automatise les tâches d'administration courantes, telles que la détection des défaillances, la reprise ou encore l'application de correctifs logiciels. DAX fournit des métriques CloudWatch de surveillance détaillées liées à votre cluster, ce qui vous permet de diagnostiquer les problèmes et de réagir rapidement. Avec ces métriques, vous pouvez paramétrer des seuils pour déclencher des alarmes CloudWatch. DAX gère toutes les opérations de mise en cache, d'extraction et d'expulsion de données à la place de votre application. Vous pouvez simplement utiliser l'API DynamoDB pour écrire et extraire des données. DAX gère alors toute la logique de mise en cache en arrière-plan pour offrir des performances accrues.

Q : Quels sont les types de données mis en cache par DAX ?

Tous les appels d'API de lecture sont mis en cache par DAX. Les demandes de lecture à cohérence forte sont lues directement à partir de DynamoDB, tandis que les demandes de lecture cohérentes à terme sont lues à partir de DAX si l'élément est disponible. Les appels d'API d'écriture sont à écriture simultanée (écriture synchrone dans DynamoDB qui est mise à jour dans le cache après qu'une écriture aboutit).

Les appels d'API suivants donnent lieu à un examen du cache. En cas de succès, l'élément est retourné. En cas de défaut, la demande est transmise, et une fois l'extraction réussie, le résultat est mis en cache puis retourné.

• GetItem
• BatchGetItem
• Query
• Scan

Les appels d'API suivants sont des opérations à écriture simultanée.

• BatchWriteItem
• UpdateItem
• DeleteItem
• PutItem

Q : Comment les expulsions de données sont-elles traitées par DAX ?

DAX traite les expulsions de données de trois manières différentes. Premièrement, le service utilise une valeur de durée de vie (TTL) qui indique la durée absolue durant laquelle un élément est disponible dans le cache. Deuxièmement, lorsque le cache est plein, un cluster DAX utilise un algorithme LRU (moins récemment utilisé) pour décider quels éléments expulser. Troisièmement, grâce à la fonctionnalité d'écriture simultanée, DAX expulse les anciennes valeurs lors de l'écriture de nouvelles. Ainsi, les éléments du cache de DAX restent cohérents avec le magasin de données sous-jacent lors de l'utilisation d'un appel d'API.

Q : Est-ce que DAX fonctionne avec les index secondaires globaux et locaux de DynamoDB ?

DAX met en cache les jeux de résultats des opérations d'interrogation et d'analyse réalisées sur les index secondaires globaux et locaux de DynamoDB, comme pour les tables DynamoDB.

Q : Comment les jeux de résultats des requêtes Query et Scan sont-ils gérés par DAX ?

Au sein d'un cluster DAX, il existe deux caches différents : le cache d'élément et le cache de requête. Le cache d'élément gère les requêtes GetItem, PutItem, et DeleteItem pour les paires clé-valeur individuelles. Le cache de requête gère les jeux de résultats des requêtes Scan et Query. A cet égard, le texte de la requête Scan/Query constitue la clé et le résultat représente la valeur. Même si les deux caches sont gérés dans le même cluster (et vous pouvez indiquer des valeurs TTL différentes pour chaque cache), ils ne se superposent pas. Par exemple, une analyse d'une table ne remplit pas le cache d'élément, mais elle enregistre à la place une entrée dans le cache de requête qui stocke le jeu de résultats de l'analyse.

Q : Est-ce qu'une mise à jour du cache d'élément entraîne la mise à jour ou l'invalidation des jeux de résultats de mon cache de requête ?

Non. Le meilleur moyen pour minimiser les incohérences entre les jeux de résultats dans le cache d'élément et dans le cache de requête est de configurer la valeur TTL du cache de requête sur une durée acceptable pendant laquelle votre application peut gérer de telles incohérences.

Q : Est-ce que je peux me connecter à mon cluster DAX depuis l'extérieur de mon VPC ?

Le seul moyen de vous connecter à votre cluster DAX depuis l'extérieur de votre VPC est de passer par une connexion VPN.

Q : Lors de l'utilisation de DAX, que se passe-t-il si mes tables DynamoDB sous-jacentes sont restreintes ?

Si le service DAX est en train de lire ou d'écrire dans une table DynamoDB et qu'il reçoit une exception de limitation, DAX retourne cette exception au client DAX. Puis, le service DAX ne fait pas de nouvelle tentative côté serveur.

Q : Est-ce que DAX prend en charge la préparation du cache ?

DAX utilise le chargement différé pour remplir le cache. Cela signifie que lors de la première lecture d'un élément, DAX récupère l'élément depuis DynamoDB, puis remplit le cache. Alors que DAX ne prend pas en charge la préparation du cache comme une fonction, le cache DAX peut être préparé pour une application en exécutant un script ou une application externe qui lit les données voulues.

Q : Comment la fonction TTL de DynamoDB est-elle prise en charge par DAX ?

DynamoDB et DAX disposent tous deux d'une fonction TTL (ou durée de vie). Dans le cas de DynamoDB, la TTL est une fonction qui permet aux clients de supprimer leurs données vieillissantes en balisant celles-ci avec un attribut particulier et l'horodatage correspondant. Par exemple, si les clients veulent que leurs données soient supprimées lorsqu'elles sont vieilles d'un mois, ils utilisent la fonction TTL de DynamoDB afin de réaliser cette tâche au lieu de gérer eux-mêmes les processus de vieillissement.

Dans le cas de DAX, la TTL indique la période pendant laquelle un élément en cache est valide. Par exemple, si une TTL est paramétrée sur 5 minutes, une fois que l'élément a été transféré dans le cache, il continue d'être valide et servi depuis le cache jusqu'à ce que la période de 5 minutes touche à sa fin. Bien que cela ne soit pas le sujet, nous souhaitons souligner le fait que la TTL peut être anticipée par les écritures sur le cache pour le même élément ou si la mémoire sur le nœud DAX est particulièrement sollicitée et que l'algorithme LRU éjecte les éléments car il s'agit des éléments les moins récemment utilisés.

Bien que les TTL pour DynamoDB et DAX fonctionnent généralement sur des échelles de temps très différentes (par exemple, la TTL de DAX s'exécute dans une optique minutes/heures, tandis que celle de DynamoDB s'exécute dans une optique semaines/mois/années), il est possible que ces deux fonctionnalités s'affectent mutuellement. Par exemple, imaginons que la valeur TTL de DynamoDB est inférieure à la valeur TTL de DAX. Dans ce scénario, un élément peut tout à fait être mis en cache dans DAX, puis être supprimé de DynamoDB par la fonction TTL de DynamoDB. Il en résulte alors un cache incohérent. Bien que ce scénario n'est pas censé se produire souvent, étant donné les échelles de temps des deux fonctionnalités sont généralement clairement différentes, il est utile de connaître le lien entre ces deux fonctionnalités.

Q : Est-ce que DAX prend en charge la réplication entre régions ?

Actuellement, DAX prend en charge uniquement les tables DynamoDB se trouvant dans la même région AWS que le cluster DAX.

Q : Le service DAX est-il pris en charge en tant que type de ressource dans AWS CloudFormation ?

Oui. Vous pouvez créer, mettre à jour et supprimer des clusters DAX, des groupes de paramètres et des groupes de sous-réseaux à l'aide d'AWS CloudFormation.

Mise en route

Q : Comment démarrer avec le service DAX ?
Vous pouvez créer un nouveau cluster DAX en passant par la console AWS ou le kit SDK AWS afin d'obtenir le point de terminaison du cluster DAX. Un client compatible avec DAX doit alors être téléchargé et utilisé dans l'application avec le nouveau point de terminaison DAX.

Q : Comment créer un cluster DAX ?

Vous pouvez créer un cluster DAX à l'aide de la console AWS ou de l'interface de ligne de commande DAX. Les clusters DAX vont d'un cache de 13 Go (dax.r3.large) à 216 Go (dax.r3.8xlarge) dans les types d'instances R3, et d'un cache de 15,25 Go (dax.r4.large) à 488 Go (dax.r4.16xlarge) dans les types d'instances R4. Moyennant quelques clics dans la console AWS ou un simple appel d'API, vous pouvez ajouter des réplicas supplémentaires à votre cluster (jusqu'à 10 réplicas) pour bénéficier d'un débit accru.

La configuration à un seul nœud vous permet de démarrer avec DAX de façon rapide et économique. Il vous suffit par la suite de passer à une configuration à plusieurs nœuds dès que vos besoins évoluent. La configuration à plusieurs nœuds s'appuie sur un nœud principal pour gérer les écritures et sur un maximum de neuf nœuds de réplica en lecture. Le nœud principal est alloué automatiquement.

Il vous suffit de spécifier vos groupes de sous-réseaux/zones de disponibilité (facultatif) préférés, le nombre de nœuds, les types de nœuds, le groupe de sous-réseaux VPC et d'autres paramètres système. Une fois que vous avez choisi la configuration souhaitée, DAX alloue les ressources nécessaires et configure votre cluster de mise en cache spécialement pour DynamoDB.

Q : Faut-il que toutes mes données puissent être stockées en mémoire en même temps pour pouvoir utiliser DAX ?

Non. DAX utilise la mémoire disponible du nœud. En utilisant la TTL et/ou le LRU, les éléments sont expulsés pour faire de la place pour les nouvelles données lorsque l'espace mémoire est plein.

Q : Quels sont les langages pris en charge par DAX ?

DAX fournit des kits SDK DAX pour Java et Node.js téléchargeables dès aujourd'hui. Nous travaillons sur la prise en charge de clients supplémentaires.

Q : Est-il possible d'utiliser DAX et DynamoDB en même temps ?

Oui, vous pouvez accéder simultanément au point de terminaison DAX et au service DynamoDB via différents clients. Toutefois, DAX ne peut pas détecter les modifications apportées aux données écrites directement dans DynamoDB, à moins que ces modifications soient explicitement saisies dans DAX via une opération de lecture des données modifiées après une mise à jour effectuée directement dans DynamoDB.

Q : Est-il possible d'utiliser plusieurs clusters DAX pour une même table DynamoDB ?

Oui, vous pouvez allouer plusieurs clusters DAX pour une même table DynamoDB. Ces clusters proposent différents points de terminaison pour différents cas d'utilisation potentiels, assurant ainsi une mise en cache optimale pour chaque scénario. Sachant que deux clusters DAX sont indépendants l'un de l'autre et ne partagent pas leur état ou leurs mises à jour, les utilisateurs ont tout intérêt à les utiliser pour des tables complètement différentes.

Q : Quel type de nœud DAX choisir pour une charge de travail donnée ?

Le dimensionnement d'un cluster DAX est un processus itératif. Il est recommandé d'allouer un cluster à trois nœuds (pour bénéficier d'une haute disponibilité) avec une quantité de mémoire suffisante pour mettre en mémoire l'ensemble actif de l'application. Selon les performances et le débit de l'application, l'utilisation du cluster DAX et le rapport entre les succès et les défauts de cache, vous pouvez être amené à dimensionner votre cluster DAX de façon à parvenir aux résultats escomptés.

Q : Sur quels types d'instances EC2 le service DAX peut-il s'exécuter ?

Les types de nœuds valides sont les suivants :

R3 : 

• dax.r3.large (13 Gio)
• dax.r3.xlarge (26 Gio)
• dax.r3.2xlarge (54 Gio)
• dax.r3.4xlarge (108 Gio)
• dax.r3.8xlarge (216 Gio)

R4 :

• dax.r4.large (15,25 Go)
• dax.r4.xlarge (30,5 Go)
• dax.r4.2xlarge (61 Go)
• dax.r4.4xlarge (122 Go)
• dax.r4.8xlarge (244 Go)
• dax.r4.16xlarge (488 Go)

Q : Le service DAX prend-il en charge les instances réservées ou le niveau d'offre gratuite d'AWS ?

A l'heure actuelle, DAX prend uniquement en charge les instances à la demande.

Q : Comment le service DAX est-il facturé ?

La tarification de DAX est basée sur le nombre d'heures de nœud consommées entre le moment où le nœud est lancé et le moment où il est arrêté. Chaque heure de nœud partielle consommée est facturée en tant qu'heure entière. La tarification s'applique à tous les nœuds du cluster DAX. Par exemple, si vous possédez un cluster DAX à trois nœuds, vous serez facturé pour chacun des nœuds séparés (trois nœuds au total) sur une base horaire.

Disponibilité

Q : Comment bénéficier d'une haute disponibilité sur mon cluster DAX ?

DAX prend en charge les configurations multi-AZ, ce qui vous permet de choisir les zones de disponibilité préférées pour les nœuds de votre cluster DAX. DAX utilise une réplication asynchrone pour assurer une cohérence entre les nœuds. Ainsi, en cas de défaillance d'un nœud, les demandes peuvent être traitées par un autre nœud. Pour bénéficier d'une haute disponibilité dans votre cluster DAX, à la fois lors des interruptions prévues et des interruptions imprévues, nous vous recommandons de déployer au moins trois nœuds dans trois zones de disponibilité distinctes. Chaque zone de disponibilité est exécutée sur sa propre infrastructure indépendante et physiquement distincte et est conçue pour offrir une grande fiabilité.

Q : Que se passe-t-il lorsqu'un nœud DAX est défaillant ?

Si une défaillance touche le nœud principal, DAX détecte la panne automatiquement et choisit le nouveau nœud principal parmi les réplicas en lecture disponibles. Par ailleurs, DAX alloue un nouveau nœud dans la zone de disponibilité du nœud principal défaillant. Ce nouveau nœud remplace le réplica en lecture nouvellement promu. Si la défaillance du nœud principal est due à une interruption provisoire de la zone de disponibilité, le nouveau réplica est lancé aussitôt que la zone de disponibilité est rétablie. Lorsqu'une défaillance se produit dans un cluster à un seul nœud, DAX lance un nouveau nœud dans la même zone de disponibilité.

Evolutivité

Q : Quel type de dimensionnement le service DAX prend-il en charge ?

DAX prend actuellement en charge deux options de dimensionnement. La première option est le dimensionnement en lecture, qui vise à offrir un débit supérieur en ajoutant des réplicas en lecture à un cluster. Un cluster DAX unique prend en charge jusqu'à 10 nœuds, ce qui représente plusieurs millions de demandes par seconde. L'ajout ou le retrait de réplicas est une opération en ligne. La deuxième façon de mettre à l'échelle un cluster est d'ajuster la capacité à la hausse ou à la baisse en choisissant des types d'instances r3 plus grands ou plus petits. Les nœuds de grande taille permettent au cluster de stocker une plus grande partie de l'ensemble de données de l'application, ce qui limite les défauts de cache et améliore les performances globales de l'application. Lorsque vous créez un cluster DAX, veillez à ce que tous les nœuds du cluster aient le même type d'instance. Par ailleurs, si vous souhaitez modifier le type d'instance de votre cluster DAX (par exemple, pour passer de r3.large à r3.2xlarge), vous devez créer un nouveau cluster DAX avec le type d'instance souhaité. Pour l'heure, DAX ne prend pas en charge les opérations d'augmentation et de diminution de la capacité en ligne.

Q : Comment dimensionner la capacité d'écriture de mon application ?

Dans un cluster DAX, seul le nœud principal gère les opérations d'écriture dans DynamoDB. Par conséquent, l'ajout de nœuds au cluster DAX augmente le débit de lecture, mais pas le débit d'écriture. Pour augmenter le débit d'écriture pour votre application, vous devez réaliser une mise à l'échelle vers une instance plus grande ou allouer plusieurs clusters DAX et partitionner votre espace clé dans la couche de l'application.

Surveillance

Q : Comment surveiller les performances de mon cluster DAX ?
Les métriques d'utilisation du CPU, du nombre de succès/défauts de cache et de trafic de lecture/écriture dans votre cluster DAX sont disponibles via AWS Management Console ou les API Amazon CloudWatch. Vous pouvez également ajouter des métriques supplémentaires que vous aurez définies via la fonctionnalité de métriques personnalisées d'Amazon CloudWatch. Outre les métriques CloudWatch, DAX fournit également des informations sur les succès et les défauts de cache et les performances des requêtes et du cluster via AWS Management Console.

Maintenance

Q : Qu'est-ce qu'une fenêtre de maintenance ? Mon cluster DAX sera-t-il disponible lors d'une opération de maintenance logicielle ?

Vous pouvez considérer le créneau de maintenance DAX comme une occasion de contrôler le moment où les modifications sont apportées au cluster (par exemple, l'application de correctifs logiciels). Si un événement de maintenance est planifié pour une semaine donnée, il sera déclenché et effectué à un moment donné au cours de la fenêtre de maintenance que vous identifiez.

La correction requise est planifiée automatiquement et uniquement pour les correctifs en rapport avec la sécurité et la fiabilité. Ce type de correctif est moins fréquent (en général, une fois tous les deux/trois mois). Si vous ne spécifiez pas de fenêtre de maintenance hebdomadaire préférée lors de la création de votre cluster, une valeur par défaut est assignée. Si vous souhaitez changer le moment où la maintenance est effectuée en votre nom, vous pouvez le faire en modifiant votre cluster dans AWS Management Console ou avec l'API UpdateCluster. Chacun de vos clusters peut avoir des fenêtres de maintenance préférées différentes.

Pour des clusters de plusieurs nœuds, les mises à jour dans le cluster sont réalisées en série. Un seul nœud est mis à jour à la fois. Une fois que le nœud a été mis à jour, il se synchronise avec l'un des pairs dans le clusters, pour que le nœud dispose du jeu de données actuellement actif. Pour un cluster à un seul nœud, nous fournissons un réplica (qui ne vous est pas facturé) que nous synchronisons avec les dernières données, puis nous réalisons un basculement pour que le nouveau réplica devienne le nœud principal. De cette façon, vous ne perdez aucune donnée durant la mise à niveau d'un cluster à un seul nœud.  

Q : Quels sont les points de terminaison de VPC pour DynamoDB (VPCE pour DynamoDB) ?

Amazon Virtual Private Cloud (VPC) est un service AWS proposant aux utilisateurs un cloud virtuel privé en allouant une section logiquement isolée du cloud d’Amazon Web Services (AWS). Le point de terminaison de VPC (VPCE) pour DynamoDB est une entité logique d’un VPC qui crée une connexion privée entre un VPC et DynamoDB, sans requérir d’accès par Internet, par l’intermédiaire d’un dispositif NAS ou d’une connexion VPN. Pour en savoir plus sur les points de terminaison de VPC, consultez le Guide de l’utilisateur d’Amazon VPC.

Q : Pourquoi utiliser le VPCE pour DynamoDB ?

Par le passé, le moyen principal d’accéder à DynamoDB à partir d’un VPC se faisait pas Internet, ce qui pouvait nécessiter des configurations complexes comme des pare-feux ou des VPN. Les points de terminaison de VPC pour DynamoDB améliorent la confidentialité et la sécurité pour les clients, en particulier les points de terminaison traitant de charges de travail sensibles avec des exigences en matière de conformité et d’audit, en autorisant un accès privé au sein d’un VPC sans le besoin d’une passerelle Internet ou NAT. De plus, les points de terminaison de VPC pour DynamoDB prennent en charge les politiques d’AWS Identity and Access Management (IAM) pour simplifier le contrôle d’accès à DynamoDB pour que vous puissiez restreindre en toute simplicité l’accès à vos tables DynamoDB à un point de terminaison de VPC.

Q : Comment commencer à utiliser VPCE pour DynamoDB ?

Vous pouvez créer un VPCE pour DynamoDB en utilisant l’AWS Management Console, AWS SDK ou l’interface de ligne de commande (CLI) AWS. Vous devez spécifier le VPC et les tables de routage existantes dans le VPC, et décrire la politique IAM à joindre au point de terminaison. Un routage est automatiquement ajouté à chacun des tables de routage de VPC spécifié.

Q : Est-ce que les VPCE pour DynamoDB assurent que le trafic ne sera pas routé en dehors du réseau Amazon ?

Oui. Lorsque vous utilisez les VPCE pour DynamoDB, les paquets de données entre DynamoDB et VPC restent dans le réseau Amazon.

Q : Puis-je me connecter à une table DynamoDB d’une région différente de mon VPC à l’aide des VPCE pour DynamoDB ?

Non. Les points de terminaison de VPC ne peuvent être créés que pour des tables DynamoDB de la même région que le VPC.

Q : Est-ce que les VPCE pour DynamoDB limitent le débit vers DynamoDB ?

Non. Vous profiterez du même débit vers DynamoDB qu’aujourd’hui à partir d’une instance avec une IP publique au sein de votre VPC.

Q : Quel est le prix d’utilisation des VPCE pour DynamoDB ?

L’utilisation des VPCE pour DynamoDB n'entraîne aucun coût supplémentaire.

Q : Puis-je accéder à la fonction Flux de DynamoDB en utilisant des VPCE pour DynamoDB ?

A présent, vous ne pouvez pas accéder à la fonction Flux de DynamoDB en utilisant des VPCE pour DynamoDB.

Q : J’utilise actuellement une passerelle Internet et une passerelle NAT pour envoyer des requêtes à DynamoDB. Dois-je changer mon code d’application lorsque j’utilise un VPCE ?

Vous n’avez pas besoin de changer votre code d’application. Il vous suffit de créer un point de terminaison de VPC, de mettre à jour votre table de routage pour orienter le trafic de DynamoDB vers le VPCE de DynamoDB, puis d’accéder directement à DynamoDB. Vous pouvez continuer d’utiliser le même code et les mêmes noms de DNS pour accéder à DynamoDB.

Q : Puis-je utiliser un VPCE aussi bien pour DynamoDB que pour une autre service AWS ?

Non. Chaque VPCE prend en charge un seul service. Cela dit, vous pouvez en créer un pour DynamoDB et un autre pour l’autre service AWS, puis utiliser les deux dans une table de routage. 

Q : Puis-je avoir plusieurs points de terminaison de VPC dans un seul VPC ?

Oui. Vous pouvez avoir plusieurs points de terminaison de VPC dans un seul VPC. Par exemple, vous pouvez avoir un VPCE pour S3 et un VPCE pour DynamoDB.

Q : Puis-je avoir plusieurs VPCE pour DynamoDB dans un seul VPC ?

Oui. Vous pouvez avoir plusieurs VPCE pour DynamoDB dans un seul VPC. Chaque VPCE peut avoir des politiques de VPCE différentes. Par exemple, vous pourriez avoir un VPCE en lecture seule et un en lecture/écriture. Cela dit, une table de routage unique dans un VPC ne peut être associée qu’à un seul VPCE pour DynamoDB, du fait que la table de routage orientera tout le trafic vers DynamoDB au travers du VPCE spécifié.

Q : Quelles sont les différences entre un VPCE pour S3 et un VPCE pour DynamoDB ?

La principale différence réside dans le fait que ces deux VPCE prennent en charge des services différents, ici S3 et DynamoDB.

Q : Quelle adresse IP verrai-je dans les journaux d’AWS CloudTrail pour le trafic provenant du VPCE pour DynamoDB ?

Les journaux d’AWS CloudTrail pour DynamoDB contiendront l’adresse IP privée de l’instance EC2 du VPC et l’identifiant VPCE (par exemple, sourceIpAddress=10.89.76.54, VpcEndpointId=vpce-12345678).

Q : Comment puis-je gérer les VPCE avec l'interface de ligne de commande (CLI) AWS ?

Pour gérer les VPCE, vous pouvez utiliser les commandes CLI suivantes : create-vpc-endpoint, modify-vpc-endpoint, describe-vpc-endpoints, delete-vpc-endpoint et descrive-vpc-endpoint-services. Vous devez spécifier le nom de service DynamoDB spécifique pour la région de votre VPC et de DynamoDB, par exemple, ‘com.amazon.us.east-1.DynamoDB’. Vous trouverez des informations supplémentaires ici.

Q : Est-ce que les clients doivent connaître et gérer les adresses IP publiques de DynamoDB pour les VPCE pour DynamoDB ?

Non. Les clients ne sont pas obligés de connaître ou gérer les plages d’adresses IP publiques de DynamoDB pour utiliser cette fonctionnalité. Une liste de préfixes sera fournie pour utiliser les tables de routage et les groupes de sécurité. AWS conserve les plages d’adresse dans la liste. Le nom de la liste de préfixes est com.amazonaws. .DynamoDB. Par exemple : com.amazonaws.us-east-1.DynamoDB.

Q : Puis-je utiliser des politiques IAM sur un VPCE pour DynamoDB ?

Oui. Vous pouvez joindre une politique IAM à votre VPCE. Ainsi, cette politique s’appliquera à tout le trafic passant par ce point de terminaison. Par exemple, un VPCE utilisant cette politique ne permet que de décrire* des appels d’API :
{
    "Statement":  [
       {
            "Sid": "Stmt1415116195105",
            "Action": "dynamodb:describe*",
            "Effect":"Allow",
            "Resource": "arn:aws:dynamodb:region:account-id:table/table-name",
            "Principal": "*"
        }
    ]
}

Q : Puis-je limiter l’accès à ma table DynamoDB à partir d’un point de terminaison de VPC ?

Oui. Vous pouvez créer une politique IAM pour restreindre un utilisateur, un groupe ou un rôle IAM à un VPCE particulier pour des tables DynamoDB.

Pour cela, il faut configurer l’élément Resource de la politique IAM vers une table DynamoDB et la clé de l’élément Condition vers aws:sourceVpce. Vous trouverez plus d’informations dans le Guide de l’utilisateur IAM.

Par exemple, la politique IAM suivante restreint l’accès aux tables DynamoDB à moins que sourceVpce ne corresponde à “vpce-111bbb22”

{
    "Statement":  [
       {
            "Sid": "Stmt1415116195105",
            "Action": "dynamodb:*",
            "Effect": "Deny",
            "Resource": "arn:aws:dynamodb:region:account-id:*",
            "Condition": { "StringNotEquals" : { "aws:sourceVpce": "vpce-111bbb22" } }
        }
    ]
}

Q : Est-ce que les VPCE pour DynamoDB prennent en charge les conditions de politique IAM pour le contrôle précis des accès (FGAC) ?

Oui. Les VPCE pour DynamoDB prennent en charge toutes les clés d’accès FGAC. Vous pouvez utiliser les conditions de politique IAM pour le FGAC afin de contrôler l’accès aux éléments et aux attributs de données individuels. Vous trouverez des informations supplémentaires sur le FGAC ici.

Q : Puis-je utiliser le générateur de politique AWS pour créer des politiques de point de terminaison de VPC ou DynamoDB ?

Vous pouvez utiliser le générateur de politique AWS pour créer vos politiques de point de terminaison de VPC.

Q : Est-ce que DynamoDB prend en charge les politiques basées sur les ressources, semblables aux politiques de compartiment S3 ?

Non. DynamoDB ne prend pas en charge les politiques basées sur les ressources se rapportant à des tables ou des éléments individuels, etc.