D'après ce que je peux dire, renommer une table ou un index existant n'est pas possible sur DynamoDB. Y a-t-il une raison pour laquelle? Je ne comprends pas pourquoi ce n'est pas une tâche simple.
(Sinon, s'il est possible de renommer l'un ou l'autre, faites-le moi savoir!)
4 Réponses :
J'ai eu ce problème il y a une semaine et il n'y a qu'une seule façon d'y parvenir. Actuellement, vous devrez créer une nouvelle table avec le nouveau nom et supprimer / supprimer l'ancien.
J'ai passé la semaine dernière à travailler dans DynamoDB pour la première fois et j'ai réalisé qu'il manquait de nombreuses fonctionnalités dans DynamoDB, par exemple l'importation de données à partir d'un fichier csv n'est pas non plus prise en charge dans la console AWS.
Vous pouvez changer le nom lors de la création d'une sauvegarde. Lorsque vous restaurez la sauvegarde, la table portera le nom que vous avez renseigné.
En l'absence d'explication officielle d'AWS, aucune réponse objective ne peut être donnée expliquant pourquoi cela n'est pas possible. La raison en est que c'est ainsi qu'ils l'ont conçu, et personne ne peut en dire plus avec une quelconque autorité.
Mais nous pouvons arriver à des conclusions raisonnables, basées sur le fait que peu de tâches sont "simples" dans les systèmes distribués.
Changer le nom d'une table ou d'un index est une opération qui devrait soit être instantanée, soit exiger que la table entière soit gelée et verrouillée pendant l'opération. Aucune opération ne peut être en cours lorsque le changement de nom se produit, car elles seraient potentiellement invalides - référençant le nouveau nom trop tôt ou l'ancien nom trop tard. Et l'application entière devrait être mise à jour en même temps.
Les bases de données relationnelles permettent plus facilement de renommer car elles ne sont qu'une seule et même chose en un seul endroit - l'index est sur une table sur un serveur maître, et le serveur peut verrouiller les métadonnées de la table (en attendant le verrou pendant que les requêtes sont terminées) , puis en évitant de nouvelles requêtes pendant que la modification est effectuée, puis en libérant le verrou).
Votre table DynamoDB n'a pas de serveur maître. Vos tables sont réparties de manière transparente sur plusieurs partitions sur plusieurs serveurs, et chacune d'elles possède plusieurs répliques / homologues dans d'autres zones de disponibilité de la région. C'est un système hautement distribué. Coordonner une opération sur toutes ces couches est une proposition complexe - pas impossible, peut-être même pas irréalisable, mais nécessitant des couches supplémentaires de complexité pour accomplir quelque chose qui est rarement nécessaire ... un coût élevé, un faible gain.
Cela serait considéré comme inacceptable dans de nombreux cas si les tables ou les index avaient un état - similaire à Backfilling état lors de la création initiale de l'index - qui a bloqué leur utilisation pendant que les tâches d'arrière-plan nécessaires effectuaient un changement de nom. Les exceptions probables seraient pour les petites tables et les tables non utilisées en production ... et ce sont les cas qui seraient les scénarios de valeur la plus basse pour une telle fonctionnalité.
Le moyen le plus simple et le plus simple est de créer une nouvelle table et de supprimer la table existante. De plus, lors de la création de sauvegardes, il peut prendre de nouveaux noms et lorsque vous restaurez, ce sera avec de nouveaux noms. La principale préoccupation derrière le dynamodb est le coût, et c'est pourquoi il manque peu de fonctionnalités que nous avons l'habitude d'avoir avec un système SGBDR normal.