Cassandra

Récemment s’est tenue, à Levallois, une conférence présentant Cassandra, une base de données NoSQL. Pour ceux qui n’ont pas eu la chance d’assister à cette conférence, voici un petit résumé de ce qu’est Cassandra et de ce que cette base est capable de faire.

Présentation

Cassandra est une base de données NoSQL distribuée où la préoccupation première est la disponibilité de la base à tout instant. D’où quelques compromis.

Les bases de données classiques ACID ont choisi de répondre efficacement à des problématiques telles que l’accès aux données par différentes requêtes plus ou moins complexes, la cohérence de la base, etc… Cependant, il est plus compliqué pour elles d’être réparties sur plusieurs machines, mais bien entendu cela n’est pas impossible.

Cassandra ayant choisi ce mode de fonctionnement, elle possède un système de requête beaucoup moins puissant (pas de JOIN possible par exemple) mais permet de répartir la base sur plusieurs machines très facilement. Cela apporte, par la même occasion une bonne résistance aux pannes car il n’y a pas de point central où toutes les données sont enregistrées (pour anecdote, la phrase qui est revenue le plus souvent dans la conférence est « Nous voulions pouvoir dormir la nuit »), un accès I/O très rapide et une grande disponibilité.

On pourra utiliser Cassandra dans des cas très variés allant de l’enregistrement de commentaires sur un site, de l’enregistrement de logs, etc…

Le modèle de données

Il existe deux API de requête :

  • Thrift, qui est l’API historique de Cassandra (mais pas très intuitive),
  • CQL (Cassandra Query Language) qui ressemble très fortement à du SQL mais où le Insert et le Update sont identiques (notion d’upsert). Cependant, comme dit précédemment, il n’y a pas de JOIN et le système fonctionne sans transaction.

Le fonctionnement de Cassandra est simple. La table possède une Primary Key (PK) qui servira, par défaut, pour l’indexation des données et la recherche de celles-ci. Par conséquent, si on imagine une table :

1
Login (PK), Mot de passe, nbAléatoire

On ne pourra pas faire une recherche pour savoir quelle est la personne ayant le plus gros nbAléatoire. Il faudra pour palier à ce problème créer un nouvel index basé sur le nbAléatoire.

La PK influe aussi sur la répartition des enregistrements sur le disque. Deux PK hashées de valeurs adjacentes seront proches (au niveau enregistrement) sur le disque. Et s’il y a des PK composites, la première PK indiquera la machine sur laquelle l’enregistrement s’effectuera et la seconde indiquera l’ordre dans lequel l’enregistrement est effectué, ce qui facilite la récupération quand celle-ci doit être ordonnée.

L’architecture

Comme dit précédemment, l’enregistrement sur le cluster de nœuds va se faire par rapport à la PK et fonctionne grâce à un système de hash. Le fonctionnement est très simple. A l’installation de l’architecture de Cassandra, on veut que la charge soit le plus possible répartie sur les différents nœuds du cluster. Il y aura donc dans un premier temps une réflexion pour savoir le nombre de machines à utiliser pour le système. Lorsqu’on aura le nombre de nœuds, on pourra facilement déterminer les codes « hashés » des différentes machines. Le plus simple à l’installation est tout simplement de prendre la valeur maximale possible du hash et de diviser ce nombre par le nombre de machines. On aura alors un cluster « équilibré ».

Il suffit ensuite de faire quelques configurations, renseigner aux autres nœuds les hashs de chacun des nœuds et notre système est prêt.

De là, la répartition des informations se fait très simplement. Le système va envoyer l’information à stocker à un nœud (pris « aléatoirement ») du cluster. Ce nœud va alors analyser le hashcode de la donnée et le comparer à la table des nœuds qu’il possède. Imaginons que le Hash de l’objet soit entre le poste jaune et le poste vert, il va alors envoyer l’information au poste vert (Cassandra utilise le poste de hash supérieur). Ce fonctionnement a pour conséquence de répartir les enregistrements sur les différentes machines.

RF et CF entrent en jeu

Mais alors, qu’en est-il de la grande résistance aux pannes ? Si un des nœuds crash, l’authenticité de la base ne sera plus garantie. Oui, ce sera le cas si vous ne laissez pas la configuration par défaut et que vous configurez mal. Il existe un paramètre de configuration nommé Replicator Factor (RF) qui indique le nombre de réplications à effectuer pour un enregistrement. Plus ce nombre est élevé, plus le nombre de duplications est fort, plus votre base est résistante aux pannes mais plus votre système est lourd, lent et complexe. Il est donc à configurer avec sagesse. Il y aura donc duplication sur les RF – 1 nœuds suivant le premier nœud possédant l’enregistrement. En imaginant que notre nombre de nœuds soit 5 et que nous choisissions un RF à 3, alors nous aurons :

Nous avons donc un système relativement solide et robuste. Mais il reste cependant un problème. Qu’arrive t-il si nous mettons à jour un enregistrement et que nous y accédons le millième de seconde après. L’enregistrement multi-nœuds peut prendre du temps et ce n’est pas le même pour chaque nœud. Alors, si nous enregistrons une valeur sur un nœud avec une réplication sur les deux suivants mais qu’entre temps, après enregistrement sur le premier nœud, nous avons un accès en lecture à cette valeur, comment être sûr que cette valeur est la valeur la plus à jour. Les développeurs ont mis en place un paramètre de configuration appelé le Consistency Level (CL). Ce nombre correspond au nombre de machines devant répondre à la requête avant que le système dise OK.

De cette façon, si le système demande la donnée de couleur rouge et que l’on a configuré le CF à 2, il y aura attente de deux réponses et vérification de la cohérence des données avant que celle-ci ne soit envoyée. Attention cependant à ne pas configurer cette valeur n’importe comment. La configurer à 1 implique qu’il n’y aura aucune autre vérification. La valeur envoyée peut donc ne pas être bonne car c’est le nœud le plus rapide qui gagnera. Attention aussi à ne pas en mettre trop car cela ralentira le système. Les développeurs Cassandra conseillent d’ailleurs d’utiliser une variable interne nommée Quorum qui est le nombre préconisé de vérification (RF/2) + 1.

Stockage

Le stockage des données pour Cassandra fonctionne en 3 temps. Dans un premier temps, à l’enregistrement des données, il y a écriture en mémoire et sur le disque dans un commit log (servant à l’historique des enregistrements en cas de panne).

Au moment du flush des données de la mémoire vers le disque dur, la table en mémoire est sauvegardée telle quelle, il n’y a aucun traitement d’organisation des données ou autre. De cette manière, il peut y avoir deux, trois, quatre tables sur le disque avant une fusion (une table par flush).

Le processus recommence ainsi une multitude de fois. Cependant quand il y a plusieurs tables sur le disque dur, le système fusionne les deux tables pour en faire une plus grosse. Ce mécanisme permet de mettre les données à jours. Imaginons 3 données (A, B, C). Dans la première table se trouvent A et B et dans la seconde se trouvent A et C. Lors du processus de fusion, le système va mettre à jours A en se basant sur la date de création. De cette manière, le A de la première table va se trouver supprimé et sera remplacé par le A de la seconde table.

Ce mécanisme permet entre autre de mettre à jour les données qui ont été insérées dans la première table, puis mises à jour dans un second temps et donc insérées dans la seconde table.

Pour conclure

Voilà pour Cassandra, la base de données NoSQL. Je ne l’ai personnellement pas utilisée mais je pense que cette base a du potentiel. Bien entendu, il ne faut pas l’utiliser sans se poser la question : « sera-t-elle utile dans mon système ? ». D’après certains témoignages durant la conférence, cette base de données est très facile à mettre en place (certains parlent de deux ou trois heures) et elle peut être très puissante si on effectue, au préalable, une bonne analyse de son système pour définir ce que l’on mettra comme PK dans chaque table.

VN:R_U [1.9.22_1171]
Rating: +1 (from 1 vote)
Share
Ce contenu a été publié dans Non classé, avec comme mot(s)-clef(s) , , . Vous pouvez le mettre en favoris avec ce permalien.

Laisser un commentaire