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 ...

Dart Flight School

Après de très bonnes présentation lors des derniers JUG à Montpellier

• AngularJS la plateforme Javascript de Google, 
• Vert.X une nouvelle plateforme événementiel pour la JVM accès sur la performance et la montée en charge 
• Neo4J qui nous a permis de comprendre tout l'intérêt des bases de données de graphe

Retour sur le dernier JUG Montpellier, où cette fois-ci c'est une mini-présentation de DART et surtout un codelab pour faire nos premières armes en DART.

A l'occasion de la sortie de Dart 1.0, Google organise dans le monde entier le "Dart Flight School" durant le mois de Février et permet ainsi sous forme d'atelier de découvrir ce langage.

Dart est un langage orienté objet, optionnellement typé et vise à concurrencer Javascript dans nos navigateurs.

Dart peut être compilé en Javascript ou s'exécuter nativement dans une version modifiée de Chomium. (Dartium) ayant une Machine Virtuelle Dart.

Dart peut aussi s'exécuter côté serveur.

Ce codelab par la réalisation d'une petite application de gestion de films nous a permis de comprendre les bases de Dart et de voir la syntaxe qui peut être assez puissante (et se rapprocher de Scala) et compacte (mais attention à la lisibilité alors).

En tout cas félicitation à l'équipe du JUG Montpellier pour ce superbe travail de préparation. La salle était pleine ce qui montre l'engouement suscité par ce langage.

La question que je me pose maintenant : faut-il se mettre à AngularJS ou à AngularDart ? De toute façon les concepts sont proches ...