Comprendre les notions de CL et RF

Le fait que Cassandra soit une base de données distribuée implique plusieurs contraintes. En effet si chacun des nodes possèdes X% des données comment s'assurer qu'on ne va pas tomber sur les (100 -X) % qu'un node ne possède pas ? Comment s'assurer aussi que les données que l'on reçoit sont correctes ?

Cassandra possède deux mécanismes séparés pour assurer la consistence des donées et leur "avaibility" (si quelqu'un a une bonne traduction en français je remplacerai avec plaisir).

Dans ce qui va suivre nous allons prendre l'exemple d'un parc de 3 serveurs ayant installé Cassandra.



1) Replication Factor

Nous possédons notre parc de 3 serveurs et nous avons configuré un keyspace. Le replication factor indique à Cassandra comment diviser le keyspace et distribuer les données. Cette vision quoique pas 100 % exacte permet de bien comprendre le principe.
Si on fixe RF(replication factor)=1 le keyspace va être divisé en 3 et chacun des nodes recevra 33 % des données.
De même si on fixe RF=2, on divise toujours le keyspace en 3 mais cette fois on donnera 2 morceaux à chacun des nodes.
Enfin en fixant RF=3 chacun des nodes contiendra l'intégralité des données.


2) Constitency level

2.1) Constitency Level en Read

Le niveau de consistence (abrégé CL) indique comment Cassandra va choisir une donnée valide ou invalide.
Prenons l'exemple avec les 3 serveurs. Nous voulons trouver la valeur enregistrée dans la clef "utilisateur1" Colonne : nom
On a la configuration suivante :

SERVEUR1 : valeur colonne : "Marie"
SERVEUR2 :  valeur colonne : "Julie"
SERVEUR3 :  valeur colonne : "Marie"

Si l'on fixe le consistency level à 1 Cassandra va considérer comme valide toute donnée qui est retournée en premier. Si SERVEUR2 répond en premier alors la valeur récupérée sera Julie. Si c'est SERVEUR1 ou SERVEUR3 la valeur sera "Marie".
Si l'on fixe CL=QUORUM, Cassandra va atteindre qu'une majorité de serveur réponde la même valeur. Ici ce sera Marie car 2 serveurs (66% du total) vont répondre Marie.
Enfin CL=ALL signifie que tous les serveurs doivent répondre la même chose afin que Cassandra valide une donnée. Ici ... et bien la requête échouerait !





2.2 Consistency Level en Write

Il existe un peu plus de possibilités pour le CL en write. Le consistency level en write indique la fiabilité avec laquelle on souhaite voir les données écrites. Un exemple vaudra mieux que cette définition.
Nous sommes en mode Write et on insère une valeur column "Pierre" dans la clef "utilisateur1"

Si l'on fixe CL=NONE : C'est le coup de poker. Cassandra n'attend même pas de savoir si la donnée a bien été insérée, il envoie la requête aux serveurs et clot la connexion.
Si l'on fixe CL=ANY ou CL=ONE on attend au moins une réponse d'un des serveurs. La différence entre les deux m'échappe encore, mais je promets de corriger cette partie lorsque j'aurai compris de quoi il en retourne.
CL=QUORUM : Ce consistency level indique au serveur cassandra qu'il attend qu'au moins une majorité de serveurs aient répondu avant de valider l'insertion.
CL=ALL : Dans ce mode on attend les réponses de TOUS les serveurs.



Encore une fois vous pouvez m'écrire un message ou rédiger un commentaire si je suis passé trop vite sur une notion ou si je me suis trompé.