II.2. CONCEPTS DE BASE
II.2.1. Théorème du CAP (d'Eric Brewer)
Actuellement, il sied de savoir que le mouvement des bases de
données NoSQL contient plusieurs approches qui ont une architecture qui
leur est propre et qui traitent des cas d'utilisation bien définis. Il
convient donc de choisir l'outil qui répond le mieux au problème
posé, à la fois en termes de modélisation mais aussi de
répartition des données.
Le théorème énonce donc qu'il est
impossible pour un système distribué de fournir
les trois propriétés suivantes à la fois :
· Consistency: Tous les noeuds du
système voient les mêmesdonnées au
même moment quelques soient les modifications ;
· Availability: Les requêtes
d'écriture et de lecture sont toujours satisfaites, donc il y a
disponibilité pour la lecture et l'écriture ;
· Partition tolerance: La seule raison
qui pousse un système à l'arrêt est la coupure totale du
réseau. Autrement dit si une partie du réseau n'est pas
opérationnelle, cela n'empêche pas le système de
répondre. Le système tolère même
une partie du réseau.
Afin de créer une architecture distribuée on doit
donc se résoudre à choisir deux de ces propriétés,
laissant ainsi trois conceptions possibles :
· CP : Les données sont
consistantes entre tous les noeuds et le système possède une
tolérance aux pannes, mais il peut aussi subir des problèmes de
latence ou plus généralement, de disponibilité ;
· AP : Le système répond
de façon performante en plus d'être tolérant aux pannes.
Cependant rien ne garantit la consistance des données entre les
noeuds ;
· CA : Les données sont
consistantes entre tous les noeuds (tant que les noeuds sont onlines). Toutes
les lectures/écritures des noeuds concernent les mêmes
données. Mais si un problème de réseau apparait, certains
noeuds seront désynchronisés au niveau des données (et
perdront donc la consistance).
Le design CA n'est pas vraiment une option cohérente
car un système qui n'est pas tolérant aux pannes (partition du
réseau) sera, par définition, obligé d'abandonner la
consistance ou la disponibilité lors d'un problème de partition.
C'est pourquoi il existe une version plus moderne du théorème :
« Durant un problème de partition, il faut choisir
entre la disponibilité et la consistance.».
II.2.2. Principes ACID et BASE
Hormis le théorème CAP ci-haut
énoncé, nous pouvons aussi parler de deux principes qui sont
alors liés à la répartition des données et qui sont
à la base des architectures actuelles des systèmes de gestion de
bases de données, notamment les systèmes du type NoSQL.
ACID et BASE représentent deux principes de conception
aux extrémités opposées du spectre
cohérence-disponibilité. Les propriétés ACID se
concentrent sur la cohérence et sont l'approche traditionnelle des bases
de données. Le principe BASE était créé à
la fin des années 90 pour saisir les concepts émergents de la
haute disponibilité et rendre explicite à la fois le choix et le
spectre. Les systèmes étendus modernes et à grande
échelle, y compris le Cloud, utilisent une combinaison des deux
approches.
Bien que les deux acronymes soient plus mnémoniques que
précis, l'acronyme BASE (étant le second apparu) est un peu plus
délicat : Basically Available, Soft state, Eventually consistent
(Simplement disponible, état souple, finalement consistant). Soft state
et Eventual consistency sont des techniques qui fonctionnent bien en
présence de partitions réseau et donc améliorent la
disponibilité.
La relation entre CAP et ACID est plus complexe et souvent
incomprise, en partie parce que les C et A d'ACID représentent des
concepts différents des mêmes lettres dans CAP et en partie parce
que choisir la disponibilité affecte seulement certaines des garanties
ACID. Les quatre propriétés ACID sont :
· Atomicity : Tout système
bénéficie d'opérations atomiques. Quand l'objectif est la
disponibilité, toutes les parties de la partition doivent toujours
utiliser des opérations atomiques. De plus, des opérations
atomiques de plus haut niveau (celles qu'impliquent ACID) simplifient la
restauration ;
· Coherence: Dans ACID, le C signifie
qu'une transaction préserve toutes les règles des bases de
données, telles que les clés uniques. En comparaison, le C de CAP
ne se réfère qu'à une cohérence de copie unique, un
sous-ensemble strict de la cohérence ACID. Plus
généralement, maintenir des invariants durant les partitions peut
être impossible, d'où le besoin de bien choisir quelles
opérations interdire et comment ensuite restaurer les
invariants ;
· Isolation : L'isolation est au
coeur du théorème CAP : si un système nécessite
l'isolation ACID, il peut opérer sur au plus une partie durant une
partition réseau. La possibilité de sérialiser les
transactions nécessite des communications en général et
échoue durant les séparations réseau. Des
définitions plus faibles de l'exactitude sont viables durant les
partitions en compensant durant la phase de restauration ;
· Durability : Comme pour
l'atomicité, il n'y a pas de raison d'abandonner la durabilité,
bien que le développeur puisse choisir d'éviter d'en avoir besoin
grâce à un état flexible (dans le style de BASE) à
cause de son coût. Une subtilité est que durant la restauration il
est possible d'inverser les opérations durables qui violent un invariant
pendant l'opération. Néanmoins, au moment de la restauration,
avec un historique durable de toutes les parties de la partition, de telles
opérations peuvent être détectées et
corrigées. En général, effectuer des transactions ACID
dans chaque partie de la partition rend la restauration plus simple et fourni
un cadre pour compenser les transactions qui peut être utilisé
pour récupérer d'une partition.
Il est à noter que le principe BASE abandonne donc la
consistance au profit de ces nouvelles propriétés :
· Basically available : Le
système garantie bien la disponibilité dans le même sens
que celle du théorème de CAP ;
· Soft-State : Indique que l'état
du système peut changer à mesure que le temps passe, et c'est
sans action utilisateur. C'est dû à la propriété
suivante ;
· Eventually consistent :
Spécifie que le système sera consistent à mesure
que le temps passe, à condition qu'il ne reçoive pas une action
utilisateur entre temps.
NOTA :
ACID est nécessaire si :
· Beaucoup d'utilisateurs ou processus qui travaillent
sur une même donnée au même moment ;
· L'ordre des transactions est très
important ;
· L'affichage de données dépassées
n'est pas une option ;
· Il y a un impact significatif lorsqu'une transaction
n'aboutit pas (dans des systèmes financiers en temps réel par
exemple).
BASE est possible si :
· Les utilisateurs ou processus ont surtout tendances
à faire des mises à jour ou travailler sur leurs propres
données ;
· L'ordre des transactions n'est pas un
problème;
· L'utilisateur sera sur le même écran
pendant un moment et regardera de toute façon des données
dépassées ;
· Aucun impact grave lors de l'abandon d'une
transaction.
Il est ainsi à remarquer que s'agissant des
systèmes AC, il s'agit des bases des données relationnelles
implémentant les propriétés de Cohérence et de
Disponibilité. Ce qui signifie que les bases des données NoSQL
sont généralement des systèmes CP et AP. [KO12].
C
A
P
Les systèmes CP sont du groupe NoSQL
Les systèmes AC renferment tous les systèmes qui
obéissent au principe ACID
Les systèmes AP sont du groupe NoSQL
Figure 2.1 : Guide visuelle au Théorème
CAP
| 
