AWS MySQL RDS vs AWS DynamoDB

Question

J'utilise MySQL depuis un certain temps maintenant et je suis à l'aise avec sa structure et ses requêtes SQL, etc.

Je construis actuellement un nouveau système dans AWS et j'ai regardé DynamoDB. Pour l'instant, je ne connais que peu de choses à ce sujet.

Est-ce qu'un est meilleur que l'autre?

Quels sont les avantages de DynamoDB?

Comment se passe la transition des requêtes MySQL à cette base de données de style plat?

Answer 1

Vraiment DynamoDB et MySQL sont comme comparer des pommes et des oranges. DynamoDB est une couche de stockage NoSQL tandis que MySQL est utilisé pour le stockage relationnel. Vous devriez choisir ce que vous allez utiliser en fonction des besoins réels de votre application. En fait, certaines applications pourraient bénéficier de l'utilisation des deux.

Par exemple, si vous stockez des données qui ne se prêtent pas bien à un schéma relationnel (structures arborescentes, représentations JSON sans schéma, etc.) qui peuvent être cherchées contre une seule clé ou une combinaison clé/plage, alors DynamoDB (ou un autre magasin NoSQL) serait probablement le meilleur choix.

Si vous avez un schéma bien défini pour vos données qui peut s'intégrer facilement dans une structure relationnelle et que vous avez besoin de flexibilité pour interroger les données de différentes manières (en ajoutant des index si nécessaire bien sûr), alors RDS pourrait être une meilleure solution.

Le principal avantage d'utiliser DynamoDB en tant que magasin NoSQL est que vous obtenez des débits de lecture/écriture garantis au niveau requis sans avoir à vous soucier de la gestion d'un magasin de données en cluster. Donc, si votre application nécessite 1000 lectures/écritures par seconde, vous pouvez simplement provisionner votre table DynamoDB pour ce niveau de débit et ne plus vraiment vous soucier de l'infrastructure sous-jacente.

RDS a en grande partie les mêmes avantages de ne pas avoir à se soucier de l'infrastructure elle-même, cependant si vous finissez par avoir besoin d'un nombre important d'écritures au point où la plus grande taille d'instance ne pourra plus suivre, vous êtes un peu laissé sans options (vous pouvez mettre à l'échelle horizontalement pour les lectures en utilisant des réplicas de lecture).

Note mise à jour: DynamoDb prend désormais en charge les index secondaires globaux, vous avez donc maintenant la possibilité d'effectuer des recherches optimisées sur des champs de données autres que la clé de hachage ou la combinaison clé de hachage et de plage.

Answer 2

Nous venons de migrer toutes nos tables DynamoDB vers RDS MySQL.

Alors qu'utiliser DynamoDB pour des tâches spécifiques peut avoir du sens, construire un nouveau système basé sur DynamoDB est vraiment une mauvaise idée. Malgré les meilleurs plans, vous avez toujours besoin de cette flexibilité supplémentaire de votre base de données.

Voici nos raisons pour lesquelles nous sommes passés de DynamoDB :

1. Indexation - Modifier ou ajouter des clés sur le vif est impossible sans créer une nouvelle table.
2. Requêtes - La requête de données est extrêmement limitée. Surtout si vous voulez interroger des données non indexées. Les jointures sont bien sûr impossibles, donc vous devez gérer des relations de données complexes sur votre code/couche de cache.
3. Backup - Une procédure de sauvegarde aussi fastidieuse est une surprise décevante comparée à la sauvegarde élégante de RDS.
4. GUI - Mauvaise expérience utilisateur, recherche limitée, pas amusant.
5. Vitesse - Le temps de réponse pose problème par rapport à RDS. Vous vous retrouvez à construire des mécanismes de mise en cache élaborés pour compenser à des endroits où vous vous seriez contenté de la mise en cache interne de RDS.
6. Intégrité des données - Alors que le concept de structure de données fluide semble agréable au début, certaines de vos données sont mieux "fixées dans la pierre". La typage fort est une bénédiction quand un petit bug tente de détruire votre base de données. Avec DynamoDB, tout est possible et en effet, tout ce qui peut mal tourner, tourne mal.

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, bien définies. Ce n'est pas une mauvaise base de données, ce n'est simplement pas la base de données pour servir à 100 % de votre système central.

En ce qui concerne les avantages, je dirais la Scalabilité et la Durabilité. Elle se dimensionne de manière incroyable et transparente et elle est (en quelque sorte) toujours opérationnelle. Ce sont vraiment de superbes fonctionnalités, mais elles ne compensent en aucun cas les aspects négatifs.

Answer 3

Vous pouvez lire l'explication d'AWS à ce sujet ici.

En bref, si vous avez principalement des requêtes de recherche (et non des requêtes de Jointure), DynamoDB (et d'autres bases de données NoSQL) est meilleur. Si vous avez besoin de gérer beaucoup de données, vous serez limité en utilisant 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 faites l'effort d'apprendre le NoSQL, vous ajouterez un outil important à votre boîte à outils. Il y a de nombreux cas où DynamoDB offre la solution la plus simple.

Answer 4

Lorsque vous utilisez DynamoDB, vous devez également savoir que les éléments/enregistrements dans DynamoDB sont limités à 400 Ko (Voir Limites de DynamoDB). Pour de nombreux cas d'utilisation, cela ne fonctionnera pas. Ainsi, DynamoDB sera bon pour quelques choses mais pas pour tout. Il en va de même pour de nombreuses autres bases de données NoSQL.