Une base NoSQL: Cassandra
La clusterisation
Multi-nodes
Un des avantages de Cassandra est la possiblité de clusteriser plusieurs serveurs et donc de pouvoir évoluer dans une architecture distribuée sans problème. Les noeuds sont représentés dans un cercle on appelle celà un "node ring", il n'existe aucun noeud maître afin que chaque noeud dispose du même rôle. Pour communiquer entre eux les noeuds utilisent le gossip protocol, son fonctionnement est assez simple, chaque noeud dispose d'une liste de noeuds présent sur le réseau (seeds) et à chaque requête le noeud va ensuite interroger tous les noeuds de sa liste et ainsi de suite. Nous allons voir dans cette partie comment on peut clusteriser 2 noeuds ensemble.

Noeud 1
Notre noeud 1 sera le premier sur le réseau donc sa liste de seeds est vide, mais nous devons au moins mettre un seed qui sera lui-même.
<Seeds> <Seed>192.168.1.10</Seed> </Seeds> <ListenAddress>192.168.1.10</ListenAddress>
Noeud 2
Cette fois-ci il y a déjà le noeud 1 sur le réseau donc on peut le renseigner comme seed du noeud 2.
<Seeds> <Seed>192.168.1.10</Seed> </Seeds> <ListenAddress>192.168.1.32</ListenAddress>
Une fois nos 2 noeuds lancés nous pouvons vérifier leur fonctionnement en utilisant un utilitaire fourni avec Cassandra qui va nous indiquer si les noeuds sont bien présents dans le cercle:
# bin/nodetool -host localhost -p 8080 ring Address Status State Load Owns Token 138909169600824171522207208684894387830 192.168.1.32 Up Normal 10,43 KB 26,76% 14294106406611201179800483086482230341 192.168.1.10 Up Normal 10,43 KB 73,24% 138909169600824171522207208684894387830
Cohérence des données
Un des premiers problème qui se pose dans une architecture distribuée est comment peut-on assurer la cohérence des données. En effet, lors de la récupération de données rien ne nous assure que celle récupérée est la plus à jour. C'est dans ce cas qu'intervient la présence du champs timestamp dans les colonnes ce qui va permettre de déterminer la donnée la plus à jour en comparant les timestamp des données récupérées. C'est Pour celà, Cassandra a défini 4 niveaux de cohérence qui va correspondre au nombre de noeud interrogé pour récupérer une valeur:
- ZERO
- ONE
- QUORUM
- ALL
ZERO: Cassandra ne veillera pas a récupérer la donnée sur d'autres noeuds, il n'y a donc pas de vérification sur l'exactitude de la donnée récupérée, elle peut tout à fait être périmée.
ONE: Cassandra s’assure que la donnée est écrite sur au moins un des noeuds avant de répondre au client. Lors des lectures, la donnée sera retournée du premier noeud où elle est trouvée. Dans ce cas, il est nécessaire d’envisager l’éventualité d’avoir une donnée non cohérente car rien ne nous garantie que le noeud qui nous retourne la donnée possède la dernière version de la donnée.
QUORUM: Dans ce cas, Cassandra écrira les données sur replicationfactor/2 + 1 noeuds avant de répondre au client (le ReplicationFactor est le nombre de noeuds sur lesquels sera répliqués la donnée). Pour la lecture, la donnée sera lue sur replicationfactor /2 + 1 noeuds avant de retourner la donnée. Dans ce cas, on a la garantie de récupérer une donnée consistante.
ALL: Dans ce cas, Cassandra écrira et lira la donnée sur tous les noeuds
Réplication des données
Il existe 2 types de réplication de données qui sont configurable dans le fichier de propriétés du serveur. Tout d'abord le nombre de réplication est défini par la propriété réplicationFactor, étant dans un cercle les données vont être réparties de manière cyclique (N+1, N+2, etc.).
Le premier type de réplication est appelé RackUnware, cela consiste à répliquer uniquement les données dans le cercle courant. Le deuxième est le qui cette fois-ci va répliquer les données dans le cercle courant mais aussi dans le datacenter voisin (si l'architecture est composée de plusieurs datacenters).