Cassandra: Pour une Réplication Efficace de Vos Données

On connait tous les bases de données relationnelles telles que MySQL ou PostreSQL, on peut apprendre sans accrochages et leur utilisation n’est pas compliquée.

Vous qui me lisez, vous êtes sans doute le roi (ou la reine) du schéma relationnel, vous souhaiteriez découvrir le NoSQL avec Cassandra ? Pas de problème, enlevez votre couronne, car vous allez entrer dans un royaume qui se situe à cent lieues de celui que vous connaissiez si bien. La route sera longue et je suis moi-même loin de tout maîtriser !

Pourquoi NoSQL ? Le buzzword du moment, mais qu’en est-il vraiment ?

On distingue 4 principaux types de bases NoSQL :

  • Clé/Valeur (Redis, Hazelcast)
  • Graphes (Neo4J, OrientDB)
  • Documents (MongoDB, CouchDB)
  • Colonnes (Cassandra, HBase, BigTable)

Bien sûr, une très grande quantité de ses systèmes existent et leurs utilisations peuvent être variées. Cassandra peut aussi être employé en tant que stockage clé/valeur, chacun a ses particularités, ses avantages et ses inconvénients.

Votre choix impactera le futur

Ne choisissez jamais une technologie parce que tout le monde l’utilise ou parce que c’est la seule que vous connaissez, vous devez avant toute chose connaître les besoins auxquels vous souhaitez y répondre.

Dans le cadre d’un projet, Cassandra a été adopté, car optimisé pour l’écriture (insert) et par son modèle de nœuds distribués. On avait besoin de données distribuées à travers plusieurs serveurs et datacenters et les performances sur l’insertion de donnée était un point majeur de notre application.

Cassandra en bref

Je ne voudrais pas vous parler en détail du fonctionnement de Cassandra, d’autres articles en parleraient mieux que moi, mais juste de ses atouts et ses subtilités.

Schéma CQL

Oubliez le Structured Query Language, voici le Cassandra Query Language (CQL), vous ne serez pas perdu, car ce langage est très fortement inspiré du SQL !

Avec Cassandra, quand vous modélisez vos schémas, le fonctionnement de son stockage linéaire en mémoire, du stockage colonne ainsi que le principe de tombstone doivent êtres acquis.

Toutes les performances de votre application seront liées à vos schémas donc la moindre erreur et c’est la catastrophe. De plus, si vous souhaitez modifier vos schémas une fois le code métier écrit, vous pourrez, mais vous devrez modifier l’ensemble de votre implémentation. Autrement dit, tout le développement tournera autour de vos schémas que vous avez établis d’où l’importance d’y passer du temps.

Réplication

La réplication est la baguette magique de Cassandra, l’un de ses atouts les plus appréciés de ses utilisateurs. Vous démarrez une instance de base, puis N autres qui se connectent à celle-ci et le tour est joué. L’ensemble des données est répliqué à travers l’anneau (ensemble de nœuds) et si un nœud tombe, pas de pertes.

Lors de la création d’un keyspace (équivalant d’une BDD MySQL contenant plusieurs tables), un niveau de réplication à travers l’anneau peut être défini. De plus, pour récupérer une donnée stockée en base, une option spéciale permet d’interroger un ou plusieurs nœuds dans un ou plusieurs datacenters selon notre besoin. Par exemple, avec un niveau de consistance QUORUM, votre donnée est déclarée comme correcte lorsque N+1 nœuds de n’importe quel datacenter transmettent le même résultat.

pH neutre

Autrement dit, pas d’ACID comme vous pouvez le connaître.

Un peu déroutant pour les habitués des transactions, mais suivant le cas d’usage vous n’avez sans doute pas besoin de transactions. Les bases NoSQL sont conçues avant tout pour du big data, en d’autres termes, enregistrer et stocker une grande quantité d’information. Selon certains cas d’usages, lorsque vous demandez une donnée en base, une donnée correcte ou obsolète importe peu. Vous pouvez toujours jouer avec le niveau de consistance pour avoir une donnée plus ou moins correct, comme expliqué plus haut.

TTL et bien d’autres

Cassandra intègre la gestion des TTL (time-to-live) qui permet de définir une durée de vie à une donnée. Cette fonction est très délicate à gérer suivant certains cas bien que la NASA l’utilise beaucoup. À vrai dire, cela évite d’écrire et de maintenir une routine qui supprime d’elle-même les données obsolètes.

Beaucoup d’autres fonctionnalités sont à découvrir, mais pour le moment celles-ci sont des plus utiles à connaître.

Ils en ont fait l’expérience

Spotify est passé de PostgreSQL à Cassandra.

Netflix, de MongoDB à Cassandra.

Facebook avec Instagram est passé de Redis à Cassandra.

Cassandra est puissant, mais délicat. Estimez correctement vos besoins et assurez-vous de comprendre son fonctionnement.

comments powered by Disqus