Réponse courte : Commencez par SQL et n'ajoutez NoSQL qu'en cas de besoin. (sauf si vous n'avez besoin de rien d'autre que des requêtes très simples).
Mon expérience personnelle : Je n'ai pas utilisé MongoDB pour les requêtes, mais en avril 2015, DynamoDB est encore très handicapé quand il s'agit de quelque chose au-delà des requêtes clés/valeurs les plus basiques. Je l'aime pour les choses de base, mais si vous voulez un langage de requête, alors regardez vers une vraie solution de base de données SQL.
Dans DynamoDB, vous pouvez effectuer une requête sur un hachage ou sur un hachage et une clé de plage, et vous pouvez avoir plusieurs index globaux secondaires. Je fais des requêtes sur une seule table avec 4 paramètres de filtre possibles et je trie les résultats, ce qui est supporté (à peine) par l'utilisation des index globaux secondaires avec des expressions de filtre. Le problème survient lorsque vous essayez d'obtenir le total des résultats correspondant au filtre, vous ne pouvez pas simplement rechercher les 10 premiers éléments correspondant au filtre, mais il vérifie plutôt 10 éléments et vous pouvez obtenir 0 résultat valide, ce qui vous oblige à continuer à rechercher à partir de la clé continue - une douleur dans le cou et consomme trop de votre quota de lecture de table pour un scénario simple.
Pour être spécifique au problème de limite avec les filtres dans la requête, ceci est tiré de la documentation ( http://docs.aws.amazon.com/amazondynamodb/latest/developerguide/QueryAndScan.html#ScanQueryLimit ) :
In a response, DynamoDB returns all the matching results within
the scope of the Limit value. For example, if you issue a Query
or a Scan request with a Limit value of 6 and without a filter
expression, the operation returns the first six items in the
table that match the request parameters. If you also supply a
FilterExpression, the operation returns the items within the
first six items in the table that match the filter requirements.
Ma conclusion est que les requêtes impliquant des FilterExpressions ne sont utilisables qu'en de très rares occasions et ne sont pas évolutives car chaque requête peut facilement lire la plupart ou la totalité de votre table, ce qui consomme beaucoup trop d'unités de lecture DynamoDB. Une fois que vous utilisez trop d'unités de lecture, vous serez étranglé et les performances seront médiocres.
Avis d'expert : Lors du sommet AWS du 9 avril 2015, Brett Hollman, responsable de l'architecture des solutions chez AWS, dans son exposé sur le scalling de vos 10 premiers millions d'utilisateurs, préconise de commencer avec une base de données SQL, puis d'utiliser NoSQL uniquement quand et si cela a du sens. Car tôt ou tard, vous aurez probablement besoin d'un serveur SQL quelque part dans votre pile. Ses diapositives sont ici : http://www.slideshare.net/AmazonWebServices/deep-dive-scaling-up-to-your-first-10-million-users Voir la diapositive 28.
4 votes
Si vous voulez des conseils sur la structure des requêtes, je vous suggère de fournir un exemple de votre schéma ainsi que vos cas d'utilisation pour accéder aux données. Sans ces éléments, il est difficile de porter un jugement sur l'adéquation.
0 votes
En effet, la façon dont vous interrogez les données peut avoir une influence considérable sur le choix de la base de données dorsale. Le degré de hiérarchisation serait ma première question.
3 votes
Je m'étonne que cette question n'ait pas déjà été fermée par les personnes du classement SO. Habituellement, les questions qui demandent des conseils sont fermées parce qu'elles ne demandent pas d'aide pour un problème très spécifique.