Insert your widgets from Appearance->Widget

Blog

JUG Montpellier sur Cassandra

Après la très bonne présentation sur Java 8 en juin par José Paumard, c’était la rentrée pour le JUG Montpellier avec Cassandra.

Nous avions pour présenter ce JUG Sylvain Lebresne de DataStax (la société qui est derrière Cassandra) et Alain Rodriguez de Teads qui gère cette solution depuis 3 ans avec des retours d’expérience très intéressantes.

Cassandra est un base de données distribuée.

C’est un projet Apache depuis 5 ans qui s’est inspiré de Dynamo ou encore de BigTable pour le modèle de données.

Les grands intérêts de cette solution sont :

– la possibilité de réaliser un scaling horizontal des données sur des machines à faible coût. Le principe est de préférer avoir de nombreux serveurs avec un bon 

rapport prix / puissance qu’un gros serveur très cher. Sachant qu’il y a des exemples d’anneau comprenant 1000 serveurs en parallèle,

– la possibilité de gérer de très gros volume de données,

– la disponibilité : on peut atteindre les 100% de disponibilité (upgrade sans arrêt du serveur, tolérance aux pannes, …) sans avoir une architecture hors de prix,

– un des principes de Cassandra est qu’il n’y a pas de serveur maître ou de hiérarchie de serveurs entraînant souvent des SPOF,

– le déploiement est possible assez facilement sur différentes régions géographiques,

– une haute performance notamment avec des écritures à faible coût.

Cela vient répondre aux limitations des bases relationnelles dans lesquelles il est difficile et très coûteux de scaler notamment liés aux limitations suivantes :

– les jointures ne permettent pas de bien scaler

– les contraintes ACID (très utiles pour les développeurs) ne permettent pas de bien scaler

– le design des bases relationnelles a été réalisé pour être mono-instance (cluster possible mais très coûteux et au final limité, le sharding des données est possible mais la gestion des pannes est délicate).

Le principe de la solution HD de Cassandra est que la réplication est réalisée de manière asynchrone sans maître.

Les données sont répliquées sur plusieurs serveurs (configuration possible du nombre de réplicas par le Replication Factor) garantissant ainsi un accès aux données même si un serveur est down (de manière voulu ou non).

Chaque donnée stockée possède un ID (hachage). Cet ID permet de localiser les données sur les différentes serveurs, chaque serveur gérant plusieurs plages de données connues par tous le serveurs.

Un des principes de Cassandra est de réaliser le travail pour faciliter la récupération des données à l’écriture, optimisant ainsi le travail de lecture « pré-maché ».

La soirée c’est poursuivie sur la présentation de CQL (Cassandra Query Language) et du Java driver.

CQL est un sous ensemble de SQL pour la dé-normalisation des données adapté pour la distribution des données et le cluster.

Le Java Driver permet de se connecter vers un base Cassandra avec une gestion automatique et transparente des noeuds (load balacing et fail-over automatique).

Et enfin quelques conseils utiles pour finir la soirée :

– monitorer les logs, l’état up/down des serveurs, la latence du cluster, le heap du GC, l’espace disque disponible, …

– toujours avoir de la marge sur les serveurs et ne pas attendre qu’il n’y ait plus de ressources pour ajouter un nouveau serveur car cela serait contre productif à cause de la surcharge liée à l’ajout d’un nouveau serveur sur l’anneau (copie des données sur le nouveau serveur)

– réaliser les opérations de maintenance lorsque la charge est faible

– tester les upgrade avant et ne pas faire d’upgrade si l’anneau est instable

– regarder les anti-patterns : http://www.datastax.com/documentation/cassandra/1.2/cassandra/architecture/architecturePlanningAntiPatterns_c.html 

Donc voilà encore un soirée du JUG très instructive …

Emmanuel Pavaux

Written by

The author didnt add any Information to his profile yet