Présentation d’Apache Cassandra

Un tour rapide sur cette base de donnée NoSQL rapide, puissante, décentralisée et libre.

Publié le

Cassandra est une base de donnée NoSQL en mode colonnes.

C’est à dire qu’elle stocke les données en un couple colonne[clé] -> donnée, comme une table de hashage.

L’intérêt principal, c’est qu’il n’y a pas de structure de colonnes établies, chaque clé peut avoir un nombre de colonnes qui varie.

Les colonnes sont regroupées par familles de colonne. C’est l’une des rares configurations que l’on peut avoir dans Cassandra : la façon dont fonctionne une famille de colonnes.

Toutes les données, c’est à dire les données des clés rassemblées en colonnes sont stockés dans l’espace de clé, le Keyspace. Le fonctionnement du Keyspace dépend de sa configuration et permet aux données d’êtres gérés (et stockés) par Cassandra.

Un serveur Cassandra peut rejoindre une grappe de cluster, cela s’appelle un ring. Le keyspace sera étalé sur tous les nodes (les serveurs Cassandra) du ring.

On peut créer une configuration qui regroupe des ring ensembles pour les dupliquer quand on a des besoins de performances et de sécurité. Cela s’appelle un datacenter dans la terminologie Cassandra.

S’il y a beaucoup d’opérations sur le Keyspace, on peut l’étaler sur plusieurs serveurs. S’il y a énormément d’opérations sur le Keyspace, notamment de plusieurs points différents, on peut multiplier le Keyspace un peu partout, ce qui rend Cassandra très solide dans un environnement de production intense.

Comme il n’y a pas de structure de donnés pré établi, il n’y a pas de possibilité de faire des requêtes structurés comme en SQL. Le nombre de colonnes n’est pas prédéfini, il n’est pas non plus limité. Pour une clé, vous pouvez avoir des millions de colonnes.

La structure de stockage du Keyspace empêche de conserver l’ordre des données envoyés, vous devrez trier les éléments que vous remontrez de Cassandra.

Le TTL, le time to live, est une durée de vie facultative d’une clé, en seconde. Passé ce délai, Cassandra détruira la clé. L’intérêt ? Poussez régulièrement vos données dans la base, vous écrasez ce qui y est déjà (car vous redéfinissez le TTL à chaque envoi), et ce qui ne l’est plus finira par être détruit. Vous êtes sûr que tout ce qui est envoyé avec un TTL est forcément récent (du maximum du TTL). Cela permet aussi de ne plus à avoir à écrire de quoi nettoyer la base des données obsolètes. Et comme vous n’avez pas de fragmentation du stockage, celui ci n’a pas besoin d’être optimisé.

Cassandra permet une cohérence, consistency, des données entre nodes/rings. Quand vous envoyez des clés, ou quand vous en remontrez, vous pouvez demander au serveur de vérifier que tous les nodes soient bien surs que votre donnée soit bien la dernière version. Vous pouvez aussi le demander que ça soit le cas sur un seul serveur, ou même sur plus de la moitié, le quorum. Vous avez le choix entre l’atomicité (la garantie d’être unique) et la vitesse.

Vous commencer un peu à comprendre comment cela marche : derrière une grosse mathématique d’algorithmes et d’optimisations, vous avez une simple machine à faire des pushs et des pulls sur des données quelconques. Vous avez une vraie souplesse de travail, du moment ou vous savez vous organiser (et car vous n’avez pas d’interface d’administration, juste un client en ligne de commande).

Cassandra est un logiciel libre développé à l’origine par Facebook. Il est très rapide, vraiment. Espérez plusieurs milliers de requêtes par secondes sur un serveur de 2008. Il est aussi consommateur de RAM. Il refusera de démarrer si votre machine n’en a pas au moins 4 Go. Mes instances de tests peuvent monter à 1,5 Go de RAM consommé en réel.

Cassandra est un logiciel écrit en Java, mais il existe une panoplie d’API dans pleins de langages.

Pour en savoir plus : http://cassandra.apache.org/