Vous souvenez-vous d’avoir déjà vu une publicité pour un paysagiste, un peintre en bâtiment ou un autre artisan commençant par le titre suivant : « Pas cher, rapide et de bonne qualité : sélectionnez deux critères au choix »?
Le théorème CAP applique une logique similaire aux systèmes distribués, à savoir qu’un système distribué ne peut fournir que deux des trois caractéristiques souhaitées : cohérence, disponibilité (availability)et tolérance au partitionnement (en anglais, le « C », le « A » et le « P » de CAP).
Un système distribué est un réseau qui stocke les données sur plusieurs nœuds (machines virtuelles ou physiques) en même temps. Comme toutes les applications en cloud sont des systèmes distribués, il est essentiel de comprendre le théorème CAP lors de la conception d’une application en cloud afin de pouvoir choisir un système de gestion des données fournissant les caractéristiques dont votre application a le plus besoin.
Le théorème CAP est également appelé théorème de Brewer, car il a été énoncé pour la première fois par le professeur Eric A. Brewer lors d’une conférence sur l’informatique en réseau en 2000. Deux ans plus tard, les professeurs Seth Gilbert et Nancy Lynch du MIT ont publié une preuve de la « conjecture de Brewer ».
Cloudant
DataStax
IBM Cloud Databases for MongoDB
Examinons en détail les trois caractéristiques d'un système distribué 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 que cela se produise, chaque fois que des données sont écrites sur un nœud, elles doivent être instantanément transmises ou répliquées vers tous les autre nœuds du système avant que l'écriture soit considérée comme « réussie ».
Disponibilité
La disponibilité signifie qu'un client qui effectue une requête de données obtient une réponse, même si un ou plusieurs nœuds sont en panne. Voici une autre façon d'exprimer ce concept : tous les nœuds actifs du système distribué renvoient une réponse valide à toutes les requêtes, sans faire d'exception.
Tolérance au partitionnement
Un partitionnement est une rupture de communication au sein d'un système distribué, 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.
Les bases de données NoSQL sont idéales pour les applications en réseau réparti. Contrairement à leurs homologues SQL (relationnelles) qui sont évolutives verticalement, les bases de données NoSQL sont réparties et évolutives horizontalement par nature : elles peuvent être rapidement mises à l’échelle dans un réseau en expansion et composé de nœuds multiples et interconnectés. (Voir « Bases de données SQL et NoSQL : quelle est la différence ?» pour plus d’informations.)
Actuellement, les bases de données NoSQL sont classifiées selon les deux caractéristiques CAP qu’elles prennent en charge :
- Base de données CP : une base de données CP fournit cohérence et tolérance au partitionnement au détriment de la disponibilité. Lorsque survient un partitionnement entre deux nœuds, le système doit arrêter le nœud non cohérent (c’est-à-dire le rendre indisponible) jusqu’à la résolution du partitionnement.
- Base de données AP: une base de données AP fournit disponibilité et tolérance au partitionnement au détriment de la cohérence. Lorsque survient un partitionnement, tous les nœuds restent disponibles, mais ceux situés du mauvais côté du partitionnement risquent de renvoyer une version des données plus ancienne que les autres. (Lorsque le partitionnement est résolu, les bases de données AP lancent une nouvelle synchronisation des nœuds pour réparer toutes les incohérences dans le système.)
- Base de données CA : une base de données CA fournit cohérence et disponibilité sur tous les nœuds. Cependant, cela n’est plus possible si un partitionnement se produit entre deux nœuds du système : elle ne fournit donc pas de tolérance aux pannes.
Les bases de données de type CA sont mentionnées en dernier pour une raison précise : dans un système distribué, les partitionnements sont inévitables. Ainsi, bien que l’on puisse discuter théoriquement des bases de données réparties CA, elles ne peuvent pas exister dans la pratique. 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, fournissent cohérence et disponibilité, et peuvent être déployées sur plusieurs nœuds grâce à la réplication.
MongoDB est un système de gestion de base de données NoSQL répandu qui stocke les données sous forme de documents BSON (JSON binaire). Il est fréquemment utilisé pour les applications de big data et en temps réel qui s’exécutent dans plusieurs emplacements différents. 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 maître unique : chaque jeu de répliques (lien externe à ibm.com) ne peut comporter qu’un seul nœud principal recevant toutes les opérations d’écriture. Tous les autres nœuds de ce jeu sont des nœuds secondaires qui répliquent le journal des opérations du nœud principal et l’appliquent à leur propre jeu de données. Par défaut, les clients aussi lisent les données à partir du nœud principal, mais ils peuvent également spécifier une préférence de lecture (lien externe à ibm.com) leur permettant de lire les données à partir des nœuds secondaires.
Lorsque le nœud principal est rendu indisponible, le nœud secondaire dont le journal des opérations est le plus récent devient le nouveau nœud principal. Une fois que tous les autres nœuds secondaires sont alignés sur le nouveau maître, la grappe redevient disponible. Comme les clients ne peuvent effectuer aucune requête d’écriture pendant cet intervalle, les données restent cohérentes sur l’ensemble du réseau.
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 dispose d'une architecture sans maître, et comporte 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 une 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 fonction de « réparation » pour permettre aux nœuds de s'aligner sur leurs pairs. Toutefois, la disponibilité constante se traduit par un système hautement performant qui justifie le compromis dans de nombreux cas de figure.
Les microservices sont des composants d’application liés de façon souple et pouvant être déployés de manière indépendante. Ils intègrent 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 ils peuvent s’exécuter aussi bien sur des serveurs Cloud que dans des centres de données sur site, ils connaissent un grand succès avec les applications hybrides et multicloud.
Comprendre le théorème CAP peut vous aider à choisir la meilleure base de données lors de la conception d’une application basée sur des microservices et exécutée à partir de plusieurs emplacements. Si, par exemple, la capacité à itérer rapidement le modèle de données et à mettre à l’échelle horizontalement est essentielle pour votre application et que vous pouvez tolérer la cohérence finale (par opposition à la cohérence stricte), une base de données AP comme Cassandra ou Apache CouchDB peut répondre à vos besoins et vous simplifier le déploiement. Par contre, si votre application dépend fortement de la cohérence des données, comme c’est le cas pour une application de commerce électronique ou un service de paiement, vous pourriez préférer une base de données relationnelle comme PostgreSQL.
IBM offre tout un spectre de services de base de données entièrement gérés. En fonction du IBM Cloud vous pouvez exécutez des systèmes de gestion de bases de données relationnelles, ainsi que
- Cloudant, un magasin de données distribuées AP
- DataStax Entreprise, une base de données basée sur Cassandra et conçue pour le cloud hybride
- MongoDB, Elasticsearch, etcd, et d'autres solutions de base de données.
Pour une recherche dans l'ensemble de notre sélection de base de données, créez un IBMid et votre compte IBM Cloud.
Explorez la gamme de bases de données cloud proposée par IBM, qui prend en charge divers cas d'utilisation : charges de travail critiques, applications mobiles et Web, analyse.
IBM Cloudant est une base de données Cloud évolutive et distribuée Apache CouchDB utilisée pour les applications Web, mobiles, IoT et sans serveur.
Obtenez cette base de données cloud native évolutive et hautement disponible NoSQL construite sur Apache Cassandra d'IBM, votre source unique d'achat, de déploiement et de support.
MongoDB sous forme de service, conçu pour répondre aux attentes des entreprises avec une intégration native à IBM Cloud.
En savoir plus à propos de Databases for Elasticsearch, un outil puissant pour les données enrichies avec un moteur de recherche documentaire et une fonction d'indexation des bases de données documentaires JSON.
Découvrez-en plus sur IBM Cloud Databases for etcd qui offre un magasin de valeurs de clés adapté aux entreprises et entièrement géré pour contenir les données permettant de gérer votre cluster de serveurs.