Comparaison des coûts de DynamoDB vs mongodb vs RDS SQL DB

Question

Je suis en train d'utiliser dynamodb dans mon application qui n'est pas encore en production. Je application qui affiche les éléments suivants dans différentes vues

1) show list of orders posted by other users from last 3 days to the user 
2) show list of orders that user created 
3) show list of orders that user have submitted bids 

le considérer comme ebay, sauf ordre de poste utilisateur pour les tâches et les autres offres utilisateurs sur elle. Aussi au lieu de la fonction de recherche dans ebay, nous avons arbre comme la structure de montrer et d'organiser toutes les commandes

level1 - list of states that have available orders from last 3 days, 
level2- list of cities in state that have available orders from last 3 days, 
level3- all orders from last 3 days in the city 

En ce moment, mon architecture est en train de faire beaucoup de lectures et d'écriture pour effectuer les opérations ci-dessus et il est très coûteux. Maintenant, nous ne faisons que tester l'application et seulement 3 utilisateurs et 100 commandes ont été créées et cela me coûte 2 $ par jour. Ce coût sera ridiculement élevé quand j'aurai des milliers d'utilisateurs et des milliers de commandes en production. Afin de faire l'opération, je fais un scan complet de la collection de commandes complètes.

Puisque cette dynamodb est chère, je pense à passer à mongodb. J'ai seulement de l'expérience avec mongodb en l'exécutant localement mais je ne l'ai jamais déployé sur AWS ou n'ai aucune expérience de production. Cependant, je suis prêt à faire/apprendre à réduire les coûts. Aussi, je suis nouveau à AWS. Je pense que mongodb sera l'option bon marché car il n'est pas facturé sur la base de lire et d'écrire.

Une autre option va à RDS SQL DB mais pour cela je dois redessiner la base de données et faire beaucoup de changements.

S'il vous plaît me donner une suggestion sur ce qui sera l'option la moins chère et la meilleure dans mon cas. Je vous remercie.

Answer 1

DynamoDB est bon marché. Vous pourriez jeter un oeil à l'utilisation de l'offre de cloud MongoDB Atlas, qui est comparable à peu de frais, mais cela ne peut pas être beaucoup moins cher. Vous essayez de comparer des pommes avec des oranges.

Cependant, cela ressemble plus à un problème de conception. Vous semblez faire régulièrement des requêtes basées sur "les 3 derniers jours", vous devriez regarder ces requêtes pas trop souvent et mettre en cache ces résultats en utilisant ElastiCache.

Mise à jour: Si vous effectuez des analyses de collecte complètes, il y a également d'autres erreurs. Vous devez les éviter. Utilisez les index secondaires globaux si vous ne l'avez pas encore fait. Vous pouvez envisager d'ajouter des collections de données d'index uniquement si vous avez déjà utilisé les cinq secondaires. En ce qui concerne MongoDB, il est beaucoup plus flexible de créer des index car vous pouvez créer des index couvrant plus de deux champs (par exemple ville, état et date) et vous pouvez créer plus de cinq index, ce qui facilitera certainement votre analyse complète scénarios. En outre, vous seriez en mesure d'utiliser le puissant cadre d'agrégation pour certaines de vos requêtes. Vous devriez toujours envisager de mettre en cache ces requêtes avec ElastiCache (redis/memcached).