AWS MySQL RDS vs AWS DynamoDB [fermé]

109

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?

— Adam
source

66

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.

— Gars
source

262

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.

— Mike Brant
source

10

Si je pouvais augmenter votre réponse par 100, je le ferais.

— Salil

Certains types de problèmes dans un modèle d'information tendent bien à une sorte d'implémentation NoSQL. Lorsque vous rencontrez de tels problèmes, posez-vous la question de savoir s'il serait judicieux d'avoir une base de données NoSQL. Certaines de ces entités sont: les journaux, les données de séries chronologiques, les réseaux sociaux, la gestion de contenu, le catalogue de produits, etc.

— user398039

150

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:

Indexation - La modification ou l'ajout de clés à la volée est impossible sans créer une nouvelle table.
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.
Sauvegarde - Une procédure de sauvegarde aussi fastidieuse est une surprise décevante par rapport à la sauvegarde astucieuse de RDS
GUI - mauvaise UX, recherche limitée, pas de plaisir.
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.
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.

— Yami Glick
source

11

Avantages / inconvénients très spécifiques.

— Bonne

10

Certains de ces éléments sont obsolètes. Par exemple, 1 n'est plus vrai.

— mbroshi

2

Réponse très bien documentée. Cependant, certaines de ces préoccupations peuvent être spécifiques à de rares cas d'utilisation. Numéro 2 - "Les jointures sont bien sûr impossibles" - Les structures de données DynamoDB ne devraient pas avoir de relations - point. La table doit être complètement dénormalisée. Cela signifie que certains attributs sont dupliqués. Dans de tels cas, utilisez un déclencheur dynamo ou des écritures conditionnelles. Si les utilisateurs ne peuvent pas gérer la latence pour les écritures conditionnelles, placez une file d'attente SQS entre l'application et la dynamo. De plus, le point numéro 6 est mal nommé au point qu'il jette un doute sur «l'intégrité» de DynamoDB - ce n'est peut-être pas l'intention ...

— doles le

1

Dynamo manque toujours de flexibilité lors des requêtes. Bien que GSI soit d'une grande aide, nous pouvons toujours mieux modéliser nos données avec le schéma RDBMS.

— Pavan

1

J'ajouterais que les capacités de requête dans DynamoDB ont quelques «pièges». Par exemple, si votre clé primaire consiste uniquement en un hachage, une requête Dynamo ne peut renvoyer qu'une seule entrée, vous ne pouvez pas fournir une plage à une clé de hachage uniquement au moment de la requête, ni effectuer une requête sans connaître le hachage spécifique du article que vous recherchez. BatchGet n'accepte que 100 obtentions dans la demande, une taille de réponse totale de 1 Mo ou une taille de requête totale de 1 Mo, selon la première éventualité. L'analyse vous offre une recherche flexible, mais elle est très inefficace et coûteuse, renvoyant la table entière avant le filtrage.

— Brooks

12

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.

— Ali
source