AWS MySQL RDS et AWS DynamoDB
J'utilise MySQL depuis assez longtemps et je suis à l'aise avec sa structure, ses requêtes SQL, etc.
Actuellement, je construis un nouveau système dans AWS et je me suis intéressé à DynamoDB. Actuellement, je sais seulement un peu à ce sujet.
Est-ce que l'un est meilleur que l'autre?
Quels sont les avantages de DynamoDB?
quelle est la transition entre les requêtes MySQL, etc. et cette base de données à plat?
Vous pouvez lire l'explication d'AWS à ce sujet ici .
En bref, si vous avez principalement des requêtes Lookup (et non des requêtes Join), DynamoDB (et les autres bases de données NoSQL) est préférable. Si vous avez besoin de gérer beaucoup de données , vous serez limité lors de l’utilisation de MySQL (et d’autres SGBDR).
Vous ne pouvez pas réutiliser vos requêtes MySQL ni votre schéma de données, mais si vous vous efforcez d'apprendre NoSQL, vous ajouterez un outil important à votre boîte à outils. DynamoDB fournit souvent la solution la plus simple.
Vraiment DynamoDB et MySQL sont des pommes et des oranges. DynamoDB est une couche de stockage NoSQL, tandis que MySQL est utilisé pour le stockage relationnel. Vous devez choisir quoi utiliser en fonction des besoins réels de votre application. En fait, certaines applications pourraient être bien servies en utilisant les deux.
Si, par exemple, vous stockez des données qui ne se prêtent pas bien à un schéma relationnel (arborescences, représentations JSON sans schéma, etc.) pouvant être comparé à une clé unique ou à une combinaison clé/plage, alors DynamoDB ( ou un autre magasin NoSQL) serait probablement votre meilleur pari.
Si vous avez un schéma bien défini pour vos données qui peut s'intégrer parfaitement dans une structure relationnelle et que vous avez besoin de la souplesse nécessaire pour interroger les données de différentes manières (en ajoutant des index si nécessaire), alors RDS pourrait être une meilleure solution. .
Le principal avantage de l'utilisation de DynamoDB en tant que magasin NoSQL est que vous bénéficiez d'un débit de lecture/écriture garanti, quel que soit le niveau requis, sans avoir à vous soucier de la gestion d'un magasin de données en cluster. Ainsi, si votre application nécessite 1 000 lectures/écritures par seconde, vous pouvez simplement provisionner votre table DynamoDB pour ce niveau de débit sans avoir à vous soucier réellement de l'infrastructure sous-jacente.
RDS présente le même avantage de ne pas avoir à s’inquiéter de l’infrastructure elle-même. Toutefois, si vous devez effectuer un nombre important d’écritures au point où la taille de la plus grande instance ne peut plus suivre, vous êtes un peu laissé pour compte. options (vous pouvez redimensionner horizontalement les lectures à l’aide de réplicas en lecture).
Remarque mise à jour: DynamoDb prend désormais en charge l'indexation secondaire globale. Vous avez donc la possibilité d'effectuer des recherches optimisées sur des champs de données autres que le hachage ou la combinaison de clés de hachage et de plage.
Nous venons de migrer toutes nos tables DynamoDB vers RDS MySQL.
Bien que l'utilisation de DynamoDB pour des tâches spécifiques puisse sembler logique, la création d'un nouveau système sur DynamoDB est une mauvaise idée. Les meilleurs plans, etc., vous avez toujours besoin de cette flexibilité supplémentaire de votre base de données.
Voici nos raisons pour lesquelles nous avons quitté DynamoDB:
- Indexation - Il est impossible de modifier ou d'ajouter des clés à la volée sans créer une nouvelle table.
- Requêtes - Les données de requêtes sont extrêmement limitées. Surtout si vous souhaitez interroger des données non indexées. Les jointures étant évidemment impossibles, vous devez gérer des relations de données complexes sur votre couche code/cache.
- Sauvegarde - Une procédure de sauvegarde aussi fastidieuse est une surprise décevante comparée à la sauvegarde fluide de RDS
- GUI - mauvais UX, recherche limitée, pas amusant.
- Vitesse - Le temps de réponse est problématique par rapport à RDS. Vous vous trouvez en train de construire un mécanisme de cache élaboré pour le compenser à des endroits où vous auriez opté pour la mise en cache interne de RDS.
- Intégrité des données - Bien que le concept de structure de données fluide semble sympa pour commencer, certaines de vos données sont mieux "figées". Une frappe forte est une bénédiction lorsqu'un petit bogue tente de détruire votre base de données. Avec DynamoDB, tout est possible et tout ce qui peut mal tourner le fait.
Nous utilisons maintenant DynamoDB comme sauvegarde pour certains systèmes et je suis sûr que nous l’utiliserons à l’avenir pour des tâches spécifiques et bien définies. Ce n'est pas une mauvaise base de données, ce n'est tout simplement pas la base de données qui sert à 100% de votre système principal.
En ce qui concerne les avantages, je dirais évolutivité et durabilité. Il évolue incroyablement et de manière transparente et est (en quelque sorte) toujours à la hausse. Ce sont vraiment des fonctionnalités intéressantes, mais elles ne compensent en aucune façon les inconvénients.
Lorsque vous utilisez DynamoDB, vous devez également savoir que les éléments/enregistrements dans DynamoDB sont limités à 400 Ko (voir Limites DynamoDB ). Dans de nombreux cas d'utilisation, cela ne fonctionnera pas. Donc, DynamoDB ne servira à rien, mais pas à tout. Il en va de même pour beaucoup d'autres bases de données NoSQL.