Amazon - DynamoDB Lectures cohérentes solides, sont-elles les plus récentes et comment?
Dans une tentative d'utiliser Dynamodb pour l'un des projets, j'ai un doute concernant le modèle de cohérence forte de dynamodb. De la FAQ
Lectures fortement cohérentes - en plus de la cohérence éventuelle, Amazon DynamoDB vous donne également la flexibilité et le contrôle pour demander une lecture fortement cohérente si votre application, ou un élément de votre application, l'exige. Une lecture fortement cohérente renvoie un résultat qui reflète toutes les écritures qui ont reçu une réponse réussie avant la lecture.
D'après la définition ci-dessus, ce que j'obtiens, c'est qu'une lecture cohérente forte retournera la dernière valeur d'écriture.
Prenons un exemple: Disons que Client1 émet une commande d'écriture sur la clé K1 pour mettre à jour la valeur de V0 à V1. Après quelques millisecondes, Client2 émet une commande de lecture pour la clé K1, puis en cas de forte cohérence, V1 sera toujours renvoyé, mais en cas de cohérence éventuelle, V1 ou V0 peut être retourné. Ma compréhension est-elle correcte?
Si tel est le cas, que se passe-t-il si l'opération d'écriture a réussi, mais que les données ne sont pas mises à jour pour toutes les répliques et que nous émettons une lecture fortement cohérente, comment cela garantira-t-il de renvoyer la dernière valeur d'écriture dans ce cas?
Le lien suivant AWS DynamoDB a lu après la cohérence d'écriture - comment cela fonctionne-t-il théoriquement? essaie d'expliquer l'architecture derrière cela, mais vous ne savez pas si c'est ainsi que cela fonctionne réellement? La question suivante qui me vient à l'esprit après avoir parcouru ce lien est la suivante: DynamoDb est-il basé sur un maître unique, une architecture à esclaves multiples, où les écritures et les lectures cohérentes fortes se font via une réplique maîtresse et les lectures normales le sont par d'autres.
Réponse courte: Une écriture réussie en mode fortement cohérent nécessite que votre écriture réussisse sur une majorité de serveurs pouvant contenir l'enregistrement, donc toute lecture cohérente future verra toujours les mêmes données, car une lecture cohérente doit lire la majorité des serveurs qui peuvent contenir l'enregistrement souhaité. Si vous n'effectuez pas une lecture fortement cohérente, le système demandera l'enregistrement à un serveur aléatoire et il est possible que les données ne soient pas à jour.
Imaginez trois serveurs. Serveur 1, serveur 2 et serveur 3. Pour écrire un enregistrement fortement cohérent, vous choisissez au moins deux serveurs et écrivez les données. Choisissons 1 et 2.
Vous souhaitez maintenant lire les données de manière cohérente. Choisissez une majorité de serveurs. Disons que nous avons choisi 2 et 3.
Le serveur 2 a les nouvelles données, et c'est ce que le système renvoie.
Des lectures cohérentes pourraient éventuellement provenir du serveur 1, 2 ou 3. Cela signifie que si le serveur 3 est choisi au hasard, votre nouvelle écriture n'apparaîtra pas encore, jusqu'à ce que la réplication se produise.
Si un seul serveur tombe en panne, vos données sont toujours en sécurité, mais si deux serveurs sur trois échouent, votre nouvelle écriture peut être perdue jusqu'à ce que les serveurs hors ligne soient restaurés.
Plus d'explications: DynamoDB (en supposant qu'elle est similaire à la base de données décrite dans l'article Dynamo publié par Amazon) utilise une topologie en anneau, où les données sont réparties sur de nombreux les serveurs. Une forte cohérence est garantie car vous interrogez directement tous les serveurs pertinents et obtenez d'eux les données actuelles. Il n'y a pas de maître dans le ring, il n'y a pas d'esclaves dans le ring. Un enregistrement donné sera mappé à un certain nombre d'hôtes identiques dans l'anneau, et tous ces serveurs contiendront cet enregistrement. Il n'y a pas d'esclave qui pourrait être à la traîne, et il n'y a pas de maître qui peut échouer.
N'hésitez pas à lire l'un des nombreux articles sur le sujet. Une base de données similaire appelée Apache Cassandra est disponible et utilise également la réplication en anneau.
http://www.read.seas.harvard.edu/~kohler/class/cs239-w08/decandia07dynamo.pdf
Vous pouvez trouver la réponse à votre question ici: http://docs.aws.Amazon.com/amazondynamodb/latest/developerguide/APISummary.html
Lorsque vous émettez une demande de lecture fortement cohérente, Amazon DynamoDB renvoie une réponse avec les données les plus à jour qui reflètent les mises à jour de toutes les opérations d'écriture liées précédentes auxquelles Amazon DynamoDB a renvoyé une réponse réussie.
Dans votre exemple, si la demande de updateItem pour mettre à jour la valeur de v0 à v1 a réussi, la demande de lecture fortement cohérente suivante renverra v1.
J'espère que cela t'aides.
Avertissement: les éléments suivants ne peuvent pas être vérifiés sur la base de la documentation publique DynamoDB, mais ils sont probablement très proches de la vérité
À partir de la théorie, DynamoDB utilise quorums , où V est le nombre total de nœuds de réplique, Vr est le nombre de nœuds de réplique qu'une opération de lecture demande et Vw est le nombre de nœuds de réplique où chaque écriture est effectuée. Le quorum de lecture (Vr) peut être optimisé pour s'assurer que le client obtient la dernière valeur, tandis que le quorum d'écriture (Vw) peut être optimisé pour s'assurer que les écritures ne créent pas de conflits.
Sur la base du fait qu'il n'y a pas de conflits d'écriture dans DynamoDB (car ceux-ci devraient être réconciliés avec le client, donc exposés dans l'API), nous concluons que DynamoDB utilise un Vw qui respecte la deuxième loi (Vw > V/2), probablement juste V/2+1 pour réduire la latence d'écriture.
En ce qui concerne les quorums de lecture, DynamoDB propose 2 types de lecture différents. La lecture fortement cohérente utilise un quorum de lecture qui respecte la première loi (Vr + Vw > V), probablement juste V/2 si nous supposons V/2+1 pour les écritures comme précédemment. Cependant, une lecture cohérente à terme ne peut utiliser qu'une seule réplique aléatoire Vr = 1, étant ainsi beaucoup plus rapide mais ne donnant aucune garantie de cohérence.
Remarque: il est possible que le quorum d'écriture utilisé ne respecte pas la deuxième loi (Vw > V/2), mais cela signifierait que DynamoDB résout automatiquement ces conflits (par exemple, en sélectionnant le dernier en fonction de l'heure locale) sans rapprochement du client. Mais je pense qu'il est très peu probable que cela soit vrai, car il n'y a pas une telle référence dans la documentation DynamoDB. Même dans ce cas, le reste du raisonnement reste le même.