Différence entre les index locaux et globaux dans DynamoDB

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

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

Global Secondary Indexes définit un nouveau paradigme - différentes clés de hachage / plage par index.
Cela rompt l'utilisation d'origine d'une clé de hachage par table. C'est également pourquoi lors de la définition de GSI, vous devez ajouter un débit provisionné par index et payer pour cela.

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

Voici la définition formelle de la documentation:

Index secondaire global - un index avec une clé de hachage et de plage qui peut être différente 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. Trouvez ci-dessous quelques facteurs importants qui auront un impact direct sur le coût et les efforts de maintenance des index:

• 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 qui a un index local, il y aura deux opérations d'écriture, une pour la table et une pour l'index. Les deux opérations consommeront des unités de capacité d'écriture de la table.

Les index secondaires globaux ont leur propre débit provisionné, lorsque vous interrogez l'index l'opération consommera la capacité de lecture de l'index, lorsque vous effectuez une opération d'écriture (créer, mettre à jour, supprimer) dans une table qui a un index global, il y en aura deux opérations d'écriture, une pour la table une autre pour l'index *.

* Lors de la définition du débit provisionné pour l'index secondaire global, assurez-vous de porter une attention particulière aux exigences suivantes:

Pour qu'une écriture de table réussisse, les paramètres de débit provisionné 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 dans la table sera limitée.

• La gestion :

Les index secondaires locaux ne peuvent être créés que lorsque vous créez la table, il n'y a aucun moyen d'ajouter un index secondaire local à une table existante, également une fois que vous avez créé l'index, vous ne pouvez pas le supprimer.

Les 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.

• Lire la cohérence:

Les index secondaires locaux prennent en charge une cohérence éventuelle ou forte, tandis que l'index secondaire global ne prend en charge qu'une cohérence éventuelle.

• Projection:

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

Considération spéciale sur l'unicité des clés définies pour les index secondaires:

Dans un index secondaire local, la valeur de clé de plage N'A PAS besoin d'être unique pour une valeur de clé de hachage donnée, la même chose s'applique aux index secondaires globaux, les valeurs de clé (hachage et plage) NE DOIVENT PAS être uniques.

Source: http://docs.aws.amazon.com/amazondynamodb/latest/developerguide/SecondaryIndexes.html

Voici les recherches possibles par index:

• Par Hash
• Par Hash + Range
• Par hachage + index local
• Par indice global
• Par indice global + indice de gamme

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

Index globaux et locaux: il s'agit d'index «supplémentaires» créés sur une table, en plus des index de hachage et de plage existants de la table. L'index global est similaire à un hachage. L'index de plage se comporte de la même manière que l'index de plage utilisé avec le hachage de la table. Dans votre modèle d'entité dans votre code, le getter doit être annoté de cette manière:

• 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 par un index global, il doit s'agir d'une lecture éventuelle (non cohérente):

queryExpression.setConsistentRead(false);

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 clés de hachage dans une table, mais coûte en conséquence un débit supplémentaire.

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

Hash 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 qui existe déjà écrasera les données existantes.

Hash + Range

Une clé de hachage + clé de 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 que vous utilisez une clé de plage qui n'est pas déjà utilisée par cette clé de hachage, cela crée un nouvel élément, alors que si un élément avec la même combinaison de hachage + plage existe déjà, il écrase l'élément correspondant.

Une autre façon de voir cela est comme un fichier avec un format. Vous pouvez avoir un fichier avec le même nom (hachage) qu'un autre, dans le même dossier (table), tant que leur format (plage) est 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 Hash-Key + Range-Key, et suit les mêmes règles que lui, 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 / nuls.

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 l'analogie de format de plus tôt) un fichier nommé: file.format.lsiet file.format.lsi2. Vous pouvez cependant avoir file.format.lsiet file.format2.lsiou file.format.lsiet file2.format.lsi.

Fondamentalement, un LSI est juste une "clé de filtre", pas une clé de plage réelle; votre combinaison de valeurs de hachage et de plage de base doit toujours être unique, tandis que les valeurs LSI ne doivent pas du tout être uniques. Un moyen plus simple de l'examiner peut être de considérer le LSI comme des données dans les fichiers. Vous pouvez écrire du code qui trouve tous les fichiers avec le nom "PROJECT101", indépendamment de leur fileFormat, puis lit les données à l'intérieur pour déterminer ce qui doit être inclus dans la requête et ce qui est omis. C'est essentiellement ainsi que fonctionne LSI (juste sans la surcharge supplémentaire de l'ouverture du fichier pour lire son contenu).

GSI

Pour GSI, vous créez essentiellement une autre table pour chaque GSI, mais sans avoir à gérer plusieurs tables séparées qui reflètent les données entre elles; c'est pourquoi ils coûtent plus de débit.

Donc, pour un GSI, vous pouvez spécifier fileNamecomme clé de hachage de base et fileFormatcomme clé de plage de base. Vous pouvez ensuite spécifier un GSI qui a une clé de hachage de fileName2et une clé de plage de fileFormat2. Vous pouvez ensuite interroger sur l'un fileNameou l' autre ou fileName2si vous le souhaitez, contrairement à LSI où vous pouvez uniquement interroger fileName.

Les principaux avantages sont que vous ne devez gérer qu'une seule table, au lieu de 2, et chaque fois que vous écrivez soit dans le Hash / Range principal ou dans le (s) Hash / Range (s) GSI, les autres seront automatiquement mis à jour également, vous ne pouvez donc pas "oublier" de mettre à jour les autres tables comme vous le pouvez avec une configuration multi-tables. De plus, il n'y a aucune chance de perdre une connexion après la mise à jour de l'une et avant la mise à jour de 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 vouliez créer une table avec fileNameet fileFormatcomme votre Hash / Range de base et filePriorityet fileNamecomme votre GSI, vous pouvez.

Enfin, une combinaison GSI Hash + Range n'a pas à être unique, tandis que la combinaison Hash + Range de base doit être unique. C'est quelque chose qui n'est pas possible avec une configuration double / multi table, mais qui l'est avec GSI. En conséquence, vous DEVEZ fournir des valeurs à la fois pour la base ET GSI Hash + Range, lors de la mise à jour; aucune de ces valeurs ne peut être vide / nulle.

Une autre façon d'expliquer: LSI vous aide à faire des requêtes supplémentaires sur des éléments avec la même clé de hachage. GSI vous aide à faire les requêtes similaires sur les éléments "à travers la table". Tellement très utile.

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

Cette documentaion donne une assez bonne explication:

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

Je ne pourrais pas commenter cette question, mais qui est meilleure en termes de performances d'écriture et de 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 table de 50?)

Je n'ai pas besoin de clé de partition séparée pour mon cas d'utilisation, donc l'index local devrait être suffisant pour la fonctionnalité requise.

Les GSI ne peuvent pas être utilisés pour des lectures cohérentes.

Les LSI peuvent être utilisés pour des lectures cohérentes, mais ils limiteront la taille de la partition principale à 10 Go. De plus, les LSI ne peuvent être créés que lors de la création de table.