Théorème CAP

Le théorème CAP ou CDP, aussi connu sous le nom de théorème de Brewer, dit qu'il est impossible sur un système informatique de calcul distribué de garantir en même temps (c'est-à-dire de manière synchrone) les trois contraintes suivantes[1],[2] :

  • Cohérence (Consistency en anglais) : tous les nœuds du système voient exactement les mêmes données au même moment ;
  • Disponibilité (Availability en anglais) : garantie que toutes les requêtes reçoivent une réponse;
  • Tolérance au partitionnement (Partition Tolerance en anglais) : aucune panne moins importante qu'une coupure totale du réseau ne doit empêcher le système de répondre correctement (ou encore : en cas de morcellement en sous-réseaux, chacun doit pouvoir fonctionner de manière autonome).

Pour les articles homonymes, voir CAP.

Représentation des contraintes du théorème CAP.

Attention : dans cette définition, le terme « partitionnement » ne doit pas être compris au sens que, dans une base, un objet peut être scindé en plusieurs destinations de stockage, mais comme des machines distinctes (appelées généralement nœuds) possédant chacune une partie des données tel que, seul, l’ensemble des nœuds permet de reconstituer l’intégralité des données de la base.

D'après ce théorème, un système de calcul/stockage distribué ne peut garantir à un instant t que deux de ces contraintes mais pas les trois[3].

Historique

Le théorème part d'une conjecture énoncée par le chercheur en informatique Eric Brewer de l'université de Californie à Berkeley lors du Symposium on Principles of Distributed Computing (PODC, « Symposium sur les principes d'informatique distribuée »)[4],[1]. En 2002, Seth Gilbert et Nancy Lynch du MIT publient une preuve formelle de la vérifiabilité de la conjecture de Brewer, et en font un théorème établi[1].

Illustrations
  1. Soit A et B deux utilisateurs du système, soit N1 et N2 deux nœuds du système. Si A modifie une valeur sur N1, alors pour que B voit cette valeur sur N2 il faut attendre que N1 et N2 soient synchronisés. Si N1 et N2 doivent toujours servir des valeurs cohérentes, alors il y a un temps incompressible entre le début de l'écriture, la synchronisation et la lecture suivante. Sur un système très chargé et très vaste, ce temps incompressible va considérablement influencer la disponibilité et la résistance au morcellement. Il existe bien évidemment des techniques pour optimiser ce temps mais plus le système est vaste, plus il est difficile à réduire.
  2. Exemple d'arbitrage qu'implique le théorème CAP : deux utilisateurs qui font une même recherche sur un même moteur de recherche peuvent obtenir des résultats différents, mais on peut considérer que cet inconvénient est moins grave que de ne pas avoir de résultats du tout [5].

Références
  1. (en) [PDF] Lynch, Nancy, et Seth Gilbert : « Brewer's conjecture and the feasibility of consistent, available, partition-tolerant web services. » in ACM SIGACT News, v. 33 N°2, 2002, p. 51-59.
  2. (en) julianbrowne.com : Brewer's CAP Theorem. Consulté le 2 mars 2010.
  3. (en) royans.net : Brewers CAP theorem on distributed systems.
  4. (en) Eric Brewer, « Towards Robust Distributed Systems », sur Université Berkeley.
  5. http://davidmasclet.gisgraphy.com/post/2010/06/09/10-minutes-pour-comprendre...NoSQL

Liens externes
  • Portail de l'informatique théorique
Cet article est issu de Wikipedia. Le texte est sous licence Creative Commons - Attribution - Partage dans les Mêmes. Des conditions supplémentaires peuvent s'appliquer aux fichiers multimédias.