Théorème CAP - Disponibilité et tolérance de partition

Alors que j'essaie de comprendre la «disponibilité» (A) et la «tolérance de partition» (P) dans CAP, j'ai eu du mal à comprendre les explications de divers articles.

J'ai l'impression que A et P peuvent aller de pair (je sais que ce n'est pas le cas, et c'est pourquoi je n'arrive pas à comprendre!).

Expliquant en termes simples, quels sont A et P et la différence entre eux?

La cohérence signifie que les données sont les mêmes sur l'ensemble du cluster, vous pouvez donc lire ou écrire depuis / vers n'importe quel nœud et obtenir les mêmes données.

La disponibilité signifie la possibilité d'accéder au cluster même si un nœud du cluster tombe en panne.

La tolérance de partition signifie que le cluster continue de fonctionner même s'il existe une "partition" (interruption de la communication) entre deux nœuds (les deux nœuds sont actifs, mais ne peuvent pas communiquer).

Afin d'obtenir à la fois la disponibilité et la tolérance de partition, vous devez renoncer à la cohérence. Considérez si vous avez deux nœuds, X et Y, dans une configuration maître-maître. Maintenant, il y a une rupture entre la communication réseau entre X et Y, donc ils ne peuvent pas synchroniser les mises à jour. À ce stade, vous pouvez soit:

A) Laisser les nœuds se désynchroniser (abandonner la cohérence), ou

B) Considérez que le cluster est "en panne" (abandonnant la disponibilité)

Toutes les combinaisons disponibles sont:

• Californie - les données sont cohérentes entre tous les nœuds - tant que tous les nœuds sont en ligne - et vous pouvez lire / écrire à partir de n'importe quel nœud et être sûr que les données sont les mêmes, mais si jamais vous développez une partition entre les nœuds, les données seront désynchronisé (et ne se resynchronisera pas une fois la partition résolue).
• CP - les données sont cohérentes entre tous les nœuds et maintiennent la tolérance de partition (empêchant la désynchronisation des données) en devenant indisponibles lorsqu'un nœud tombe en panne.
• AP - les nœuds restent en ligne même s'ils ne peuvent pas communiquer entre eux et resynchroniseront les données une fois la partition résolue, mais vous n'êtes pas assuré que tous les nœuds auront les mêmes données (pendant ou après la partition)

Vous devez noter que les systèmes CA n'existent pratiquement pas (même si certains systèmes prétendent l'être).

Considérer P en termes égaux avec C et A est un peu une erreur, plutôt que la notion de «2 sur 3» parmi C, A, P est trompeuse. La manière succincte que j'expliquerais le théorème de CAP est: "Dans un magasin de données distribué, au moment de la partition réseau, vous devez choisir la cohérence ou la disponibilité et vous ne pouvez pas obtenir les deux". Les nouveaux systèmes NoSQL tentent de se concentrer sur la disponibilité tandis que les bases de données ACID traditionnelles mettent davantage l'accent sur la cohérence.

Vous ne pouvez vraiment pas choisir CA, la partition réseau n'est pas quelque chose que quelqu'un aimerait avoir, c'est juste une réalité indésirable d'un système distribué, les réseaux peuvent échouer. La question est de savoir quel compromis choisir pour votre application lorsque cela se produit. Cet article de l'homme qui a d'abord formulé ce terme semble l'expliquer très clairement.

Voici comment je parle de CAP, concernant P en particulier.

L'autorité de certification n'est possible que si vous êtes d'accord avec une base de données monolithique à serveur unique (peut-être avec réplication mais toutes les données sur un "bloc de défaillance" - les serveurs ne sont pas considérés comme défaillants partiellement).

Si votre problème nécessite une mise à l'échelle, une distribution et plusieurs serveurs --- des partitions réseau peuvent se produire. Vous avez déjà besoin de P. Peu de problèmes que j'approche se prêtent à des paradigmes à serveur unique (ou, comme l'a dit Stonebraker, "distribué est un enjeu de table"). Si vous pouvez trouver un problème de CA, des solutions comme un SGBDR traditionnel sans évolutivité offrent de nombreux avantages.

Pour moi, rare: nous passons donc à la discussion AP vs CP.

Vous ne choisissez entre le fonctionnement AP et CP que lorsque vous avez une partition. Si le réseau et le matériel fonctionnent correctement, vous obtenez votre gâteau et le mangez aussi.

Parlons de la distinction AP / CP.

AP - lorsqu'il y a une partition réseau, laissez les parties indépendantes fonctionner librement.

CP - lorsqu'il y a une partition réseau, arrêtez les nœuds ou interdisez les lectures et les écritures afin qu'il y ait des échecs déterministes.

J'aime les architectures qui peuvent faire les deux, car certains problèmes sont AP et certains CP - et certaines bases de données peuvent faire les deux. Parmi les solutions CP et AP, il existe également des subtilités.

Par exemple, dans un jeu de données AP, vous avez la possibilité à la fois de lectures incohérentes et de générer des conflits d'écriture - ce sont deux modes AP possibles. Votre système peut-il être configuré pour AP avec une haute disponibilité en lecture mais interdit les conflits d'écriture? Ou votre système AP peut-il accepter des conflits d'écriture, avec un système de résolution solide et flexible? Aurez-vous éventuellement besoin des deux, ou pouvez-vous choisir un système qui n'en fait qu'un?

Dans un système CP, combien d'indisponibilité obtenez-vous avec de petites partitions (serveur unique), le cas échéant? Une plus grande réplication peut augmenter l'indisponibilité dans un système CP, comment le système gère-t-il ces compromis?

Ce sont toutes des questions à poser avec CP vs AP.

Une excellente lecture dans ce domaine est en ce moment le post "12 ans plus tard" de Brewer. Je pense que cela fait avancer le débat sur la PAC avec clarté et je le recommande vivement.

http://www.infoq.com/articles/cap-twelve-years-later-how-the-rules-have-changed

Cohérence:

Une lecture est garantie de retourner l'écriture la plus récente (comme ACID) pour un client donné. Si une demande survient pendant cette période, elle doit attendre la fin de la synchronisation des données sur / dans les nœuds.

Disponibilité:

chaque nœud (s'il n'est pas défaillant) exécute toujours des requêtes et doit toujours répondre aux requêtes. Peu importe qu'il renvoie ou non la dernière copie.

Tolérance de partition:

Le système continuera de fonctionner lorsque des partitions réseau se produiront.

Concernant AP , la disponibilité (toujours accessible) peut exister avec ( Cassendra ) ou sans tolérance de partition ( RDBMS )

source de pic

Je pense que la tolérance de partition n'est pas bien expliquée dans aucune des réponses, donc juste pour expliquer les choses plus en détail, le théorème CAP signifie:

C : (linéarisation ou forte cohérence) signifie grosso modo

Si l'opération B a démarré après la fin de l'opération A, l'opération B doit voir le système dans le même état qu'à la fin de l'opération A, ou dans un état plus récent (mais jamais dans un ancien état).

Un :

«Chaque demande reçue par un nœud [de base de données] non défaillant du système doit entraîner une réponse [sans erreur]». Il ne suffit pas qu'un nœud soit en mesure de gérer la demande: tout nœud non défaillant doit pouvoir la gérer. De nombreux systèmes dits «hautement disponibles» (c'est-à-dire à faible temps d'indisponibilité) ne répondent en fait pas à cette définition de la disponibilité.

P :

La tolérance de partition (terriblement mal nommée) signifie essentiellement que vous communiquez sur un réseau asynchrone qui peut retarder ou supprimer des messages. Internet et tous nos centres de données ont cette propriété, vous n'avez donc pas vraiment le choix.

Source: Awesome Martin kleppmann's travail

Prenons juste un exemple: Cassandra peut au maximum être un système AP. Mais si vous le configurez pour lire ou écrire sur la base de Quorum, il ne reste pas disponible pour CAP (disponible selon la définition du théorème CAP) et n'est que le système P.

Dans un théorème CAP simple, il est impossible pour un système distribué de fournir simultanément les trois garanties:

Cohérence

Chaque nœud contient les mêmes données en même temps

Disponibilité

Au moins un nœud doit être disponible pour servir des données à chaque fois

Tolérance de partition

La défaillance du système est très rare

Généralement, chaque système ne peut garantir que deux fonctionnalités au minimum , CA, AP ou CP .

Cohérence - Lorsque nous envoyons la demande de lecture, si elle renvoie un résultat, elle doit renvoyer l'écriture la plus récente donnée par la demande du client. Disponibilité - Votre demande de lecture / écriture doit toujours réussir. Tolérance de partition - Lorsqu'il y a une partition réseau (problème pour certaines machines de communiquer entre elles), le système devrait toujours fonctionner.

Dans une distribution, il y a des chances qu'une partition réseau se produise et nous ne pouvons pas éviter le «P» de CAP. Nous choisissons donc entre «cohérence» et «disponibilité».

http://bigdatadose.com/understanding-cap-theorem/

Un moyen simple de comprendre le théorème de CAP:

En cas de partition réseau, il faut choisir entre une disponibilité parfaite et une cohérence parfaite.

Consistance de la cueillette signifie ne pas être en mesure de répondre à la requête d'un client car le système ne peut garantir le retour de l'écriture la plus récente. Cela sacrifie la disponibilité.

Choisir la disponibilité signifie pouvoir répondre à la demande d'un client mais le système ne peut garantir la cohérence, c'est-à-dire la valeur écrite la plus récente. Les systèmes disponibles fournissent la meilleure réponse possible dans les circonstances données.

Cette explication est tirée de cet excellent article . J'espère que cela vous aidera.

J'ai parcouru beaucoup de liens, mais aucun d'entre eux n'a pu me donner une réponse satisfaisante, sauf un.

Par conséquent, je décris CAP dans des termes très simples.

• Cohérence : doit renvoyer les mêmes données , quel que soit le nœud d'où elles proviennent.

• Disponibilité : le nœud doit répondre (doit être disponible).

• Tolérance de partition : le cluster doit répondre (doit être disponible), même s'il y a une partition (c'est-à-dire une défaillance du réseau) entre les nœuds.

(Également une raison principale , il embrouille plus est mauvaise convention de nommage si j'avais raison, je aurais pu donner. DNC théorème à la place: la cohérence des données , disponibilité nœud , disponibilité cluster , où chaque correspond à la cohérence , la disponibilité et la partition Tolérance respectivement)

Base de données CP: une base de données CP offre cohérence et tolérance de partition au détriment de la disponibilité. Lorsqu'une partition se produit entre deux nœuds, le système doit arrêter le nœud non cohérent (c'est-à-dire le rendre indisponible) jusqu'à ce que la partition soit résolue.

Base de données AP: une base de données AP offre la disponibilité et la tolérance de partition au détriment de la cohérence. Lorsqu'une partition se produit, tous les nœuds restent disponibles, mais ceux situés à la mauvaise extrémité d'une partition peuvent renvoyer une version de données plus ancienne que les autres. (Lorsque la partition est résolue, les bases de données AP resynchronisent généralement les nœuds pour réparer toutes les incohérences du système.)

Base de données CA: une base de données CA offre cohérence et disponibilité sur tous les nœuds. Cependant, il ne peut pas le faire s'il existe une partition entre deux nœuds du système et ne peut donc pas offrir une tolérance aux pannes. Dans un système distribué, les partitions ne peuvent pas être évitées. Ainsi, alors que nous pouvons discuter d'une base de données distribuée CA en théorie, à toutes fins pratiques, une base de données distribuée CA peut exister mais ne devrait pas exister.

Par conséquent, cela ne signifie pas que vous ne pouvez pas avoir de base de données CA pour votre application distribuée si vous en avez besoin. De nombreuses bases de données relationnelles, telles que PostgreSQL, offrent cohérence et disponibilité et peuvent être déployées sur plusieurs nœuds à l'aide de la réplication.

Source: https://www.ibm.com/cloud/learn/cap-theorem