Disons que j'ai une table utilisateur avec Quels sont les avantages et les inconvénients de chaque approche? ID et horodatamp attributs. Je voudrais pouvoir interroger sur les deux paramètres. Si je comprends correctement la documentation, il y a deux façons de le faire avec Dynamodb:
ID en tant que hachage et horodatage comme plage.
horodatage .
3 Réponses :
Cette réponse peut être d'une certaine utilisation, mais vous " re droite sur les deux manières que vous pourriez y accomplir.
En supposant que vous utilisiez L'inconvénient principal de l'utilisation d'un indice secondaire global est que vous aurez besoin d'un débit approvisionné supplémentaire sur la table. ID comme clé de hachage, alors afin de récupérer un élément en utilisant uniquement un horodatage, vous aurez besoin d'un index secondaire global. Vous pouvez toujours faire de horodatage votre clé de gamme, qui sera utile dans cette dynamodb l'utilisera pour trier les résultats de vos requêtes par ID .
Voulez-vous dire que même si je dispose de la combinaison de clés de plage de hachage +, si je veux interroger uniquement la clé de la plage, je dois toujours définir la clé de la plage en tant qu'index secondaire global?
@batmaci - Oui, chaque fois que vous souhaitez effectuer une requête dans DynamoDB, vous devez spécifier la clé de hachage, que ce soit la clé de hachage principale de la table ou une clé de hachage d'index. Pensez à Dynamodb en tant que table de hachage - si vous n'avez pas la clé, vous devez rechercher toute la table.
Définissez une clé primaire de la plage de hachage + à l'aide de l'identifiant comme hayes et horodatage comme la gamme. P>
en faisant
id code> la touche code> clé code> ethorodatage code> la touche de plagecode>, vous créez efficacement un 'composite clé primaire'. p>Dans les mots de commande, votre schéma DynamoDB permettrait aux données suivantes (remarquez que 'John' est répété trois fois) p>
xxx pré> et vous pouvez exécuter ces Opérations: P>
getItem code> Pour obtenir un seul élément en fonction de l'identifiant code> (clé de hachage) +horodatage code> (touche de gamme) (clé de gamme) li>Query code> Pour obtenir une liste de tous les éléments égaux auID code> (clé de hachage) li> OL>Si ce n'est pas ce que vous avez destiné, alors hachage + gamme sur
ID code> ethorodatage code> n'est pas ce que vous recherchez. P >Définissez une clé primaire de hachage uniquement à l'aide d'un identifiant et de définir un secondaire global index en utilisant horodatage. p> blockQquote>
Utilisation d'une clé primaire uniquement sur
ID code>,ID code> doit être unique. p>id (Hash) | timestamp (GSI Hash Key) ----------|------------------------- john | 2014-04-28T07:53:29.000Z mary | 2014-04-28T07:53:29.000Z jane | 2014-04-28T07:53:29.000Z
Merci pour la grande réponse. J'utilise les uuids RFC 4122 pour l'attribut ID, votre commentaire sur la solution n ° 1 étant une mauvaise utilisation d'une clé de gamme est probablement juste. Cependant, cet inconvénient n'est que conceptuel, tandis que les inconvénients de l'utilisation d'un GSI sont assez tangibles. Cela me donne certainement quelque chose à penser, cependant.
Je crois que vous pouvez changer de GSI à la volée maintenant.
Si vous utilisez une clé primaire simple pour la table, pouvez-vous toujours la questionner? Je pensais que vous ne pouviez numériser que des tables avec des clés primaires simples (hachage sans plage).
J'ai un intérêt similaire et envisageait de créer un indice secondaire sur une partie de l'horodatage (par exemple, jour ou heure) en tant que hachage et l'identifiant comme la gamme pour permettre une requête contre une tranche de temps particulière, mais cette obligerait tous les enregistrements dans une tranche de temps pour être dans la même partition pour l'indice.
Pour pouvoir interroger les données récentes et les données historiques, Amazon recommande une approche de conception multi-table - voir https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/bp-time-series.html .