Amazon-DynamoDB forte compatible lit, sont-ils les derniers et comment?
Dans une tentative d'utiliser Dynamodb pour l'un des projets, j'ai un doute concernant la forte cohérence du modèle de dynamodb. De la FAQ
lit fortement cohérent - en plus de la cohérence éventuelle, Amazon DynamoDB vous donne également le flexibilité et 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 tous écrit que ont reçu une réponse positive avant la lecture.
D'après la définition ci-dessus, ce que j'obtiens, c'est qu'une lecture forte et cohérente retournera la dernière valeur en écriture.
prenons un exemple: disons que le Client1 émet une commande d'écriture sur la touche K1 pour mettre à jour la valeur de V0 à V1. Après quelques millisecondes le Client2 émet une commande de lecture pour la clé K1, alors en cas de forte cohérence V1 sera toujours retourné, cependant en cas d'éventuelle cohérence V1 ou V0 peuvent être retournés. Est ma compréhension correcte?
si c'est le cas, que se passe-t-il si l'opération d'écriture est un succès mais que les données ne sont pas mises à jour à toutes les répliques et que nous émettons une lecture fortement cohérente, comment s'assurera-t-il de retourner la valeur d'écriture la plus récente dans ce cas?
le lien suivant AWS DynamoDB lecture après écriture de cohérence - comment ça marche en théorie? tente d'expliquer l'architecture derrière cela, mais ne savoir si cela est de savoir comment il fonctionne réellement? La question suivante qui me vient à l'esprit après avoir traversé ce lien est: est DynamoDb basé sur un seul maître, architecture esclave multiple, où écrit et forte cohérente lit sont par Maître réplique et la normale lit sont par d'autres.
3 réponses
réponse courte: écrire avec succès en mode fortement cohérent exige que votre écriture réussir sur une majorité de serveurs qui peuvent contenir l'enregistrement, donc tout futur lectures cohérentes verront toujours les mêmes données, parce qu'une lecture cohérente doit lire une majorité des serveurs qui peuvent contenir l'enregistrement désiré. Si vous n'effectuez pas une lecture très cohérente, le système demandera à un serveur aléatoire l'enregistrement, 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 deux serveurs au minimum, et écrivez les données. Prenons 1 et 2.
Maintenant, vous voulez lire les données de manière cohérente. Choisissez la majorité des serveurs. Disons qu'on a choisi 2 et 3.
Serveur 2 a les nouvelles données, et c'est ce que le système retourne.
éventuellement des lectures cohérentes pourraient 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 ait lieu.
si un seul serveur échoue, 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 sont restaurés.
plus d'explications: DynamoDB (en supposant qu'il est similaire à la base de données décrite dans le papier de Dynamo que Amazon a publié) utilise une topologie d'anneau, où les données sont diffusées sur de nombreux serveurs. Une forte cohérence est garantie, car vous interroger directement tous les serveurs et récupérer les données. Il n'y a pas de maître dans le ring, il n'y a pas d'esclaves dans le ring. Un enregistrement de la carte pour un nombre identique d'hôtes dans le ring, et tous ces serveurs contiennent cet enregistrement. Il n'y a pas d'esclave qui pourrait être en retard, et il n'y a pas de maître qui puisse échouer.
n'hésitez pas à lire les nombreuses études sur le sujet. Un 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 requête de lecture fortement cohérente, Amazon DynamoDB renvoie une réponse contenant les données les plus récentes qui reflètent les mises à jour effectuées par toutes les opérations d'écriture liées antérieures auxquelles Amazon DynamoDB a renvoyé une réponse réussie.
dans votre exemple, si la demande updateItem pour mettre à jour la valeur de v0 à v1 a été réussie, la demande de lecture fortement cohérente suivante retournera v1 .
Espérons que cette aide.
Avertissement: ce qui suit ne peut pas être vérifiée basé sur le public DynamoDB de la documentation, mais ils sont probablement très proches de la vérité
à partir de la théorie, DynamoDB fait usage de quorums , où V est le nombre total de noeuds de réplique, Vr est le nombre de noeuds de réplique une opération de lecture demande et Vw est le nombre de noeuds de réplique où chaque Écriture est effectuée. La lecture de quorum ( Vr ) peut être utilisé pour s'assurer que le client obtient la dernière valeur, tandis que le quorum d'écriture ( Vw ) peut être utilisé pour s'assurer que les Écritures ne créent pas de conflits.
basé sur le fait qu'il n'y a pas de conflits d'écriture dans DynamoDB (puisque ceux-ci devraient être réconciliés avec le client, donc exposés dans L'API), nous concluons que DynamoDB utilise une Vw qui respecte la deuxième loi ( Vw > V/2 ), probablement juste V/2+1 pour réduire la latence d'écriture.
maintenant en ce qui concerne les quorums de lecture, DynamoDB fournit 2 différents types de lire. 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 écrit comme avant. Toutefois , une lecture éventuellement cohérente ne peut utiliser qu'une seule réplique aléatoire Vr = 1 , ce qui est beaucoup plus rapide, mais donne zéro garantie autour de la cohérence.
Note: Il y a une possibilité 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 la dernière basée sur l'heure locale) sans réconciliation du client. Mais je crois que c'est peu probable, puisqu'il n'y a pas de telle référence dans la documentation de DynamoDB. Même dans ce cas cependant, le reste du raisonnement reste le même.