Quand utiliser les index secondaires DynamoDB

Les index constituent un élément crucial d'une modélisation appropriée des données pour toutes les bases de données, et DynamoDB ne fait pas exception. Les index secondaires de DynamoDB sont un outil puissant pour activer de nouveaux modèles d'accès à vos données.

Dans cet article, nous examinerons les index secondaires DynamoDB . Tout d’abord, nous commencerons par quelques points conceptuels sur la manière de penser DynamoDB et les problèmes résolus par les index secondaires. Nous examinerons ensuite quelques conseils pratiques pour utiliser efficacement les index secondaires. Enfin, nous terminerons par quelques réflexions sur le moment où vous devez utiliser les index secondaires et quand vous devez rechercher d'autres solutions.

Commençons.

Qu'est-ce que DynamoDB et que sont les index secondaires DynamoDB ?

Avant d'aborder les cas d'utilisation et les meilleures pratiques pour les index secondaires, nous devons d'abord comprendre ce que sont les index secondaires DynamoDB . Et pour ce faire, nous devons comprendre un peu le fonctionnement de DynamoDB.

Cela suppose une certaine compréhension de base de DynamoDB. Nous aborderons les points de base que vous devez connaître pour comprendre les index secondaires, mais si vous débutez avec DynamoDB, vous souhaiterez peut-être commencer par une introduction plus basique.

Le strict minimum que vous devez savoir sur DynamoDB

DynamoDB est une base de données unique. Il est conçu pour les charges de travail OLTP, ce qui signifie qu'il est idéal pour gérer un volume élevé de petites opérations - pensez à des choses comme ajouter un article à un panier, aimer une vidéo ou ajouter un commentaire sur Reddit. De cette façon, il peut gérer des applications similaires à celles d'autres bases de données que vous avez pu utiliser, comme MySQL, PostgreSQL, MongoDB ou Cassandra.

La principale promesse de DynamoDB est sa garantie de performances constantes à toute échelle . Que votre table contienne 1 mégaoctet de données ou 1 pétaoctet de données, DynamoDB souhaite avoir la même latence pour vos requêtes de type OLTP. C'est un gros problème : de nombreuses bases de données verront leurs performances diminuer à mesure que vous augmentez la quantité de données ou le nombre de requêtes simultanées. Cependant, fournir ces garanties nécessite certains compromis, et DynamoDB possède des caractéristiques uniques que vous devez comprendre pour l'utiliser efficacement.

Premièrement, DynamoDB met à l'échelle horizontalement vos bases de données en répartissant vos données sur plusieurs partitions sous le capot. Ces partitions ne sont pas visibles pour vous en tant qu'utilisateur, mais elles sont au cœur du fonctionnement de DynamoDB. Vous spécifierez une clé primaire pour votre table (soit un élément unique, appelé « clé de partition », soit une combinaison d'une clé de partition et d'une clé de tri), et DynamoDB utilisera cette clé primaire pour déterminer sur quelle partition se trouvent vos données. . Toute requête que vous ferez passera par un routeur de requêtes qui déterminera quelle partition doit gérer la requête. Ces partitions sont petites (généralement 10 Go ou moins) et peuvent donc être déplacées, divisées, répliquées et gérées de manière indépendante.

L'évolutivité horizontale via le sharding est intéressante mais n'est en aucun cas unique à DynamoDB. De nombreuses autres bases de données – relationnelles et non relationnelles – utilisent le partitionnement pour évoluer horizontalement. Cependant, ce qui est unique à DynamoDB, c'est la façon dont il vous oblige à utiliser votre clé primaire pour accéder à vos données. Plutôt que d'utiliser un planificateur de requêtes qui traduit vos requêtes en une série de requêtes, DynamoDB vous oblige à utiliser votre clé primaire pour accéder à vos données. Vous obtenez essentiellement un index directement adressable pour vos données.

L'API pour DynamoDB reflète cela. Il existe une série d'opérations sur des éléments individuels ( GetItem , PutItem , UpdateItem , DeleteItem ) qui vous permettent de lire, d'écrire et de supprimer des éléments individuels. De plus, il existe une opération Query qui vous permet de récupérer plusieurs éléments avec la même clé de partition. Si vous disposez d'une table avec une clé primaire composite, les éléments ayant la même clé de partition seront regroupés sur la même partition. Ils seront classés en fonction de la clé de tri, vous permettant de gérer des modèles tels que « Récupérer les commandes les plus récentes pour un utilisateur » ou « Récupérer les 10 dernières lectures de capteurs pour un appareil IoT ».

Par exemple, imaginons une application SaaS dotée d'un tableau d'utilisateurs. Tous les utilisateurs appartiennent à une seule organisation. Nous pourrions avoir un tableau qui ressemble à ceci :

Nous utilisons une clé primaire composite avec une clé de partition de « Organisation » et une clé de tri de « Nom d'utilisateur ». Cela nous permet d'effectuer des opérations pour récupérer ou mettre à jour un utilisateur individuel en fournissant son organisation et son nom d'utilisateur. Nous pouvons également récupérer tous les utilisateurs d'une seule organisation en fournissant uniquement l'organisation à une opération Query .

Que sont les index secondaires et comment fonctionnent-ils

Avec quelques notions de base à l’esprit, examinons maintenant les index secondaires. La meilleure façon de comprendre la nécessité des index secondaires est de comprendre le problème qu’ils résolvent. Nous avons vu comment DynamoDB partitionne vos données en fonction de votre clé primaire et comment il vous pousse à utiliser la clé primaire pour accéder à vos données. C'est très bien pour certains modèles d'accès, mais que se passe-t-il si vous devez accéder à vos données d'une manière différente ?

Dans notre exemple ci-dessus, nous avions un tableau d'utilisateurs auquel nous avions accès par leur organisation et leur nom d'utilisateur. Cependant, nous pouvons également avoir besoin de récupérer un seul utilisateur via son adresse e-mail. Ce modèle ne correspond pas au modèle d'accès à la clé primaire vers lequel DynamoDB nous pousse. Étant donné que notre table est partitionnée selon différents attributs, il n'existe pas de moyen clair d'accéder à nos données comme nous le souhaitons. Nous pourrions effectuer une analyse complète de la table, mais c'est lent et inefficace. Nous pourrions dupliquer nos données dans une table distincte avec une clé primaire différente, mais cela ajoute de la complexité.

C'est là qu'interviennent les index secondaires. Un index secondaire est essentiellement une copie entièrement gérée de vos données avec une clé primaire différente. Vous spécifierez un index secondaire sur votre table en déclarant la clé primaire de l'index. Au fur et à mesure que les écritures arrivent dans votre table, DynamoDB répliquera automatiquement les données sur votre index secondaire.

Remarque * : Tout dans cette section s'applique aux index secondaires globaux . DynamoDB fournit également des index secondaires locaux , qui sont un peu différents. Dans presque tous les cas, vous souhaiterez un index secondaire global. Pour plus de détails sur les différences, consultez cet article sur le choix d'un index secondaire global ou local .*

Dans ce cas, nous ajouterons un index secondaire à notre table avec une clé de partition de « Email ». L'index secondaire ressemblera à ceci :

Notez qu'il s'agit des mêmes données, elles viennent d'être réorganisées avec une clé primaire différente. Désormais, nous pouvons rechercher efficacement un utilisateur par son adresse e-mail.

À certains égards, cela ressemble beaucoup à un index dans d’autres bases de données. Les deux fournissent une structure de données optimisée pour les recherches sur un attribut particulier. Mais les index secondaires de DynamoDB diffèrent sur plusieurs points essentiels.

Premièrement, et surtout, les index de DynamoDB résident sur des partitions entièrement différentes de celles de votre table principale. DynamoDB souhaite que chaque recherche soit efficace et prévisible, et souhaite fournir une mise à l'échelle horizontale linéaire. Pour ce faire, il doit repartir vos données en fonction des attributs que vous utiliserez pour les interroger.

Dans d'autres bases de données distribuées, ils ne repartagent généralement pas vos données pour l'index secondaire. Ils conservent généralement simplement l'index secondaire pour toutes les données sur le fragment. Cependant, si vos index n'utilisent pas la clé de partition, vous perdez certains des avantages de la mise à l'échelle horizontale de vos données, car une requête sans clé de partition devra effectuer une opération de collecte dispersée sur toutes les partitions pour trouver les données que vous souhaitez. tu cherches.

Une deuxième différence entre les index secondaires de DynamoDB est qu'ils copient (souvent) l'intégralité de l'élément dans l'index secondaire. Pour les index d'une base de données relationnelle, l'index contient souvent un pointeur vers la clé primaire de l'élément en cours d'indexation. Après avoir localisé un enregistrement pertinent dans l'index, la base de données devra alors aller récupérer l'élément complet. Étant donné que les index secondaires de DynamoDB se trouvent sur des nœuds différents de la table principale, ils souhaitent éviter un saut de réseau vers l'élément d'origine. Au lieu de cela, vous copierez autant de données que nécessaire dans l'index secondaire pour gérer votre lecture.

Les index secondaires dans DynamoDB sont puissants, mais ils présentent certaines limites. Tout d’abord, ils sont en lecture seule : vous ne pouvez pas écrire directement dans un index secondaire. Au lieu de cela, vous écrirez dans votre table principale et DynamoDB gérera la réplication vers votre index secondaire. Deuxièmement, vous êtes facturé pour les opérations d'écriture dans vos index secondaires. Ainsi, l'ajout d'un index secondaire à votre table doublera souvent les coûts totaux d'écriture de votre table.

Conseils d'utilisation des index secondaires

Maintenant que nous comprenons ce que sont les index secondaires et comment ils fonctionnent, parlons de la façon de les utiliser efficacement. Les index secondaires sont un outil puissant, mais ils peuvent être utilisés à mauvais escient. Voici quelques conseils pour utiliser efficacement les index secondaires.

Essayez d'avoir des modèles en lecture seule sur les index secondaires

Le premier conseil semble évident : les index secondaires ne peuvent être utilisés que pour des lectures, vous devriez donc viser à avoir des modèles en lecture seule sur vos index secondaires ! Et pourtant, je vois cette erreur tout le temps. Les développeurs liront d’abord à partir d’un index secondaire, puis écriront dans la table principale. Cela entraîne des coûts et une latence supplémentaires, et vous pouvez souvent les éviter grâce à une planification préalable.

Si vous avez lu quelque chose sur la modélisation des données DynamoDB, vous savez probablement que vous devez d'abord penser à vos modèles d'accès. Ce n'est pas comme une base de données relationnelle dans laquelle vous concevez d'abord des tables normalisées, puis écrivez des requêtes pour les joindre. Dans DynamoDB, vous devez réfléchir aux actions que votre application entreprendra, puis concevoir vos tables et index pour prendre en charge ces actions.

Lors de la conception de ma table, j'aime commencer par les modèles d'accès basés sur l'écriture. Avec mes écrits, je maintiens souvent un certain type de contrainte : l'unicité d'un nom d'utilisateur ou un nombre maximum de membres dans un groupe. Je souhaite concevoir ma table de manière à ce que cela soit simple, idéalement sans utiliser de transactions DynamoDB ni en utilisant un modèle de lecture-modification-écriture qui pourrait être soumis à des conditions de concurrence.

Au fur et à mesure que vous les parcourez, vous constaterez généralement qu'il existe un moyen « principal » d'identifier votre élément qui correspond à vos modèles d'écriture. Cela finira par être votre clé primaire. Ensuite, l’ajout de modèles de lecture secondaires supplémentaires est facile avec les index secondaires.

Dans notre exemple d'utilisateurs précédent, chaque demande d'utilisateur inclura probablement l'organisation et le nom d'utilisateur. Cela me permettra de rechercher l'enregistrement individuel de l'utilisateur ainsi que d'autoriser des actions spécifiques de la part de l'utilisateur. La recherche d'adresse e-mail peut concerner des modèles d'accès moins importants, comme un flux « mot de passe oublié » ou un flux « recherche d'un utilisateur ». Ce sont des modèles en lecture seule et ils s'intègrent bien avec un index secondaire.

Utilisez des index secondaires lorsque vos clés sont mutables

Un deuxième conseil pour utiliser les index secondaires consiste à les utiliser pour des valeurs mutables dans vos modèles d'accès. Comprenons d’abord le raisonnement qui se cache derrière cela, puis examinons les situations dans lesquelles cela s’applique.

DynamoDB vous permet de mettre à jour un élément existant avec l'opération UpdateItem . Cependant, vous ne pouvez pas modifier la clé primaire d'un élément dans une mise à jour . La clé primaire est l'identifiant unique d'un élément, et modifier la clé primaire revient essentiellement à créer un nouvel élément. Si vous souhaitez modifier la clé primaire d'un élément existant, vous devrez supprimer l'ancien élément et en créer un nouveau. Ce processus en deux étapes est plus lent et coûteux. Souvent, vous devrez d'abord lire l'élément d'origine, puis utiliser une transaction pour supprimer l'élément d'origine et en créer un nouveau dans la même demande.

D'un autre côté, si vous avez cette valeur mutable dans la clé primaire d'un index secondaire, alors DynamoDB gérera ce processus de suppression + création pour vous lors de la réplication. Vous pouvez émettre une simple requête UpdateItem pour modifier la valeur, et DynamoDB se chargera du reste.

Je vois ce modèle apparaître dans deux situations principales. La première, et la plus courante, se produit lorsque vous souhaitez effectuer un tri sur un attribut mutable. Les exemples canoniques ici sont un classement pour un jeu dans lequel les gens accumulent continuellement des points, ou pour une liste d'éléments continuellement mise à jour dans laquelle vous souhaitez afficher en premier les éléments les plus récemment mis à jour. Pensez à quelque chose comme Google Drive, où vous pouvez trier vos fichiers par « dernière modification ».

Un deuxième modèle où cela apparaît est lorsque vous avez un attribut mutable sur lequel vous souhaitez filtrer. Ici, vous pouvez penser à une boutique de commerce électronique avec un historique des commandes d’un utilisateur. Vous souhaiterez peut-être autoriser l'utilisateur à filtrer ses commandes par statut : montrez-moi toutes mes commandes « expédiées » ou « livrées ». Vous pouvez l'intégrer dans votre clé de partition ou au début de votre clé de tri pour permettre un filtrage par correspondance exacte. À mesure que l'élément change de statut, vous pouvez mettre à jour l'attribut status et vous appuyer sur DynamoDB pour regrouper correctement les éléments dans votre index secondaire.

Dans ces deux situations, déplacer cet attribut mutable vers votre index secondaire vous fera économiser du temps et de l'argent. Vous gagnerez du temps en évitant le modèle lecture-modification-écriture, et vous économiserez de l'argent en évitant les coûts d'écriture supplémentaires de la transaction.

De plus, notez que ce modèle correspond bien au conseil précédent. Il est peu probable que vous identifiiez un élément à écrire en fonction de l'attribut mutable tel que son score précédent, son statut précédent ou la dernière fois qu'il a été mis à jour. Au lieu de cela, vous mettrez à jour avec une valeur plus persistante, comme l'ID de l'utilisateur, l'ID de la commande ou l'ID du fichier. Ensuite, vous utiliserez l’index secondaire pour trier et filtrer en fonction de l’attribut mutable.

Évitez la partition « grosse »

Nous avons vu ci-dessus que DynamoDB divise vos données en partitions basées sur la clé primaire. DynamoDB vise à conserver ces partitions petites (10 Go ou moins) et vous devez vous efforcer de répartir les requêtes sur vos partitions pour bénéficier des avantages de l'évolutivité de DynamoDB.

Cela signifie généralement que vous devez utiliser une valeur de cardinalité élevée dans votre clé de partition. Pensez à quelque chose comme un nom d'utilisateur, un identifiant de commande ou un identifiant de capteur. Il existe un grand nombre de valeurs pour ces attributs et DynamoDB peut répartir le trafic sur vos partitions.

Souvent, je vois des gens comprendre ce principe dans leur table principale, mais ensuite l'oublier complètement dans leurs index secondaires. Souvent, ils souhaitent commander sur l’ensemble de la table pour un type d’article. S'ils souhaitent récupérer les utilisateurs par ordre alphabétique, ils utiliseront un index secondaire dans lequel tous les utilisateurs auront USERS comme clé de partition et le nom d'utilisateur comme clé de tri. Ou, s'ils souhaitent classer les commandes les plus récentes dans une boutique de commerce électronique, ils utiliseront un index secondaire dans lequel toutes les commandes ont ORDERS comme clé de partition et l'horodatage comme clé de tri.

Ce modèle peut fonctionner pour les applications à faible trafic pour lesquelles vous ne vous approcherez pas des limites de débit de la partition DynamoDB , mais il s'agit d'un modèle dangereux pour une application à fort trafic. Tout votre trafic peut être redirigé vers une seule partition physique et vous pouvez rapidement atteindre les limites de débit d'écriture pour cette partition.

De plus, et c'est le plus dangereux, cela peut causer des problèmes à votre table principale. Si votre index secondaire est limité en écriture pendant la réplication, la file d'attente de réplication sera sauvegardée. Si cette file d'attente sauvegarde trop, DynamoDB commencera à rejeter les écritures sur votre table principale.

Ceci est conçu pour vous aider : DynamoDB souhaite limiter le caractère obsolète de votre index secondaire, cela vous évitera donc un index secondaire avec un décalage important. Cependant, il peut s'agir d'une situation surprenante qui surgit au moment où on s'y attend le moins.

Utiliser des index clairsemés comme filtre global

Les gens considèrent souvent les index secondaires comme un moyen de répliquer toutes leurs données avec une nouvelle clé primaire. Cependant, vous n'avez pas besoin que toutes vos données se retrouvent dans un index secondaire. Si vous disposez d'un élément qui ne correspond pas au schéma de clé de l'index, il ne sera pas répliqué dans l'index.

Cela peut être très utile pour fournir un filtre global sur vos données. L'exemple canonique que j'utilise pour cela est une boîte de réception de messages. Dans votre table principale, vous pouvez stocker tous les messages destinés à un utilisateur particulier, classés selon leur date de création.

Mais si vous êtes comme moi, vous avez beaucoup de messages dans votre boîte de réception. De plus, vous pouvez traiter les messages non lus comme une liste de « choses à faire », comme de petits rappels pour répondre à quelqu'un. Par conséquent, je souhaite généralement voir uniquement les messages non lus dans ma boîte de réception.

Vous pouvez utiliser votre index secondaire pour fournir ce filtre global où unread == true . Peut-être que votre clé de partition d'index secondaire ressemble à ${userId}#UNREAD , et la clé de tri est l'horodatage du message. Lorsque vous créez initialement le message, il inclura la valeur de la clé de partition de l'index secondaire et sera donc répliqué dans l'index secondaire des messages non lus. Plus tard, lorsqu'un utilisateur lit le message, vous pouvez modifier l' status en READ et supprimer la valeur de la clé de partition d'index secondaire. DynamoDB le supprimera ensuite de votre index secondaire.

J'utilise cette astuce tout le temps et elle est remarquablement efficace. De plus, un index clairsemé vous fera économiser de l’argent. Les mises à jour pour lire les messages ne seront pas répliquées sur l'index secondaire et vous économiserez sur les coûts d'écriture.

Affinez vos projections d'index secondaire pour réduire la taille de l'index et/ou les écritures

Pour notre dernier conseil, poussons un peu plus loin le point précédent. Nous venons de voir que DynamoDB n'inclura pas un élément dans votre index secondaire si l'élément ne possède pas les éléments clés primaires de l'index. Cette astuce peut être utilisée non seulement pour les éléments clés primaires, mais également pour les attributs non clés des données !

Lorsque vous créez un index secondaire, vous pouvez spécifier les attributs de la table principale que vous souhaitez inclure dans l'index secondaire. C'est ce qu'on appelle la projection de l'indice. Vous pouvez choisir d'inclure tous les attributs de la table principale, uniquement les attributs de clé primaire ou un sous-ensemble d'attributs.

Bien qu'il soit tentant d'inclure tous les attributs dans votre index secondaire, cela peut s'avérer une erreur coûteuse. N'oubliez pas que chaque écriture dans votre table principale modifiant la valeur d'un attribut projeté sera répliquée dans votre index secondaire. Un seul index secondaire avec projection complète double effectivement les coûts d’écriture de votre table. Chaque index secondaire supplémentaire augmente vos coûts d'écriture de 1/N + 1 , où N est le nombre d'index secondaires avant le nouveau.

De plus, vos coûts d'écriture sont calculés en fonction de la taille de votre article. Chaque 1 Ko de données écrites dans votre table utilise un WCU. Si vous copiez un élément de 4 Ko vers votre index secondaire, vous paierez la totalité des 4 WCU sur votre table principale et votre index secondaire.

Ainsi, vous pouvez économiser de l’argent de deux manières en affinant vos projections d’indice secondaire. Premièrement, vous pouvez éviter complètement certaines écritures. Si vous avez une opération de mise à jour qui ne touche aucun attribut dans la projection de votre index secondaire, DynamoDB ignorera l'écriture dans votre index secondaire. Deuxièmement, pour les écritures qui sont répliquées sur votre index secondaire, vous pouvez économiser de l'argent en réduisant la taille de l'élément répliqué.

Il peut s’avérer difficile de parvenir à un juste équilibre. Les projections de l'index secondaire ne sont pas modifiables une fois l'index créé. Si vous constatez que vous avez besoin d'attributs supplémentaires dans votre index secondaire, vous devrez créer un nouvel index avec la nouvelle projection, puis supprimer l'ancien index.

Faut-il utiliser un index secondaire ?

Maintenant que nous avons exploré quelques conseils pratiques concernant les index secondaires, prenons du recul et posons une question plus fondamentale : devriez-vous utiliser un index secondaire ?

Comme nous l'avons vu, les index secondaires vous aident à accéder à vos données d'une manière différente. Cependant, cela se fait au prix d’écritures supplémentaires. Ainsi, ma règle générale pour les index secondaires est la suivante :

Utilisez des index secondaires lorsque la réduction des coûts de lecture dépasse l’augmentation des coûts d’écriture.

Cela semble évident lorsque vous le dites, mais cela peut être contre-intuitif lorsque vous modélisez. Il semble si facile de dire « Jetez-le dans un index secondaire » sans penser à d’autres approches.

Pour bien comprendre, examinons deux situations dans lesquelles les index secondaires pourraient ne pas avoir de sens.

Beaucoup d'attributs filtrables dans les petites collections d'éléments

Avec DynamoDB, vous souhaitez généralement que vos clés primaires effectuent votre filtrage à votre place. Cela m'irrite un peu chaque fois que j'utilise une requête dans DynamoDB, mais que j'effectue ensuite mon propre filtrage dans mon application. Pourquoi ne pourrais-je pas simplement l'intégrer dans la clé primaire ?

Malgré ma réaction viscérale, il existe certaines situations dans lesquelles vous souhaiterez peut-être surlire vos données, puis les filtrer dans votre application.

L'endroit le plus courant où vous verrez cela est lorsque vous souhaitez fournir de nombreux filtres différents sur vos données à vos utilisateurs, mais que l'ensemble de données pertinent est limité.

Pensez à un tracker d'entraînement. Vous souhaiterez peut-être autoriser les utilisateurs à filtrer sur de nombreux attributs, tels que le type d'entraînement, l'intensité, la durée, la date, etc. Cependant, le nombre d'entraînements d'un utilisateur sera gérable - même un utilisateur expérimenté mettra un certain temps à dépasser 1 000 entraînements. Plutôt que de mettre des index sur tous ces attributs, vous pouvez simplement récupérer tous les entraînements de l'utilisateur, puis filtrer dans votre application.

C'est là que je recommande de faire le calcul . DynamoDB facilite le calcul de ces deux options et permet d'avoir une idée de celle qui fonctionnera le mieux pour votre application.

De nombreux attributs filtrables dans les grandes collections d'éléments

Changeons un peu notre situation : que se passe-t-il si notre collection d'objets est importante ? Que se passe-t-il si nous construisons un tracker d'entraînement pour une salle de sport et que nous souhaitons permettre au propriétaire de la salle de sport de filtrer tous les attributs que nous avons mentionnés ci-dessus pour tous les utilisateurs de la salle de sport ?

Cela change la donne. Nous parlons désormais de centaines, voire de milliers d’utilisateurs, chacun ayant des centaines ou des milliers d’entraînements. Cela n'aura aucun sens de surlire l'intégralité de la collection d'éléments et d'effectuer un filtrage post-hoc sur les résultats.

Mais les index secondaires n’ont pas vraiment de sens ici non plus. Les index secondaires conviennent aux modèles d'accès connus où vous pouvez compter sur la présence des filtres pertinents. Si nous voulons que le propriétaire de notre salle de sport puisse filtrer sur une variété d'attributs, tous facultatifs, nous devrons créer un grand nombre d'index pour que cela fonctionne.

Nous avons déjà parlé des inconvénients possibles des planificateurs de requêtes, mais les planificateurs de requêtes ont également des avantages. En plus de permettre des requêtes plus flexibles, ils peuvent également effectuer des opérations telles que des intersections d'index pour examiner les résultats partiels de plusieurs index lors de la composition de ces requêtes. Vous pouvez faire la même chose avec DynamoDB, mais cela entraînera de nombreux allers-retours avec votre application, ainsi qu'une logique d'application complexe pour la comprendre.

Lorsque je rencontre ce type de problèmes, je recherche généralement un outil mieux adapté à ce cas d'utilisation. Rockset et Elasticsearch sont mes recommandations préférées ici pour fournir un filtrage flexible de type index secondaire sur votre ensemble de données.

Conclusion

Dans cet article, nous avons découvert les index secondaires DynamoDB. Tout d’abord, nous avons examiné quelques éléments conceptuels pour comprendre comment fonctionne DynamoDB et pourquoi des index secondaires sont nécessaires. Ensuite, nous avons passé en revue quelques conseils pratiques pour comprendre comment utiliser efficacement les index secondaires et découvrir leurs particularités spécifiques. Enfin, nous avons examiné comment penser aux index secondaires pour voir quand vous devriez utiliser d'autres approches.

Les index secondaires sont un outil puissant dans votre boîte à outils DynamoDB, mais ils ne constituent pas une solution miracle. Comme pour toute modélisation de données DynamoDB, assurez-vous d'examiner attentivement vos modèles d'accès et de compter les coûts avant de vous lancer.

Apprenez-en davantage sur la façon dont vous pouvez utiliser Rockset pour un filtrage de type index secondaire dans le blog d'Alex DeBrie . Requêtes de filtrage et d'agrégation DynamoDB utilisant SQL sur Rockset .