Cassandra - Ecriture des données

Edit : En raison d'une erreur je me permets d'editer ce qui a été fait. Veuillez m'excuser pour cette erreur, j'ai écrit l'article hier soir tard. Les MemTables sont bien évidemment, comme leur nom l'indique, en mémoire. Toutes les sections de l'article sont concernées par les changements.

Je pense qu’il est particulièrement important de comprendre ce qui se passe dans Cassandra, surtout si l’on souhaite comprendre d’où viennent les problèmes.

Deux notion importantes que nous allons essayer de comprendre aujourd’hui sont le « commitlog » et les  « Memtables » et enfin les SSTable.

Tout d’abord je vous invite à regarder cette vidéo si vous en avez le temps : http://riptano.blip.tv/file/4012133/ . Cette vidéo explique comment résoudre les principaux problèmes que l’on peut rencontrer en utilisant Cassandra. C’est assez difficile à comprendre et cela présente l’outil « nodetool », outil auquel je consacrerai mon prochain billet.

1) Le CommitLog

Le CommitLog est la première barrière que rencontrent les insertions lorsqu’elles sont passées à Cassandra. Au lieu d’insérer directement les données ce qui pourrait se révéler coûteux dans les cas de bases de données très utilisées, Cassandra écrit toutes ces opérations dans le CommitLog qui se trouve sur le disque dur.

L’écriture dans cette structure de données est très rapide.

Lorsque vous démarrez Cassandra si vous regardez ce qui s’affiche et que vous avez déjà lancé auparavant cassandra vous verrez la ligne suivante :

INFO HH : mm ss,xxx Replaying $CASSANDRAHOME/commitlog/CommitLog-XXXXXXXXXX.log

Cette ligne indique que Cassandra reconstruit l’ensemble des operations qui lui ont été passées afin de reconstruire les précieuses MemTable.

2) MemTable

Les Memtables sont construites en même temps que le CommitLog et résident en mémoires.
Lors d'une insertion les MemTables se chargent d'organiser les différents writes en mémoire (notamment en effectuant un tri des colonnes), c'est la raison de la rapidité des insertions sur Cassandra, puisque dans les bases de données la plupart du temps nécessaire est consacré à la recherche sur le disque dur puis à l'insertion à la place correcte.
L'opération de Flushing peut se révéler assez coûteuse  il faut faire attention à effectuer les réglages nécessaires dans le storage-conf.xml

3) SSTable

Les SSTables sont la forme sur le disque dur des données sous Cassandra Cassandra. Les SSTables sont découpées par ColumnFamily et par Row/Key. 
Une fois qu'une MemTable a atteint une certaine taille en mémoire ou qu'elle a résidé pendant trop longtemps en mémoire Cassandra estime qu'il est temps de sauvegarder les données sur le disque dur. Cette opération a pour nom le Flushing des MemTables. Pendant cette opération un fichier est créé sur le disque dur contenu l'ensemble des données de la MemTable tandis qu'une nouvelle MemTable est créée.
Plusieurs SSTables peuvent résider sur le disque dur de façon concurrent pour une même ColumnFamily et Row.

Une fois un nombre donné de SSTables écrites sur le disque dur (4 par défaut dansa le storage-conf.xml) Cassandra effectue une compaction (compression) des données. Toutes les opérations des 4 SSTable sont comparées et seules les plus nouvelles sont gardées, puis ensuite écrites sur le disque dur dans une SSTable finale. L'opération a de nouveau lieu lorsque le nombre de SSTable retrouve sa valeur maximale. Cette opération peut être assez couteuse, il faut donc bien la déclencher en fonction des besoins.

4)Illustration 

Pour illustrer tout ce qu’on vient de voir voici un exemple de ce qui arrive, en très simplifié. Les concepts restent les mêmes.

Nous avons l’école Ecole1 qui insère les notes d’espagnol dans une Row/Key « Espagnol ». La ColumnFamily trie par UTF8-Type donc on insère en tant que nom de colonne le nom de l’élève et en tant que value sa note.

On va supposer que le prof qui insère les notes est lent et ne sait pas se servir de son clavier, il se trompe souvent et à besoin de renvoyer la note de ses élèves. La configuration de Cassandra est la suivante le Flushing est régulier et est basé sur le temps : il a lieu toutes les 10 minutes, on fixe le nombre de SSTables maximal à 3.

Voici les opérations qui vont être faites :

10h10 Insère Pierre : 7
10h12 Insère Marie : 8

[Flushing de la MemTable]

10h21 Insère Pierre : 9
10h25 Insère Jean : 10

[Flushing de la MemTable]

10h32 Insère Pierre : 12
10h37 Insère Jean : 3

[Flushing de la MemTable]

etc...

Etudions ce qui va se passer : Entre 10h10 et 10h20 : Aucun MemTable, tout est dans le CommitLog
10h20 : SSTable1 Créée avec comme valeurs {Pierre:7} et {Marie:8}

10h30 : SSTable2 Créée avec comme valeurs {Pierre:9} et {Jean:10}

10h40 : SSTable3 Créée avec comme valeurs {Pierre:12} et {Jean:3}

10h40 : Compaction car  Cassandra détecte qu'il y a 3 MemTables, création de la SSTable1 avec comme valeurs :

{Pierre:12} {Jean:3} {Marie:8}

Et ainsi de suite !

J'espère que ce que j'ai dit vous a été utile et dans le cas où ça l'aurait été n'hésitez pas à faire partager ce blog !
Je vous remercie.