Comprendre le théorème CAP en 2 minutes

Choisir sa base de données est toujours un long chemin semé d’avantages, d’inconvénients et de concessions… mais lorsque l’on doit partir sur une base de donnée distribuée, le challenge est encore plus grand !

Si le concept de base de données distribuée ne vous est pas familier, découvrez notre article sur la fragmentation en base de données

Pour simplifier, des données distribuées (ou fragmentées) sont réparties sur plusieurs nœuds (serveurs), qui peuvent être eux-mêmes réparties dans plusieurs datacenters, dans plusieurs pays !

Les trois propriétés stratégiques

Il est important de savoir que le fait que vos données soient réparties sur plusieurs machines ajoute quelques contraintes supplémentaires.

Dans l’idéal, quel que soit le nombre de serveurs, on aimerait que toute les requêtes fournissent un résultat correct.

Dans cette phrase, on retrouve trois concepts importants : La cohérence, la disponibilité des données et la tolérance à la partition.

Consistency (Cohérence)

Une donnée cohérence est une donnée qui n’a qu’un seul état visible, et valide.

Et ce, quel que soit le nombre de machine qui en possède une copie, ou la fréquence à laquelle cette donnée est mise à jour.

Par exemple, lorsque vous effectuez une opération de retrait d'argent dans un guichet automatique, le solde affiché doit être exact et à jour. Même si plusieurs guichets automatiques sont en service, ils doivent tous afficher le même solde après une transaction réussie pour maintenir la cohérence des données financières.

Availability (Disponibilité)

Les données doivent être disponibles, accessibles, en lecture.

Ca signifie que chaque requête obtiendra forcément une réponse, peut importe l’état du système.

Par exemple, les sites de médias sociaux comme Twitter (X) doivent être disponibles en permanence pour permettre aux utilisateurs de publier des tweets, même en cas de panne partielle du système. Même si certains tweets peuvent prendre un certain temps pour se propager à tous les serveurs, les utilisateurs doivent toujours pouvoir accéder au service et interagir avec leurs tweets et ceux des autres.

Partition tolerance (Tolérance à la partition)

On parle également parfois simplement de “partitionnement”, mais ce terme est trop souvent confondu avec la “fragmentation”, qui est le principe même de donnée distribuée.

Une partition, c’est lorsque l’une des machines qui contient une partie de vos données, ne répond plus. Cela peut être dû :

• À un problème matériel
• À un problème logiciel
• À une coupure de réseau

La tolérance à la partition signifie que le système doit continuer à répondre, même si une partie de vos données est manquante (ou inaccessible), même temporairement !

Par exemple, si un centre de données est déconnecté du reste du réseau en raison d'une panne de connexion, les autres centres de données doivent être en mesure de continuer à fonctionner et à servir les demandes des utilisateurs sans interruption.

Le théorème CAP (ou Brewer)

Le théorème CAP stipule qu'une base de données distribuée ne peut garantir simultanément que 2 propriétés sur 3 maximum. Soit :

• Cohérence + Disponibilité (CA)
• Cohérence + Partition (CP)
• Disponibilité + Partition (AP)

On représente souvent ce théorème sous la forme d’un triangle, comme celui-ci :

Et vous ne pouvez choisir qu’un seul côté à la fois !

Le paradigme CA

En choisissant ce paradigme, vos requêtes recevront toujours une réponse complète et cohérente, sauf si un nœud est rendu indisponible (partition).

Dans le cas d’une partition, votre système arrêtera de répondre.

Le paradigme CP

En tolérant la faute, et en assurant la cohérence des données, on se prive de la disponibilité.

Les données seront toujours fiables, mais si les données fiables sont inaccessible, alors la requête ne retournera pas de résultat.

Le paradigme AP

En tolérant la faute, et en assurant la disponibilité, on se prive de la cohérence.

La requête retournera un toujours résultat, mais les données pourront être périmées ou désynchronisées.

Les bases de données

Ce théorème est un guide indispensable pour prendre des décisions quand vous devez distribuer vos données, et fonction des contraintes du projet.

Alors voici une liste des base de données majeures et leurs implémentation du théorème CAP :

Relationnel

MySQL (CA), SQLServer (CA), PostgresQL (CA), Oracle (CA), DB2 (CA)

Clé-Valeur

Redis (AP), Memcached (AP ou CP), SimpleDB (AP ou CP), SimpleDB (AP ou CP), CosmosDB (CP ou AP)

Colonne

ElasticSearch (AP), Spark (AP), HBase (CP), BigTable (CP)

Document

MongoDB (CP ou AP), DynamoDB (AP ou CP), Couchbase (AP ou CP), Cassandra (AP ou CP)

Graph

Neo4J (AP), OrientDB (AP), FlockDB (AP)

Bien sûr, le choix d'une base de données dépend également d'autres facteurs tels que les compétences disponibles, le temps, les ressources, la communauté…