309 votes

Théorème CAP - Disponibilité et tolérance des partitions

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

J'ai l'impression que A et P peuvent aller ensemble (je sais que ce n'est pas le cas, et c'est pour cela que je n'arrive pas à comprendre !)

Expliquez en termes simples ce que sont A et P et la différence entre eux.

1 votes

Voici un article qui explique la PAC en termes simples. ksat.me/a-plain-english-introduction-à-cap-theorem

3 votes

Ne vous laissez pas tenter par les réponses toutes faites. Lisez, visualisez et comprenez chaque C, A, P séparément. Concevez une architecture de cluster distribué (peut-être 3 DB) et appliquez maintenant votre compréhension. Voyez ce qui arrive à C, A, P quand les pannes des DB distribués se produisent. Une fois que vous avez compris, vérifiez les réponses et appliquez-les avec votre logique. Rappelez-vous - Même si vous comprenez, cela peut ne pas être clair. Donc, réfléchissez et appliquez votre compréhension. Merci

4 votes

D'une manière ou d'une autre, le lien ksat.me ci-dessus renvoie à une url 404 car il se termine par '/'. ksat.me/a-plain-english-introduction-à-cap-theorem Cela fonctionne bien et c'est une explication très détaillée de chacun des éléments 'C', 'A' et 'P'.

617voto

Chris Heald Points 28814

La cohérence signifie que les données sont les mêmes dans tout le cluster, de sorte que vous pouvez lire ou écrire à partir de/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 aux partitions signifie que le cluster continue de fonctionner même s'il y a une "partition" (rupture de communication) entre deux nœuds (les deux nœuds sont actifs, mais ne peuvent pas communiquer).

Pour obtenir à la fois la disponibilité et la tolérance de partition, il faut renoncer à la cohérence. Prenons le cas de deux nœuds, X et Y, dans une configuration maître-maître. Maintenant, il y a une rupture de communication réseau entre X et Y, ils ne peuvent donc pas synchroniser les mises à jour. À ce stade, vous pouvez soit

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

B) Considérer que le cluster est "down" (abandon de la disponibilité).

Toutes les combinaisons disponibles sont :

  • CA - 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 vous développez une partition entre les nœuds, les données seront désynchronisées (et ne seront pas resynchronisées une fois la partition résolue).
  • CP - les données sont cohérentes entre tous les nœuds, et maintient la tolérance de partition (empêchant la désynchronisation des données) en devenant indisponible 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 resynchronisent les données une fois la partition résolue, mais vous n'avez pas la garantie que tous les nœuds auront les mêmes données (que ce soit pendant ou après la partition).

Vous devez noter que Les systèmes d'AC n'existent pas dans la pratique (même si certains systèmes le prétendent).

1 votes

Dans AP, pourquoi n'avons-nous pas la garantie que tous les noeuds auront les mêmes données ? Ok, parce que nous n'avons pas de "C" mais... ce n'est pas clair pour moi... Je veux savoir pourquoi cela arrive...

8 votes

@grep Désolé pour la réponse tardive. Si vous avez à la fois la disponibilité (le cluster ne tombe pas en panne) et la tolérance de partition (la base de données peut survivre aux nœuds qui ne peuvent pas communiquer), alors vous ne pouvez pas garantir que tous les nœuds auront toujours toutes les données (cohérence), parce que les nœuds sont en place et acceptent les écritures, mais ne peuvent pas communiquer ces écritures les uns aux autres.

4 votes

J'arrive tard dans la soirée, mais cela vaut la peine de présenter quelques exemples dans chaque catégorie, par ex. blog.nahurst.com/visual-guide-to-nosql-systems

86voto

jayadev Points 982

Considérer P sur un pied d'égalité avec C et A est une erreur, et la notion de "2 sur 3" entre C, A et P est trompeuse. La façon succincte dont j'expliquerais le théorème du PAC est la suivante : "Dans un magasin de données distribuées, au moment de la partition du réseau, vous devez choisir entre la cohérence et la disponibilité et vous ne pouvez pas obtenir les deux". Les nouveaux systèmes NoSQL essaient de se concentrer sur la disponibilité, alors que les bases de données ACID traditionnelles se concentrent davantage sur la cohérence.

Vous ne pouvez vraiment pas choisir l'AC, la partition du réseau n'est pas quelque chose que l'on souhaite 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. Voici article de l'homme qui a été le premier à formuler ce terme semble l'expliquer très clairement.

0 votes

C'est ce que je comprends aussi du théorème CAP. Sur la partition du réseau, vous pouvez choisir entre la cohérence et la disponibilité.

0 votes

D'accord, les bases de données SQL traditionnelles sont des CA, mais elles n'ont pas de partitionnement, seulement un basculement pour HA. Un système sans P peut-il même être considéré comme distribué ?

23voto

Brian Bulkowski Points 187

Voici comment je discute de la PAC, en ce qui concerne P en particulier.

CA n'est possible que si vous êtes d'accord avec une base de données monolithique, à un seul serveur (peut-être avec une réplication, mais toutes les données sont sur un seul "bloc de défaillance" - les serveurs ne sont pas considérés comme pouvant tomber partiellement en panne).

Si votre problème nécessite une mise à l'échelle, une distribution et des serveurs multiples --- des partitions de réseau peuvent se produire. Vous avez déjà besoin de P. Peu de problèmes que j'aborde se prêtent à des paradigmes à serveur unique et permanent (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 échelle offrent beaucoup d'avantages.

Pour moi, c'est rare : nous passons donc à la discussion sur l'AP et le CP.

Vous ne pouvez choisir entre le fonctionnement AP et CP que lorsque vous avez une partition. Si le réseau et le matériel fonctionnent correctement, vous avez le beurre et l'argent du beurre.

Discutons de la distinction AP / CP.

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

CP - lorsqu'il y a une partition du réseau, arrêter les nœuds ou interdire les lectures et les écritures afin d'obtenir des défaillances déterministes.

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

Par exemple, dans un ensemble de données AP, vous avez la possibilité d'effectuer des lectures incohérentes et de générer des conflits d'écriture - ce sont deux modes AP différents. Votre système peut-il être configuré pour le mode AP avec une haute disponibilité en lecture, mais en interdisant les conflits d'écriture ? Ou votre système AP peut-il accepter les conflits d'écriture, avec un système de résolution fort 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 de PC, quel degré d'indisponibilité obtenez-vous avec de petites partitions (un seul serveur), le cas échéant ? Une réplication plus importante peut augmenter l'indisponibilité dans un système CP, comment le système gère-t-il ces compromis ?

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

L'article de Brewer intitulé "12 ans plus tard" est une excellente lecture dans ce domaine. Je pense qu'il 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

2 votes

Le système CA est effectivement déroutant, j'ai une question concernant votre exemple CA d'une base de données monolithique. S'il ne s'agit que d'un seul serveur, d'où vient le "A", puisqu'il me semble que la défaillance dudit serveur aura pour conséquence qu'aucun service ne sera disponible ?

1 votes

Bonne question. Les serveurs peuvent avoir un disque défaillant, ou même des modules DIMM défaillants, ou des alimentations défaillantes s'ils sont conçus pour la haute disponibilité. Imaginez même être sur plusieurs réseaux électriques. Vous obtenez une disponibilité de plus en plus élevée, mais il n'y a jamais de "réseau" à l'intérieur qui ait la capacité de partitionner et de fonctionner avec des composants en désaccord. Bien qu'il existe du matériel plus ésotérique (consultez SQL NON-STOP), les exemples de matrices RAID avec des composants défaillants et reprenant leur activité sont encore courants de nos jours et offrent une très haute disponibilité dans un seul serveur.

0 votes

Hm, ma lecture de votre réponse @BrianBulkowski est que le "A" dit "il sera toujours disponible même s'il y a une partition du réseau", pas "il sera toujours disponible si le nœud tombe". Est-ce exact ?

2voto

Yoh0xFF Points 167

Je pense que ce guide visuel, démontre clairement un théorème de CAP NoSQL

http://blog.nahurst.com/visual-guide-to-nosql-systems

0voto

zafar142003 Points 30

Le théorème a été très bien expliqué dans une conférence de M. Martin Fowler ici ( http://www.youtube.com/watch?v=qI_g07C_Q5I ) à 40:14.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X