Théorème CAP

menu icon

Théorème CAP

Ce guide porte sur le théorème CAP et sa pertinence lors de la conception d'applications réparties et de la sélection d'un magasin de données NoSQL ou relationnel.

Qu'est-ce que le théorème CAP

Avez-vous déjà vu une publicité pour un paysagiste, un peintre en bâtiment ou un autre artisan qui commence par « Pas cher, rapide et bien : choisissez-en deux » ?

Le théorème CAP applique un type de logique similaire aux systèmes répartis, à savoir qu'un système réparti ne peut fournir que deux des trois caractéristiques souhaitées : consistency (cohérence), availability (disponibilité) et partition tolerance (tolérance au partitionnement) (c'est-à-dire « C », « D » et « P » dans CAP).

Un système réparti est un réseau qui stocke des données simultanément sur plusieurs nœuds (physiques ou de machines virtuelles). Comme toutes les applications cloud sont des systèmes répartis, il est essentiel de comprendre le théorème CAP lors de la conception d'une application cloud, afin de pouvoir choisir un système de gestion des données qui offre les caractéristiques dont votre application a le plus besoin.

Le théorème CAP s'appelle également théorème de Brewer, car il a été avancé pour la première fois par le professeur Eric A. Brewer lors d'un discours sur l'informatique en réseau prononcé en 2000. Deux ans plus tard, les professeurs Seth Gilbert et Nancy Lynch du MIT publient une preuve de « la conjecture de Brewer ».

Explication de « CAP » dans le théorème CAP

Examinons en détail les trois caractéristiques d'un système réparti auxquelles se réfère le théorème CAP.

Cohérence

La cohérence signifie que tous les clients voient les mêmes données en même temps, quel que soit le nœud auquel ils se connectent. Pour cela, chaque fois que des données sont écrites sur un nœud, elles doivent être instantanément transférées ou répliquées vers tous les autres nœuds du système pour que l'écriture soit considérée comme « réussie ».

Disponibilité

La disponibilité signifie qu'un client qui effectue une demande de données obtient une réponse, même si un ou plusieurs nœuds sont en panne. Autre façon de l'exprimer : tous les nœuds actifs du système réparti renvoient une réponse valide à toute demande, sans exception.

Tolérance au partitionnement

Un partitionnement est une rupture de communication au sein d'un système réparti, une perte ou un retard temporaire de connexion entre deux nœuds. La tolérance au partitionnement signifie que la grappe (cluster) doit continuer à fonctionner quel que soit le nombre d'interruptions entre les nœuds du système.

Théorème de CAP : Types de bases de données NoSQL

Les bases de données NoSQL (non relationnelles) sont idéales pour les applications réseau réparties. Contrairement à leurs homologues SQL (relationnelles) évolutives verticalement, les bases de données NoSQL sont évolutives horizontalement et réparties par nature : elles peuvent être mises à l'échelle rapidement dans un réseau en expansion composé de plusieurs nœuds interconnectés (voir « Bases de données SQL versus bases de données NoSQL : Quelle est la différence ? » pour plus d'informations).

Actuellement, les bases de données NoSQL sont classées en fonction des deux caractéristiques CAP qu'elles prennent en chargent :

  • Base de données CP : Une base de données CP assure la cohérence et la tolérance au partitionnement au détriment de la disponibilité. Lorsqu'un partitionnement se produit entre deux nœuds, le système doit arrêter le nœud incohérent (c'est-à-dire le rendre indisponible) jusqu'à ce que le partitionnement soit résolu.
  • Base de données AP : Une base de données AP assure la disponibilité et la tolérance au partitionnement au détriment de la cohérence. Lorsqu'un partitionnement se produit, tous les nœuds restent disponibles, mais ceux qui se trouvent à l'autre bout du partitionnement peuvent renvoyer une version plus ancienne des données que les autres. (Lorsque le partitionnement est résolu, 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 assure la cohérence et la disponibilité sur tous les nœuds. Cependant, elle ne peut pas le faire s'il existe un partitionnement entre deux nœuds du système, et elle ne peut donc pas assurer la tolérance au partitionnement.

Nous avons répertorié ce type en dernier pour une raison précise : dans un système réparti, les partitionnements sont inévitables. Ainsi, bien que nous puissions discuter d'une base de données répartie CA en théorie, dans la pratique une base de données répartie CA ne peut pas exister. Toutefois, cela ne signifie pas que vous ne pouvez pas disposer d'une base de données CA pour votre application répartie si vous en avez besoin. De nombreuses bases de données relationnelles, telles que PostgreSQL, assurent la cohérence et la disponibilité et peuvent être déployées sur plusieurs nœuds à l'aide de la réplication.

MongoDB et le théorème CAP (CP)

MongoDB est un système de gestion de base de données NoSQL très utilisé, qui stocke les données sous forme de documents BSON (binary JSON). Il est fréquemment utilisé pour les applications de big data et en temps réel qui s'exécutent dans plusieurs emplacements. Par rapport au théorème CAP, MongoDB est un magasin de données CP : il résout les partitionnements de réseau en maintenant la cohérence au détriment de la disponibilité.

MongoDB est un système à nœud principal unique : chaque jeu de répliques (lien externe à IBM) ne peut avoir qu'un seul nœud principal qui reçoit toutes les opérations d'écriture. Tous les autres nœuds d'un même jeu de répliques sont des nœuds secondaires qui répliquent le journal des opérations du nœud principal et l'appliquent à leur propre ensemble de données. Par défaut, les clients lisent également à partir du nœud principal, mais ils peuvent également spécifier une préférence de lecture (lien externe à IBM) qui leur permet de lire à partir des nœuds secondaires.

Lorsque le nœud principal devient indisponible, le nœud secondaire dont le journal des opérations est le plus récent est désigné comme nouveau nœud principal. Une fois que tous les autres nœuds secondaires sont alignés sur le nouveau nœud principal, la grappe redevient disponible. Comme les clients ne peuvent pas faire de demandes d'écriture pendant cet intervalle, les données restent cohérentes sur l'ensemble du réseau.

Cassandra et le théorème CAP (AP)

Apache Cassandra est une base de données NoSQL open source gérée par l'Apache Software Foundation. Il s'agit d'une base de données en colonnes larges qui permet de stocker des données sur un réseau réparti. Cependant, contrairement à MongoDB, Cassandra a une architecture sans nœud principal, et possède donc plusieurs points de défaillance au lieu d'un seul.

Par rapport au théorème CAP, Cassandra est une base de données AP : elle assure la disponibilité et la tolérance au partitionnement, mais ne peut pas garantir la cohérence en permanence. Cassandra n'ayant pas de nœud principal, tous les nœuds doivent être disponibles en permanence. Cependant, Cassandra fournit la cohérence à terme en permettant aux clients d'écrire sur n'importe quel nœud à tout moment et en remédiant aux incohérences aussi rapidement que possible.

Comme les données ne deviennent incohérentes que dans le cas d'un partitionnement du réseau et que les incohérences sont rapidement résolues, Cassandra offre une fonctionnalité de « réparation » (lien externe à IBM) pour permettre aux nœuds de s'aligner sur leurs pairs. Toutefois, la disponibilité constante se traduit par un système hautement performant qui peut valoir le compromis dans de nombreux cas de figure.

Utilisation des microservices

Les microservices sont des composants d'application déployables indépendamment et faiblement couplés, qui incorporent leur propre pile, y compris leur propre base de données et leur propre modèle de base de données, et communiquent entre eux sur un réseau. Comme vous pouvez exécuter les microservices sur des serveurs cloud et dans des centres de données sur site, ils connaissent un très grand succès pour les applications hybrides et multicloud.

La compréhension du théorème CAP peut vous aider à choisir la meilleure base de données lors de la conception d'une application basée sur les microservices et exécutée à partir de plusieurs emplacements. Si, par exemple, la capacité d'itérer rapidement le modèle de données et de mettre à l'échelle horizontalement est essentielle pour votre application et que vous pouvez tolérer la cohérence à terme (par opposition à la cohérence stricte), une base de données AP comme Cassandra ou Apache CouchDB peut répondre à vos besoins et simplifier votre déploiement. Par contre, si votre application dépend fortement de la cohérence des données, comme dans une application de commerce électronique ou un service de paiement, vous pourriez opter pour une base de données relationnelle comme PostgreSQL.

Théorème CAP et IBM Cloud

IBM propose tout un éventail de services de base de données entièrement gérés. Outre des systèmes de gestion de base de données relationnelle, vous pouvez également exécuter MongoDB, Cloudant (autre magasin de données réparti AP), Elasticsearch, etcd ainsi que d'autres solutions de base de données sur IBM Cloud.

Pour consulter l'ensemble de notre sélection de bases de données (sans aucun engagement), inscrivez-vous pour obtenir un IBMid et créez votre compte IBM Cloud.