Salut et bienvenue dans ce nouvel épisode du podcast de Code Garage, je m'appelle Nicolas
Brandin-Bernard et aujourd'hui on va parler du théorème CAP.
Alors le théorème CAP, je ne sais pas, ça ne vous parle pas forcément puisque c'est
quand même un domaine assez spécifique lié au base de données et encore plus précisément
aux bases de données distribuées.
C'est un théorème qu'on appelle également le théorème de Brewer, d'après le nom de
son auteur et donc c'est quelque chose qui est vraiment très important quand on va
travailler sur des bases de données distribuées.
Alors si jamais le concept justement de bases de données distribuées vous n'est pas trop
familier, je vous invite à écouter un précédent épisode du podcast de mémoire, c'était
l'épisode 32 dans lequel justement on aborde ces bases de données distribuées pour qu'on
comprennie un petit peu mieux de quoi on parle.
Donc évidemment dans n'importe quel projet choisir sa base de données c'est toujours
un long chemin, se met davantage d'inconvénients, de concessions etc.
Mais en fait justement quand on va partir dans le monde du distribuer, le challenge
il est encore plus grand.
Donc si jamais petit récapitulatif, une base de données distribuées contient des données
distribuées ou fragmentées et sont réparties sur plusieurs nœuds, plusieurs serveurs
distincts et souvent ces nœuds peuvent être répartis dans plusieurs datacenters, dans
plusieurs pays.
Voilà, on le fait par soucis de performance en général, quand c'est plus facile de
scaler plusieurs serveurs en nombre plutôt que d'avoir des très gros serveurs qui
vont coûter extrêmement cher et si jamais il y a un problème avec un de ces serveurs
c'est toutes vos données qui tombent.
Là on va distribuer nos données sur les serveurs.
Il y a plusieurs manières de distribuer, il y a de la fragmentation où on va fragmenter
le contenu d'une table sur plusieurs bases de données ou alors on va séparer une table
et les mettre sur différentes bases de données.
Là on ne va pas rentrer plus que ça dans le détail mais c'est pour comprendre un petit
peu juste la suite.
Alors il y a vraiment trois propriétés stratégiques quand on parle justement de
distribution parce que quand on va répartir nos données sur plusieurs machines ça va
ajouter quelques contraintes.
Dans l'idéal, quel que soit le nombre de serveurs qu'on a, on aimerait que toutes
les requêtes fournissent un résultat correct et en fait dans cette phrase on retrouve trois
concepts importants qui sont la cohérence, la disponibilité des données et la tolérance
à la partition.
Et là on va voir ces trois propriétés.
La première c'est la cohérence des données, on en anglais on parle de consistency.
Une donnée cohérente c'est une donnée qui n'a qu'un seul état visible et valide
et ce quel que soit le nombre de machines qui possèdent une copie de cette donnée
ou la fréquence à laquelle cette donnée est mis à jour.
Par exemple quand vous effectuez une opération de retrait d'argent sur un guichet automatique
et un distributeur de billets, le solde affiché doit être exact et à jour même si plusieurs
guichets automatiques sont en service au même moment et potentiellement qui regardent le
même compte, ils doivent tous afficher le même solde après une transaction réussie
pour maintenir justement cette cohérence de données financière.
La deuxième propriété c'est la disponibilité, on va parler de availability en anglais.
Les données elles doivent être donc disponibles, accessibles en lecture.
Ça veut dire que chaque requête obtiendra forcément une réponse peu importe l'état
du système. Par exemple pour des réseaux sociaux comme Twitter maintenant X, les données
et les tweets doivent être disponibles en permanence pour permettre aux utilisateurs
de publier des tweets et même en cas de panne partielle du système, il faut quand même pouvoir
continuer les gens à laisser utiliser la plateforme. Même si certains tweets peuvent
prendre un peu plus de temps que d'autres pour se propager à tous les serveurs etc,
les utilisateurs doivent toujours pouvoir accéder au service et interagir avec leurs tweets et ce
des autres parce qu'il y a un vrai besoin business. Ensuite on a la tolérance à la
partition, on parle aussi parfois de partitionnement mais le term' il est trop souvent confondu avec
la fragmentation dont on a parlé un petit peu au début qui est différent et qui est le principe
même d'avoir des données distribuées, le sharding, la fragmentation. Là on parle de
justement tolérance à la partition. Une partition c'est quand une machine qui contient
une partie de vos données ne répond plus, ça peut être dû à un problème matériel,
ça peut être dû à un problème logiciel, ça peut être dû à une coupure de réseau etc.
La tolérance à la partition, ça signifie simplement que le système doit continuer
à répondre même si une partie de vos données est manquante ou inaccessible même si c'est
temporaire. Par exemple si un centre de données data center est déconnecté du reste du réseau
parce qu'il y a une panne de connexion, les autres data centers doivent être en mesure de
continuer à fonctionner et à servir les demandes des utilisateurs et sans interruption.
Maintenant on va attaquer justement notre théorème CAP ou théorème de brewer et ce
théorème stipule qu'une base de données distribuée elle ne peut garantir simultanément que 2
propriétés sur 3 maximum parmi les propriétés qu'on a vu. Donc en fait on a 3 possibilités,
c'est soit la cohérence et la disponibilité, donc c'est consistency availability donc on parle
de CA, on a cohérence et partition, CP et disponibilité et partition c'est AP pour
availability toujours. On représente souvent ce théorème sous la forme d'un triangle, vous
aurez si jamais vous voulez voir le schéma si ça peut vous aider à y comprendre, enfin comprendre
ce théorème plus facilement dans les liens, dans les notes de l'épisode je vous mettrai le lien
vers l'article et dans l'article évidemment je vous ai fait un beau schéma pour bien comprendre.
Et donc quand vous regardez ce triangle qui est à chaque côté il y a CA et P et en fait on peut
choisir, enfin les trois sommets plutôt CAP et on peut choisir qu'un seul côté du triangle à
chaque fois le côté CA, le côté AP ou le côté CP. Maintenant on va revenir un petit peu justement
sur chacun de ces paradigmes, ce que ça apporte et aussi les inconvénients. Le paradigme CA par exemple
consistance et disponibilité, eh bien quand on choisit ce paradigme les requêtes recevront
toujours une réponse complète et cohérente sauf si un des notes est rendu indispensable. Dans le
cas d'une partition, eh bien votre système il va s'arrêter carrément de répondre. Alors
typiquement quand est-ce qu'on veut ça potentiellement eh bien peut-être dans des données bancaires
comme on le disait tout à l'heure j'ai pas envie qu'il y ait un environnement qui passe et qui soit
validé alors qu'en fait il y a une donnée sur une autre partition qui ne répondent plus. Donc
potentiellement on va vraiment avoir besoin de la consistance, enfin la cohérence pardon, et donc
on va choisir ce paradigme. Ensuite on a le paradigme CP, là en tolérant la faute, la tolérance
de partition, et en assurant la cohérence des données, eh bien on se prive de la disponibilité. Les
données est-ce qu'on est toujours fiable mais si les données fiables elles sont inaccessibles,
alors eh bien la requête ne retournera pas de résultats. Et ensuite on a le paradigme AP,
là en tolérant la faute eh bien et en assurant évidemment la disponibilité, on se prive de la
cohérence. Ça veut dire que la requête elle retournera toujours un résultat mais les données
pourront elles être périmées ou désynchronisées. Alors du coup là maintenant qu'on a vu ça et
on a compris que chaque base de données ne peut assurer que deux à chaque fois de ses propriétés,
eh bien on peut faire une petite liste des bases de données et leur implementation
justement du théorème CAP. On va le faire très rapidement, je ne vais pas tout vous faire,
mais on va faire au moins les bases de données relationnelles. Dans le relationnel eh bien en
fait quasiment toutes les bases de données majeures, c'est-à-dire MySQL, SQL Server,
Postgre, Oracle, etc. Eh bien N où donne le paradigme CA donc cohérence et disponibilité.
Pour les clés valeurs, on a par exemple Redis qui lui va être sur de AP donc c'est
disponibilité et partitionnement. Pareil pour Memcache mais Memcache qui propose et c'est le cas
du coup pour certaines bases de données qui proposent deux paradigmes au choix. Ça peut être soit le
paradigme AP soit le paradigme CP. Donc là c'est souvent à la configuration de votre base de données
ou de votre cluster en tout cas que vous allez choisir. Ensuite voilà on a par exemple l'Elestic
Search. L'Elestic Search lui ça va être un paradigme AP donc disponibilité, partitionnement.
MongoDB on peut le choisir aussi en document c'est soit CP soit AP. Pareil pour DynamoDB c'est soit AP
soit CP. Voilà on va pas faire comme je vous ai dit toutes les bases de données mais simplement c'est
important de savoir être sur enseigné quand vous faites de la base de données distribuée sur
quelle base de données vous voulez choisir pour votre projet puisque comme je vous ai dit tous les
paradigmes ne sont pas disponibles et qu'il y aura forcément on va dire une contrainte. Il y aura une
propriété qu'on ne pourra pas assurer. J'espère que cet épisode vous aura plu. Je suis désolé je le
tourne je suis encore un petit peu malade j'espère que ça ne s'entend pas trop donc j'ai essayé de vous
apporter quand même le meilleur épisode possible avec l'énergie disponible que j'ai. Moi je vous donne
rendez-vous la semaine prochaine pour un prochain épisode évidemment mais surtout n'hésitez pas à
venir faire un tour sur code-garrache.fr il y a énormément de choses qui arrivent dont des
nouveaux cours des nouveaux cours gratuits des nouveaux cours premium qui arrivent très très très
prochainement. Donc venez faire un tour la communauté grandit de plus en plus la plateforme est de
plus en plus active même les discussions commencent vraiment à avoir quelques quelques pages de
discussions pour les juniors pour lier au cours aussi si vous les discutez des cours ou à prendre
des choses en dehors des cours juste en discutant avec des gens bah c'est possible aussi. Donc vraiment
venez y faire un tour on vous accueillera très très bien à la semaine prochaine prenez soin de vous salut