web-dev-qa-db-fra.com

Différence entre les index locaux et globaux dans DynamoDB

Je suis curieux de connaître ces 2 index secondaires et leurs différences. Il est difficile d’imaginer à quoi cela ressemble. Et je pense que cela aidera plus de gens que moi.

indexingamazon-dynamodbsecondary-indexes
105
Michael Czolko

Les index secondaires locaux reposent toujours sur la clé de hachage d'origine. Lorsque vous fournissez une table avec table de hachage + plage, considérez le LSI comme table de hachage + plage1, table de hachage + plage2 .. table de hachage + plage6. Vous obtenez 5 autres attributs de plage sur lesquels interroger. En outre, il n'y a qu'un seul débit provisionné.

Les index secondaires globaux définissent un nouveau paradigme - différentes clés de hachage/plage par index.
Ceci casse l'utilisation initiale d'une clé de hachage par table. C'est également pourquoi, lors de la définition de GSI, vous devez ajouter un débit alloué par index et en assumer les coûts.

Des informations plus détaillées sur les différences peuvent être trouvées dans le annonce de GSI

97
Chen Harel

Voici la définition formelle de la documentation:

Index secondaire global - un index avec une clé de hachage et une clé de plage pouvant être différentes de celles de la table. Un index secondaire global est considéré comme "global", car les requêtes sur l'index peuvent couvrir toutes les données d'une table, sur toutes les partitions.

Index secondaire local - un index qui a la même clé de hachage que la table, mais une clé de plage différente. Un index secondaire local est "local" dans le sens où chaque partition d'un index secondaire local est étendue à une partition de table qui a la même clé de hachage.

Cependant, les différences vont bien au-delà des possibilités en termes de définitions clés. Vous trouverez ci-dessous certains facteurs importants qui auront une incidence directe sur les coûts et les efforts nécessaires au maintien des indices:

  • Débit :

Les index secondaires locaux consomment le débit de la table. Lorsque vous interrogez des enregistrements via l'index local, l'opération consomme des unités de capacité de lecture de la table. Lorsque vous effectuez une opération d'écriture (création, mise à jour, suppression) dans une table ayant un index local, il y aura deux opérations d'écriture, une pour la table, une autre pour l'index. Les deux opérations consomment des unités de capacité d'écriture de la table.

Les index secondaires globaux ont leur propre débit alloué. Lorsque vous interrogez l'index, l'opération consomme de la capacité de lecture à partir de l'index. Lorsque vous effectuez une opération d'écriture (création, mise à jour, suppression) dans une table comportant un index global, deux écrire des opérations, une pour la table, une autre pour l'index *.

* Lors de la définition du débit alloué pour l'index global global, veillez à accorder une attention particulière aux exigences suivantes:

Pour que l'écriture d'une table réussisse, les paramètres de débit alloué pour la table et tous ses index secondaires globaux doivent avoir une capacité d'écriture suffisante pour prendre en charge l'écriture. sinon, l'écriture à la table sera limitée.

  • La gestion :

Les index secondaires locaux ne peuvent être créés que lors de la création de la table. Il est impossible d'ajouter un index secondaire local à une table existante. Une fois que vous avez créé l'index, vous ne pouvez pas le supprimer.

Des index secondaires globaux peuvent être créés lorsque vous créez la table et ajoutés à une table existante. La suppression d'un index secondaire global existant est également autorisée.

  • Cohérence de lecture:

Les index secondaires locaux prennent en charge la cohérence éventuelle ou forte, alors que l’indice secondaire global ne prend en charge que la cohérence éventuelle.

  • Projection:

Les index secondaires locaux permettent de récupérer des attributs qui ne sont pas projetés dans l'index (avec un coût supplémentaire: unités de performance et de capacité consommée). Avec Global Secondary Index, vous ne pouvez récupérer que les attributs projetés sur l’index.

Considération particulière sur le caractère unique des clés définies dans les index secondaires:

Dans un index secondaire local, la valeur de clé d'intervalle NE DOIT PAS être unique pour une valeur de clé de hachage donnée, il en va de même pour les index secondaires globaux, les valeurs de clé (Hash et Range) NE doivent PAS être uniques.

Source: http://docs.aws.Amazon.com/amazondynamodb/latest/developerguu/SecondaryIndexes.html

67
bsd

Voici les recherches possibles par index:

  • Par hachage
  • Par hachage + gamme
  • Par hachage + index local
  • Par index global
  • Par index global + Range Index

Index de hachage et de plage d'une table: Il s'agit des index habituels des versions précédentes du kit de développement logiciel Amazon AWS.

Index globaux et locaux: Ce sont des index 'supplémentaires' créés sur une table, en plus des index de hachage et de plage existants de la table. Index global est similaire à un hachage. Indice de plage se comporte de manière similaire à l'indice de plage utilisé avec le hachage de la table. Dans votre modèle d'entité dans votre code, le getter doit être annoté de la manière suivante:

  • Pour les index globaux:

    @DynamoDBIndexHashKey(globalSecondaryIndexName = INDEX_GLOBAL_RANGE_US_TS)
@DynamoDBAttribute(attributeName = PROPERTY_USER)
public String getUser() {
    return user;
}

  • Pour l'index de plage associé à l'index global:

    @DynamoDBIndexRangeKey(globalSecondaryIndexName = INDEX_GLOBAL_RANGE_US_TS)
@DynamoDBAttribute(attributeName = PROPERTY_TIMESTAMP)
public String getTimestamp() {
    return timestamp;
}

De plus, si vous lisez une table avec un index global, il doit s'agir d'une lecture éventuelle (non cohérente):

queryExpression.setConsistentRead(false);
27
Carlos AG

Une façon de le dire est la suivante:

LSI - vous permet d'effectuer une requête sur une seule clé de hachage tout en utilisant plusieurs attributs différents pour "filtrer" ou restreindre la requête.

GSI - vous permet d'effectuer des requêtes sur plusieurs hachages-clés d'une table, mais entraîne un coût supplémentaire en termes de débit.

Une ventilation plus détaillée des types de table et de leur fonctionnement, ci-dessous:

hachage uniquement

Comme vous le savez probablement déjà; une clé de hachage en elle-même doit être unique, car l'écriture sur une clé de hachage existante écrasera les données existantes.

Hash + Range

Une touche de hachage + plage vous permet d'avoir plusieurs clés de hachage identiques, à condition qu'elles aient une clé de plage différente. Dans ce cas, si vous écrivez sur une clé de hachage qui existe déjà, mais utilisez une clé de plage qui n'est pas déjà utilisée par cette clé de hachage, un nouvel élément est créé, alors que s'il s'agit d'un élément avec la même combinaison Hash + Range existe déjà, il écrase l'élément correspondant.

Une autre façon de penser à cela est comme un fichier avec un format. Vous pouvez avoir un fichier portant le même nom (hachage) comme un autre, dans le même dossier (table), à ​​condition que leur format (plage) soit différent. De même, vous pouvez avoir plusieurs fichiers du même format tant que leur nom est différent.

LSI

Un LSI est fondamentalement identique à un hachage + Range-Key et suit les mêmes règles que lors de la création d'éléments, sauf que vous devez également fournir des valeurs pour les LSI; ils ne peuvent pas être laissés vides/null.

Dire qu'un LSI est "Range-Key 2" n'est pas tout à fait correct car vous ne pouvez pas avoir (en utilisant mon fichier et mon analogie de formatage plus tôt) un fichier nommé: file.format.lsi et file.format.lsi2. Vous pouvez cependant avoir file.format.lsi et file.format2.lsi ou file.format.lsi et file2.format.lsi.

Fondamentalement, un LSI est juste une "clé de filtre", pas une véritable clé de plage; votre combinaison de valeurs de hachage et de plage de base doit toujours être unique, tandis que les valeurs de LSI ne doivent pas nécessairement l'être du tout. Un moyen plus facile de voir cela peut être de considérer le LSI comme des données contenues dans les fichiers. Vous pouvez écrire du code qui trouve tous les fichiers avec le nom "PROJECT101", quel que soit leur fileFormat, puis lit les données qu'il contient afin de déterminer ce qui doit être inclus dans la requête et ce qui est omis. C’est essentiellement ainsi que fonctionne LSI (sans la charge supplémentaire liée à l’ouverture du fichier pour en lire le contenu).

GSI

Pour GSI, vous créez essentiellement une autre table pour chaque GSI, mais vous n'avez pas à vous soucier de la maintenance de plusieurs tables distinctes qui reflètent les données en miroir. c'est pourquoi ils coûtent plus de débit.

Ainsi, pour un GSI, vous pouvez spécifier fileName comme clé de hachage de base et fileFormat comme clé de base. Vous pouvez ensuite spécifier un GSI ayant une clé de hachage de fileName2 et une plage-clé de fileFormat2. Vous pouvez ensuite interroger sur fileName ou fileName2 _ si vous voulez, contrairement à LSI où vous ne pouvez interroger que sur fileName.

Les principaux avantages sont que vous ne devez conserver qu'une table, au lieu de 2, et que chaque fois que vous écrivez sur le hachage/plage principal ou sur le hachage/plage (s) GSI, le ou les autres seront automatiquement mis à jour, vous ne pouvez donc pas "oublier" de mettre à jour la ou les autres tables comme vous pouvez le faire avec une configuration multi-table. En outre, il n'y a aucune chance de perdre une connexion après la mise à jour de l'une ou l'autre, comme c'est le cas avec la configuration multi-tables.

De plus, un GSI peut "chevaucher" la combinaison de hachage/plage de base. Donc, si vous voulez créer une table avec fileName et fileFormat comme hachage/plage de base et filePriority et fileName en tant que votre GSI, vous pouvez le faire.

Enfin, une combinaison GSI Hash + Range ne doit pas nécessairement être unique, alors que la combinaison de base Hash + Range doit être unique. C'est quelque chose qui n'est pas possible avec une configuration double/multi-tables, mais avec GSI. Par conséquent, vous DEVEZ fournir des valeurs pour la base ET GSI Hash + Range, lors de la mise à jour; Aucune de ces valeurs ne peut être vide/nulle.

15
DGolberg

Une autre façon d’expliquer: LSI vous permet d’effectuer des requêtes supplémentaires sur des éléments ayant la même clé de hachage. GSI vous aide à faire les mêmes requêtes sur les articles "à travers la table". Donc très utile.

Si vous avez une table de profil utilisateur: identifiant unique, nom, email. Ici, si vous devez rendre la table interrogeable sur nom, email - le seul moyen est de les rendre GSI (LSI ne vous aidera pas)

12
Sony Kadavan

Cette documentation donne une très bonne explication:

https://aws.Amazon.com/blogs/aws/now-available-global-secondary-indexes-for-Amazon-dynamodb/

Je ne peux pas commenter cette question, mais qui est meilleure en termes de performances en écriture et en lecture:

(Index local avec un débit de lecture et d'écriture de table de 100) ou (Index global avec un débit de lecture/écriture de 50 avec un débit de lecture/écriture de la table de 50?)

Je n'ai pas besoin d'une clé de partition distincte pour mon cas d'utilisation. Par conséquent, l'index local devrait suffire à la fonctionnalité requise.

1
Sindhu