Cohérence éventuelle dans un anglais simple

J'entends souvent parler de cohérence éventuelle dans différents discours sur NoSQL, grilles de données, etc. Il semble que la définition de la cohérence éventuelle varie dans de nombreuses sources (et dépend peut-être même d'un stockage de données concret).

Quelqu'un peut-il expliquer simplement ce qu'est la cohérence éventuelle en termes généraux, sans rapport avec un stockage de données concret?

Cohérence éventuelle:

1. Je regarde le bulletin météo et j'apprends qu'il va pleuvoir demain.
2. Je vous dis qu'il va pleuvoir demain.
3. Votre voisin dit à sa femme qu'il va faire beau demain.
4. Vous dites à votre voisin qu'il va pleuvoir demain.

Finalement, tous les serveurs (vous, moi, votre voisin) connaissent la vérité (qu'il va pleuvoir demain), mais en attendant, le client (sa femme) est reparti en pensant qu'il va faire beau, même si elle a demandé après qu'un ou plusieurs serveurs (vous et moi) aient une valeur plus à jour.

Contrairement à la cohérence stricte / conformité ACID:

1. Votre solde bancaire est de 50 $.
2. Vous déposez 100 $.
3. Votre solde bancaire, interrogé à partir de n'importe quel guichet automatique n'importe où, est de 150 $.
4. Votre fille retire 40 $ avec votre carte de guichet automatique.
5. Votre solde bancaire, interrogé à partir de n'importe quel guichet automatique n'importe où, est de 110 $.

A aucun moment, votre solde ne peut refléter autre chose que la somme réelle de toutes les transactions effectuées sur votre compte à ce moment précis.

La raison pour laquelle tant de systèmes NoSQL ont une cohérence finale est que pratiquement tous sont conçus pour être distribués, et avec des systèmes entièrement distribués, il y a une surcharge super-linéaire pour maintenir une cohérence stricte (ce qui signifie que vous ne pouvez évoluer que si loin avant que les choses commencent à ralentir et quand ils le font, vous devez lancer exponentiellement plus de matériel sur le problème pour continuer à évoluer).

Cohérence éventuelle:

1. Vos données sont répliquées sur plusieurs serveurs
2. Vos clients peuvent accéder à n'importe quel serveur pour récupérer les données
3. Quelqu'un écrit une donnée sur l'un des serveurs, mais elle n'a pas encore été copiée sur le reste
4. Un client accède au serveur avec les données et obtient la copie la plus à jour
5. Un client différent (ou même le même client) accède à un serveur différent (celui qui n'a pas encore reçu la nouvelle copie), et obtient l'ancienne copie

Fondamentalement, comme la réplication des données sur plusieurs serveurs prend du temps, les demandes de lecture des données peuvent être envoyées à un serveur avec une nouvelle copie, puis à un serveur avec une ancienne copie. Le terme «éventuel» signifie que finalement les données seront répliquées sur tous les serveurs, et ainsi ils auront tous la copie à jour.

La cohérence éventuelle est indispensable si vous souhaitez des lectures à faible latence, car le serveur répondant doit renvoyer sa propre copie des données et n'a pas le temps de consulter d'autres serveurs et de parvenir à un accord mutuel sur le contenu des données. J'ai écrit un article de blog expliquant cela plus en détail.

Pensez que vous avez une application et sa réplique. Ensuite, vous devez ajouter un nouvel élément de données à l'application.

Ensuite, l'application synchronise les données avec une autre réplique présentée ci-dessous

Pendant ce temps, le nouveau client va obtenir des données d'un réplica qui n'est pas encore mis à jour. Dans ce cas, il ne peut pas obtenir des données à jour correctes. Parce que la synchronisation prend du temps. Dans ce cas, il n'y a finalement pas de cohérence

Le problème est de savoir comment pouvons-nous finalement la cohérence ?

Pour cela, nous utilisons l'application mediator pour mettre à jour / créer / supprimer des données et utiliser des requêtes directes pour lire les données. qui aident à rendre finalement la cohérence

Lorsqu'une application modifie un élément de données sur une machine, cette modification doit être propagée aux autres répliques. Étant donné que la propagation du changement n'est pas instantanée, il y a un intervalle de temps pendant lequel certaines des copies auront le changement le plus récent, mais d'autres pas. En d'autres termes, les copies seront incompatibles entre elles. Cependant, la modification sera éventuellement propagée à toutes les copies, d'où le terme «cohérence éventuelle». Le terme cohérence éventuelle est simplement une reconnaissance du fait qu'il y a un délai illimité dans la propagation d'une modification effectuée sur une machine à toutes les autres copies. La cohérence finale n'est ni significative ni pertinente dans les systèmes centralisés (copie unique) car il n'y a pas besoin de propagation.

source: http://www.oracle.com/technetwork/products/nosqldb/documentation/consistency-explained-1659908.pdf

En anglais simple, nous pouvons dire: bien que votre système puisse être dans des états incohérents, le but est toujours d'atteindre la cohérence à un moment donné pour chaque élément de données.

Finalement, la cohérence signifie que les changements prennent du temps à se propager et que les données peuvent ne pas être dans le même état après chaque action, même pour des actions ou des transformations identiques des données. Cela peut entraîner de très mauvaises choses lorsque les gens ne savent pas ce qu'ils font lorsqu'ils interagissent avec un tel système.

Veuillez ne pas mettre en œuvre des magasins de données de documents critiques pour l'entreprise tant que vous n'avez pas bien compris ce concept. Il est beaucoup plus difficile de réparer une implémentation de magasin de données de document qu'un modèle relationnel, car les choses fondamentales qui vont être gâchées ne peuvent tout simplement pas être corrigées car les choses nécessaires pour le réparer ne sont tout simplement pas présentes dans l'écosystème. La refactorisation des données d'un magasin en vol est également beaucoup plus difficile que les simples transformations ETL d'un SGBDR.

Tous les magasins de documents ne sont pas créés égaux. Certains de nos jours (MongoDB) prennent en charge des transactions d'une sorte, mais la migration des banques de données est probablement comparable aux frais de réimplémentation.

AVERTISSEMENT: Les développeurs et même les architectes qui ne connaissent pas ou ne comprennent pas la technologie d'un magasin de données documentaires et qui ont peur de l'admettre par peur de perdre leur emploi mais qui ont été classiquement formés au SGBDR et qui ne connaissent que les systèmes ACID (à quel point cela peut-il être différent ?) et qui ne connaissent pas la technologie ou prennent le temps de l'apprendre, manqueront de concevoir un magasin de données de document. Ils peuvent également essayer de l'utiliser comme SGBDR ou pour des choses comme la mise en cache. Ils décomposeront ce qui devrait être des transactions atomiques qui devraient opérer sur un document entier en morceaux «relationnels» en oubliant que la réplication et la latence sont des choses, ou pire encore, en entraînant des systèmes tiers dans une «transaction». Ils le feront pour que leur SGBDR puisse refléter leur lac de données, sans se soucier de savoir si cela fonctionnera ou non, et sans test, car ils savent ce qu'ils font. Ensuite, ils agiront surpris lorsque des objets complexes stockés dans des documents séparés tels que des «commandes» ont moins «d'articles de commande» que prévu, ou peut-être pas du tout. Mais cela n'arrivera pas souvent, ni assez souvent pour qu'ils avancent simplement. Ils peuvent même ne pas toucher le problème du développement. Ensuite, plutôt que de repenser les choses, ils lanceront des «retards», des «tentatives» et des «vérifications» pour simuler un modèle de données relationnel, ce qui ne fonctionnera pas, mais ajoutera de la complexité supplémentaire sans aucun avantage. Mais il est trop tard maintenant - la chose a été déployée et maintenant l'entreprise fonctionne dessus. Finalement, le système entier sera jeté et le département sera externalisé et quelqu'un d'autre le maintiendra. Cela ne fonctionnera toujours pas correctement, mais ils peuvent échouer moins cher que l'échec actuel.

La cohérence finale ressemble plus à un spectre. D'un côté, vous avez une forte cohérence et de l'autre vous avez une cohérence éventuelle. Entre les deux, il y a des niveaux comme Snapshot, lisez mes écrits, l'obsolescence limitée. Doug Terry a une belle explication dans son article sur la cohérence éventuelle à travers le baseball .

Selon moi, la cohérence éventuelle est essentiellement la tolérance aux données aléatoires dans un ordre aléatoire chaque fois que vous lisez à partir d'un magasin de données. Tout ce qui est mieux que cela est un modèle de cohérence plus solide. Par exemple, un instantané contient des données obsolètes mais renverra les mêmes données s'il est lu à nouveau, ce qui les rend prévisibles. Parfois, une application peut tolérer des données périmées pendant un laps de temps donné au-delà duquel elle exige des données cohérentes.

Si vous regardez le sens de la cohérence, cela se rapporte davantage à l'uniformité ou au manque d'écart. Donc, en termes non informatiques, cela pourrait signifier une tolérance pour des variations inattendues. Cela pourrait être très bien expliqué par ATM. Un guichet automatique peut être hors ligne et donc différent du solde du compte par rapport aux systèmes de base. Cependant, il existe une tolérance pour afficher des soldes différents pendant une fenêtre de temps. Une fois que le guichet automatique est en ligne, il peut se synchroniser avec les systèmes de base et refléter le même équilibre. On pourrait donc dire qu'un guichet automatique est finalement cohérent.