AWS MySQL RDS vs AWS DynamoDB [fermé]

J'utilise MySQL depuis un bon moment 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 examiné DynamoDB. Actuellement, je n'en sais que peu de chose.

L'un est-il meilleur que l'autre?

Quels sont les avantages de DynamoDB?

à quoi ressemble la transition des requêtes MySQL, etc. vers cette base de données de style plat?

Vous pouvez lire l'explication 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 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 consacrez l'effort à apprendre NoSQL, vous ajouterez un outil important à votre boîte à outils. Dans de nombreux cas, DynamoDB offre 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 les éléments à 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 (arborescence, représentations JSON sans schéma, etc.) qui peuvent être comparées à une seule clé 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 bien s'intégrer 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 de l'utilisation de DynamoDB en tant que magasin NoSQL est que vous obtenez un débit de lecture / écriture garanti quel que soit le niveau dont vous avez besoin sans avoir à vous soucier de la gestion d'un magasin de données en cluster. Ainsi, 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 pas vraiment avoir à vous soucier de l'infrastructure sous-jacente.

RDS a en grande partie le même avantage de ne pas avoir à vous soucier de l'infrastructure elle-même, mais si vous finissez par avoir besoin de faire un nombre important d'écritures au point où la plus grande taille d'instance ne suivra plus, vous êtes en quelque sorte laissé sans options (vous pouvez mettre à l'échelle horizontalement pour les lectures à l'aide de répliques en lecture).

Remarque mise à jour: DynamoDb prend désormais en charge l'indexation secondaire globale, vous avez donc maintenant 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 avoir du sens, créer un nouveau système au-dessus de DynamoDB est vraiment une mauvaise idée. Les meilleurs plans, etc., vous avez toujours besoin de cette flexibilité supplémentaire de votre DB.

Voici nos raisons pour lesquelles nous avons quitté DynamoDB:

1. Indexation - La modification ou l'ajout de clés à la volée est impossible sans créer une nouvelle table.
2. Requêtes - L'interrogation des données est extrêmement limitée. Surtout si vous souhaitez interroger des données non indexées. Les jointures sont bien sûr impossibles, vous devez donc gérer des relations de données complexes sur votre couche code / cache.
3. Sauvegarde - Une procédure de sauvegarde aussi fastidieuse est une surprise décevante par rapport à la sauvegarde astucieuse de RDS
4. GUI - mauvaise UX, recherche limitée, pas de plaisir.
5. Vitesse - Le temps de réponse est problématique par rapport au RDS. Vous vous retrouvez à construire un mécanisme de mise en cache élaboré pour le compenser dans des endroits où vous auriez choisi la mise en cache interne de RDS.
6. Intégrité des données - Bien que le concept de structure de données fluide semble agréable au départ, certaines de vos données sont mieux «gravées dans la pierre». Une frappe forte est une bénédiction lorsqu'un petit bug 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'utilisons à 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 pour servir 100% de votre système central.

En ce qui concerne les avantages, je dirais évolutivité et durabilité. Il évolue de manière incroyablement et transparente et il est (en quelque sorte) toujours en place. Ce sont de très bonnes fonctionnalités, mais elles ne compensent en aucun cas les aspects négatifs.

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 sera bon pour peu de choses mais pas pour tout. Il en va de même pour la plupart des autres bases de données NoSQL.