Cassandra : What to do when you run out of disk space?

Hi folks

In the first place, running out of disk space with a Cassandra cluster is not something you really want to experiment, trust me...

Caused by: java.io.IOException: No space left on device

I guess that if you're reading this post, you don't mind about this advice because it's too late though.

Why Cassandra need (so much) free space?

Under the hood, Cassandra works with internal processes which needs temporary disk space (up to the size it's already using...) such as : 

• Running Compactions: As SSTables are immutable, Compactions are the processes which reorganize SSTables by recreating new SSTables and to do so, use space on disk.
• Keeping Snapshots: a snapshot corresponds to a copy of SSTables at a certain point of time. Cassandra uses hard link to create the snapshots. Basically, taking a snapshot is not something that will increase the disk but over the time, keeping snapshots will increase the disk (because the snapshot files are not deleted).

What can you do?

First question is : Is it only one node or your entire cluster which is running out of disk space?

If it's only one node, you can follow the proposals below but sometimes it's easier to trash the node and to replace it with a fresh new node... Thanks to Cassandra and the way it distributes the data across a cluster, you should not end up with one node with (a lot) more data than the others.

If it's your entire cluster which is running out of disk space... Well... It's where the fun begins... I can't promise that you will not loose data...

Most of the actions that you can run on a node to reclaim spaces will start to increase a bit the disk usage...

Quick wins

• Stop writing data into the cluster

It sounds a bit weird but yes, first of all let's stop the bleeding...

• Clear Snapshots 

run on each node:

nodetool cfstats

nodetool listsnapshots

Theses commands will show you if you have any snapshots. If so they are good candidates to reclaim spaces and then to delete them: 

nodetool clearsnapshot

• Increase the disk size of the nodes 

If you can temporary increase the disk size of your nodes, it's worth to do it to get back on a less critical state first. A state, where you can think of adding nodes and so on. If you're running your cluster on the cloud, most of the cloud provider provide ways to extend the disk. In most of cases you'll have to stop and start the VMs hosting your nodes.

• Remove data (if you can...)

It can be a bit extreme as well but depending on your context and your use case it's perhaps possible...

You can drop or truncate tables. This solution is quite efficient because no tombstones are written. Cassandra just create a snapshot of the table when you run the command. The disk space is released when you clear the snapshot.

Not so quick win

• Add nodes

This is the usual procedure... If your cluster needs more space, add more nodes...

Adding nodes means that the ownership data is changing between nodes. Cassandra does not automatically release the data which has been moved to other nodes. Do not forget to run a cleanup on each nodes:

nodetool cleanup

If you're still very limited in terms of available disk space, be careful because running a cleanup temporary increase the disk space. You can limit this increase by running the cleanup table per table :

nodetool cleanup yourkeyspace yourtable

• Remove data (if you can...)

The other way to delete data by inserting tombstones in your cluster. To avoid to wait the gc_grace_seconds parameter before the tombstones will be evicted (by default it's 10 days), you can change the value by using the ALTER cql command. Before doing that check, check that old nodes are Up :

ALTER TABLE keyspace.yourtable WITH gc_grace_seconds = 3600

Best advice

If you survived to the issue, I'm pretty sure that you don't want to face it one more time. I would warmly recommend to monitor the disk usage of the nodes in your cluster. 

If you're using the SizeTieredCompactionStrategy (which is the worst regarding the needed free space) a good practice is to keep your disk usage below 50 to 60% and to add nodes before reaching the 70% threshold.

There's a currently an opened ticket to tackle this type of problem: 

https://issues.apache.org/jira/browse/CASSANDRA-14499

Enjoy!

Cassandra Lan Party How-to

Hi Cassandra folks,

I would like to share with you my experience regarding the organization of a Cassandra Lan party.

<;-)>

Are we still the worldwide Cassandra Lan party record holder with 36 nodes? 🤔https://t.co/VH9PIc2o9j @nromanetti @framiere #itwassocool #Cassandra

— Jérémy Sevellec (@jsevellec) September 20, 2019

It looks like I'm still the record holder of the biggest Cassandra Lan party organized with a 36 nodes cluster. I would be so happy if someone can beat this record!

</;-)>

I've already organized a bunch of Cassandra Lan party during conferences or meetups. If you want to have it done the right way and to avoid to loose time or just to fail, it's a bit of work and preparation...

Here's my How-to regarding the preparation and the run of a Cassandra Lan party. Feel free to use it or to just take a part of it! I know that this How-to works because i did it several times. It does not mean that you can't do it in another ways though.

Special thanks to friends who were already part of Cassandra Lan party organizations with me: 

• Nicolas Romanetti
• Florent Ramière
• Sylvain Lebresne
• Thomas Recloux
• Gautier Dhordain
• Amira Lakhal

The goal

The basic goal of a Cassandra Lan Party is: 

• to create a network with the attendees' laptop
• to create a Cassandra cluster on top of it. One node per attendee
• to let attendees manipulate data of the cluster all together
• to play with the cluster (like "oh s..., we lost one data center" and so on)

The ideal situation is also to be able to: 

• setup a multi data center Cassandra cluster. 3DCs with a replication factor of 3 per DC
• be isolated in terms of network

1. Preparation 

You need a Team:

• 1 driver who displays slides
• 1 team member per DC who:
• knows the procedure
• will be responsible of doing the network setup of the data center
• will be a seed node with his own machine
• will help the other attendees who are part of the data center

So basically, a team of 4 peoples if you want to simulate a 3 data centers clusters is an ideal setup.

You need network equipments :

• 1 small switch (at least 4 ports)
• 3 big switches (the bigger they are the more attendees you can get)
• 3 RJ45 network cables at least 3 ou 5 meters long to connect switches togethers
• as many as RJ45 network cables as you can for the attendees (a mix of 1m, 2m and 3m is perfect) 

You need additional equipments:

• a luggage to carry everything in

• flashy t-shirts, so attendees can identify the Cassandra Lan Party team easily

• USB keys
• few power strips
• a scotch roller
• sticky notes
• few felt pens

I know that it's the most tricky part is to find the network equipments part. In my case, what I did was to ask some companies around me if they would lend me the network equipments by giving them a bit of visibility during the Lan Party and it worked fine... 

Also, regarding USB Keys, the goal is to load them with: 

• JDK8 for all OS platforms
• Python for windows
• The Cassandra binary

If you don't have any USB Keys, you also have the option to distribute the archives thanks to the Cassandra Lan Party Configurator that the driver will run from his laptop once the network setup id done during the Cassandra Lan party (more details below).

In addition to that, You need: 

• Some Slides to guide the attendees
• the Cassandra Lan party configurator (again, more details below)... 

And that's it!

I would advice, if you can, to test the network equipment before the Cassandra Lan party D Day. You can also organize a repetition just with the team or with few close friends.  It enables to feel more relax for the D day.

If you can contact the attendees before the event, you can ask them :

• to come with a laptop
• install a JDK 8
• yo come with a RJ45 adaptor for the laptop (like for the recent Mac for instance...)

2. Room preparation

To better picture the DCs physically, group tables to create 3 areas which will define your 3 DCs. One big switch per DC.

You can also spread sticky notes and pens on the tables.

Here is an example of a room setup i did for a repetition: 

Each table is a DC + the table at the back with the driver laptop which also display slides and the smaller switch.

3. Welcome attendees

Just few things about that : 

• try to guide them to spread them across all the DCs. the Ideal situation is to have the same number of attendees per DC (or close to). You need to have at least 2 attendees per DC + the team member of the DC (the setup is using a RF of 3 per DC).
• display a slide to kindly ask people to not touch anything. Regarding my experience, Attendees are sometimes quite excited to participate and want to go too fast. The idea is to go slow at the beginning to not fail the Cassandra Lan Party. 
• distribute USB Keys
• start the Cassandra lan Party with slides

4. Network Setup

The first thing is to ask attendees to switch off WIFI.

The goal is to create this network setup :

The small switch (WORLD) is connecting the 3 DCs (LILLE, SAN FRANCISCO and SINGAPORE) all together. The driver laptop is connected to the small switch and all the other attendees and team members are connected to a DC switch.

The Ip allocation is done manually to be able to control it.

As we will use the RackInferringSnitch of Cassandra to distribute the node across the DCs. IPs of Attendees have to look like: 

10.X.1.Y

where:

• X corresponds to the number of the DC (in our case "1" for Lille, "2", for SF, ...)
• Y is an incremental number given by the DC team member. "1" will be used for each DC team member
• 10.1.1.0 will be for the driver laptop

For example for the Lille DC: 

• 10.1.1.1 : DC team member
• 10.1.1.2 : 1st DC attendee
• 10.1.1.3 : 2nd DC attendee
• ...

To avoid any issue and a big network mess, I would advice to use sticky notes to write each IP with the name of the attendee on the closest wall to the DC and also to control the plugging into the switch.

Once connected you can ask attendees to do the network configuration : 

• IP : the one from the sticky note
• network mask : 255.0.0.0
• no proxy
• no gateway

And then to ask them to ping: 

• 10.1.1.0
• 10.1.1.1
• 10.2.1.1
• 10.3.1.1

5. A bit of Cassandra theory

Usually, once the network setup is done or if there's one or two laptops causing issues, I would recommend to do a bit of Cassandra theory with few slides. How deep you need to go depends a bit on the experience of the attendees. Up to you to decide how far you want to go. The good thing is that it let a bit of time to try to solve network issues in the background.

6. Cassandra Setup 

Again, the first gentle reminder that you have ask to attendees is to not start Cassandra before the green light of the DC team member.

How to do the distributed setup : There's an app for that. 

The Cassandra Lan Party Configurator is a web application that will help attendees to do the setup of Cassandra on their machine. The goal is to let attendees to do the setup themselves but guided thanks to the application. The application is OSS and Apache licensed.

Main features are : 

• attendees configuration helper
• archives provider
• cluster status

I would recommend to run the application from the driver laptop.

7. Cassandra cluster start

Once all attendees are done with the Cassandra setup, you can start nodes.

As we set the auto_bootstrap properties to false, it enables to accelerate the creation of the cluster. The drawback is that if an attendee is joining after the creation of the keyspace, he will have to remove the auto_bootstrap properties to join the cluster and to receive data.

First, start the seeds nodes which should correspond to each of the DC team member. Then, once the seeds nodes are there, you can let each of the DC team member adding nodes one after each other asking attendee to start his node.

8. Play with the Cassandra cluster

Once everyone is there, create a keyspace and one table so all attendees will be able to play with.

The important thing is to create the keyspace with the good strategy and using a RF of 3 per DC.

CREATE KEYSPACE "lanparty" WITH REPLICATION = {'class' : 'NetworkTopologyStrategy', '1' : 3, '2' : 3, '3' : 3};
use lanparty;
CREATE TABLE attendee (
  email text primary key,  first_name text,  last_name text);

Then you can ask every attendees to play with CQLSH to insert and read data...

and The cool thing is that you can simulate DC connections issue by just unplugging the network cable of one DC Switch from the small switch.

I let your imagination do the rest...

Conclusion

I hope this How-to can help and I'm looking forward for feedback of new Cassandra Lan party!

As you have seen the network setup with switches and network cables is the biggest part of the Cassandra Lan Party. It's also a funny part because attendees really like this part of the setup.

I think that it could be possible to replace the 3 big switches and the network cables by 3 WIFI points.

Don't hesitate to contact me if you have any questions!

Jérémy

Cassandra : Compaction, compaction and compaction

Hi Folks,

The word "compaction" is heavily used in the Cassandra world. You can see it everywhere while reading documentation, blog post, mailing list and so on.

Sometimes the use of compaction in combination of another word can be a bit misleading. Let's try to take a step back and to sump up a bit all the different concepts where the word compaction is used:

[Compaction]

Let's say the default one when you talk about Cassandra compaction. Cassandra has a write path which is very efficient. The concept is like "let's put as fast as possible the data into a file and in memory". In a second step, the data will be flushed on the disk as is. Ok but then, to enable Cassandra to also have an efficient read path, especially when you have to read a file from the disk, you need to tidy up and rearrange all the files. This process is called the compaction. A bit more technically : SSTTable are immutable and compaction is the action of generating new SSTable by merging and purging the old ones (duplicate, deleted data with expired ttl and tombstone).

Minor [Compaction]

We are still talking about the default compaction. The minor compaction is not really something which is minor.... The minor compaction is the compaction handled automatically by Cassandra as a background process and according to the chosen compaction strategy (see below).

Major [Compaction]

We are still talking about the default compaction mechanism in Cassandra. Contrary to the minor compaction, the major compaction is triggered by a manual action on a node (using nodetool compact). The major compaction can behave differently depending on the compaction strategy (see below). The other main difference between major and minor compaction and that explain the naming difference is that a major compaction has a bigger impact in terms of I/O.

[Compaction] Strategy

As already said, Compaction will merge into SSTables into new ones. Depending on you use case, Cassandra propose different strategies to compact the data new SSTables.  There is a default strategy applied if you do not specify it but you can choose the one you want per table. There are 3 main compaction strategies.

Size Tiered [Compaction] Strategy

This is the default compaction strategy. It fits for the write heavy and general workload. More documentation here:
http://cassandra.apache.org/doc/latest/operating/compaction.html#size-tiered-compaction-strategy

Leveled [Compaction] Strategy

This compaction strategy fits perfectly for read heavy workloads. This strategy involves a bit more I/O than the Size Tiered Compaction. It can be a good idea to combine that with SSDs. More documentation here:
http://cassandra.apache.org/doc/latest/operating/compaction.html#leveled-compaction-strategy

Time Window [Compaction] Strategy

This compaction strategy fits perfectly for time series. Basically the data is compacted regarding the timeMore documentation here:
http://cassandra.apache.org/doc/latest/operating/compaction.html#timewindowcompactionstrategy-operational-concerns

A good blog blog post which deep dive into it:
https://thelastpickle.com/blog/2016/12/08/TWCS-part1.html

Validation [Compaction]

This one is a fake friend from my point of view. It's considered as a compaction but is not really about compaction. The validation compaction is the process of building Merkle tree on nodes during a repair. It's anyway called validation compaction because this action is anyway controlled by the  

compaction_throughput_mb_per_sec  parameter. 

Anti[Compaction]

The anti compaction occurs during incremental repair. The goal is to split into two SSTables the repaired data from the unrepaired data. The 2 sets of data can no longer be compacted together and it's why it's called anticompaction.

Conclusion

Hopefully you get now a better vision of what means compaction regarding the context it's used into the Cassandra world.

Une Cassandra/Spark Lan party à Devoxx France

Il y aura cette année (2016) à Devoxx France un hands-on particulier :

Une Cassandra / Spark Lan Party

Cet évènement aura lieu le vendredi 22 Avril (le dernier jour de Devoxx France) 

de 11:00 à 13:40 en salle Neuilly 231-232M Lab

http://cfp.devoxx.fr/2016/talk/YVP-4476/Cassandra%2FSpark%20Lan%20Party

Avec Thomas, nous avons été sélectionné pour organiser cet évènement et Amira et Gautier se joignent à l'équipe pour nous filer un coup de main. Merci à eux!

J'ai eu la chance de pouvoir participer à l'organisation de la Cassandra Lan party à Devoxx France en 2012, lors de la première édition. Nous avions réussi à créer un cluster Cassandra de 36 noeuds avec les machines des participants. Si vous voulez en savoir plus, le récit de cette précédente édition se trouve ici : http://www.unchticafe.fr/2012/04/histoire-dune-cassandra-lan-party.html

C'est quoi une Cassandra / Spark Lan party?

Cette fois-ci nous reprenons le concept initial de la Cassandra Lan party : 

- Créer un réseau avec les machines des participants 

- Créer un cluster Cassandra

- Manipuler des données sur le cluster

- Jouer avec le cluster

et en y rajoutant :

- Créer un cluster Spark

- Executer des jobs Spark sur le cluster

- Exécuter des jobs Spark sur le cluster qui jouent avec le cluster Cassandra

Si vous venez à Devoxx France et souhaitez découvrir Cassandra et Spark par la pratique, cet évènement est fait pour vous. 

Pourquoi y participer?

- Parce que vous ne connaissez pas Cassandra

- Parce que vous ne connaissez pas Spark

- Parce que vous ne connaissez pas Cassandra et Spark

- Parce que vous connaissez Cassandra
- Parce que vous connaissez Spark
- Parce que vous connaissez Cassandra et Spark

- Parce qu'une Lan party c'est fun.
- Parce qu'il y a un record du monde de 36 noeuds à battre
- Parce que vous voulez faire partie de l'histoire

Ok je m'emballe.

De quoi avez-vous besoin?

- votre ordinateur portable
- un Jdk 1.8 d'installé si vous voulez gagner du temps
- l'adaptateur ethernet de votre ordinateur (comme pour les Mac Book Pro récents par exemple...). Nous n'utiliserons pas de wifi mais un réseau filaire qui sera créé pour l'occasion.
- un cable RJ45 si vous en avez un
- votre bonne humeur

Pour le reste, on s'occupe de tout! Les valises sont prêtes.

A Vendredi!

Amira/Gautier/Thomas/Jérémy

Histoire d'une Cassandra Lan Party à Devoxx France

Genèse

Tout commença par un coup de fil de Nicolas Romanetti. un soir du début du mois de Mars.  

J'avais appris le mois précédent que mon Tool In Action sur cassandra-unit n'avait pas été retenu. Rien d'étonnant quand on voit la qualité des sujets qui ont été retenus.

Nicolas, lui, avait proposé 2 talks sur Cassandra : 

- le premier au format University : "Introduction à Cassandra". L'idée est de balayer sur 3 heures tous les concepts de Cassandra en prenant bien le temps du question/réponses mais dans un format très théorique basé sur des slides.

- le second au format Labs : "Hands On Cassandra". Ce "Hands On" devait initialement permettre aux participants de manipuler un peu cassandra "dans son coin" sur son poste.

Ces deux talks ont été sélectionnés (et se suivent sur la même journée, 2x3H). C'est ça les rockstars :-).

Histoire d'un coup de Fil :

N : Salut Jérémy, dis moi, je ne sais pas si tu as vu mais mes 2 talks ont été sélectionnés.

moi : oui énorme, c'est cool, les participants qui le souhaitent pourront faire une journée complète sur Cassandra!

N : J'ai besoin d'aide sur le Hands On, ça te dirait de me filer un coup de main?

moi : un coup de main comment?

N : Pour le Hands On, j'ai une idée, j'ai envie de changer légèrement le contenu, c'est ok avec les organisateurs mais il me faut une équipe. J'ai envie de faire une Lan Party.

Moi : Comme celle qui a eu lieu à NYC?

N : Yes

Moi : BANCO! C'est parti pour une Cassandra Lan Party à Devoxx France.

Lui : Tu es où toi?

Moi : sur Lille et toi?

Lui : Ajaccio ;-)

C'est comme ça qu'on se retrouve dans le même bateau, Nicolas, Florent, Sylvain et moi.

Il y aura donc une Cassandra Lan Party à Devoxx France :

- http://www.jaxio.com/2012/03/21/cassandra-party-devoxx-france.html

- http://www.devoxx.com/display/FR12/Hands+on+Cassandra

Préparation

On en maintenant mi-mars. Devoxx, c'est quand même dans un mois. Alerte générale!

On échange pas mal entre nous par mail et sur un petit google doc partagé. Le point noir, c'est le réseau, la seule façon pour que ça se passe sans problème, c'est de ne pas compter sur celui de Devoxx et donc c'est de venir avec à Devoxx. "Qui a des switchs? Heu... Personne... ". Tout le reste n'est que de la préparation et du détail (ou presque ;-)). Pas de switchs, pas de Cassandra Lan party! On lance alors un appel à la population.

Nous n'avons pas eu tant de retour que ça mais des retours gagnants! :

- Euratechnologies répond OK et nous prête 3 switchs professionnel 24 ports en gigabit neuf ainsi qu'une quarantaine de câble RJ45 de différentes longueur!

- Thomas Recloux, un ami un peu geek ;-), me prête aussi son switch personnel (enfin pro ;-)) de 24 ports en gigabit neuf.

Côté matériel, c'est tout bon.

En parallèle nous contactons Jake et Edward, les organisateurs de la Cassandra Lan Party de NYC, pour avoir leur feedback. Pour faire simple : c'était fun mais la génération et l'attribution du token n'a pas fonctionné comme ils le voulaient

Hey mais nous sommes début Avril! Alerte générale!

L'idée émerge alors dans nos esprits de faire une application web pour aider les participants à récupérer leur token et configurer leur noeud cassandra. L'application web de la cassandra-lan-party, vient de naitre, 2 nuits pour coder ça en équipe, un peu de spring-mvc, de twitter bootstrap et hop. Nous mettrons prochainement les sources à disposition.

De mon côté, je récupère le matériel et je fais des tests (je ne vous raconte pas comment madame était contente de voir ça dans le salon :-)) : 

On peaufine aussi les slides.

Tiens si on se faisait un tee-shirt, ça aiderait les participants à nous identifier plus facilement s'ils ont des problèmes :

Répétition

Il n'y a pas de secret, il faut répéter! Ca nous permettra accessoirement de nous rencontrer IRL ;-)

Nicolas organise la semaine précédent Devoxx France, une répétition chez Zenika. 

C'est parti pour Paris, mais tiens, c'est vrai, il faut transporter tout le matériel réseau... : 

Est-ce que la valise va fermer?

Voici le récit de la répétition ainsi que les photos.

Nous avons mis en place 18 noeuds Cassandra sur différent OS sur 3 Datacenters.

Pour la petite anecdote, Tout le monde arrive progressivement pour la répétition, Je dis bonjour à plein de participants. On commence à s'installer et je dis à un moment à Nicolas, "On attend Florent pour commencer?" et là j'entend une voix qui répond derrière moi "ben je suis là". Moment de solitude ;-)

Nous avons pas mal de feedbacks intéressants et avons la confirmation qu'une application web pour aider les participants à récupérer leur token et configurer leur noeud cassandra est une très bonne idée, on nous donne même des idées de feature en plus. Merci Brice. C'est l'heure de recoder un peu dans l'application web et modifier les slides :-).

The D Day

Le matin, Nicolas a fait un super talk sur Cassandra. Simple, clair, précis et efficace. De très bon échange avec le public. Voici les slides.

Mais c'est maintenant déjà l'heure du Hands On!

Dans un premier temps, nous avons eu la chance d'avoir la salle du Hands On en avance. C'était d'ailleurs assez drôle de voir les serveurs préparer la salle avec des petits napperons, des verres et des bouteilles d'eau avec les tables et les chaises bien alignées avant que nous en prenions possession :-). Une fois la salle à disposition, hop, on enlève tout, on bouge tout pour constituer 3 zones avec les tables pour représenter physiquement 3 datacenters avec les chaises dans tous les sens, bref une Lan (merci Thomas pour le coup de main lors de la mise en place!)

La Cassandra Lan party s'est déroulée en 3 étapes :

- installation/configuration du réseau

Tout les participants se branchent par datacenter sur un switch. On note les IPs sur des Post-its. Un slide explique la conf réseau à effectuer ainsi que des tests pour vérifier que tout est ok.

- installation/configuration de Cassandra

Des clés USB sont distribuées. Il est possible d'installer Cassandra soit par les clés USB soit en la téléchargeant depuis notre application web. Les slides expliquent le paramétrage à effectuer... 

L'application Web fournit le token et précise les éléments de configuration à modifier dans Cassandra :

- démarrage et exécution de différents scénarios sur le cluster

Voici les caractéristiques du cluster cassandra :

• 3 datacenters.
• Utilisation du RackInferringSnich
• 3 seeds (un par DC)
• Replication Factor de 9 (3 par DC).

Nous avons démarrer dans un premier temps les 3 seeds (Sylvain, Florent et moi) puis dans un second temps nous avons démarrer progressivement tous les autres noeuds.

Et là, problème, les noeuds cassandra sur les machines windows ne veulent pas rejoindre le cluster, merci windows et à son firewall ;-). Une fois le firewall coupé, tout le monde arrive à rejoindre le cluster.

Notre cluster est constitué de 36 noeuds. D'un point de vue de l'équipe, on sait déjà qu'on a remporté notre   pari. Le reste n'est que formalité ;-).

Nous avons mis en place un cluster Cassandra de 36 noeuds réparti sur 3 datacenters sur tout type d'OS.

La Cassandra Lan party de NYC est battue :-)

C'est maintenant l'heure de jouer avec le cluster.

Par l'intermédiaire de nodetool, les participants interrogent l'état du cluster et par l'intermédiaire de cassandra-cli, ils écrivent et lisent dans le keyspace créé pour l'occasion. Nous faisons d'abord tombé et revenir un DC puis nous faisons tomber et revenir 2 DCs. Les participants constate en live comment le cluster réagit... Bref, facile, c'est Cassandra, c'est fait pour ça :-)

- un peu de théorie pour terminer

Après une petite pause, les questions commencent à arriver en nombre et c'est le moment de repartir sur quelques slides pour pouvoir y répondre : le datamodel, le ring, le partitioner avec le token, le replication factor, le consistency level, tout y passe. Nicolas était bien au point après l'university du matin!

Toutes les photos de la Cassandra Lan Party sont ici

Les slides utilisés sont ici

Le mot de la fin

Les objectifs étaient que les participants :

- mettent les mains dans le cambouis!

- constatent que Cassandra, ça n'est pas compliqué!

- s'amusent!

Je ne suis pas très objectif justement mais je pense que nous ne sommes pas loin de les avoir tous atteints!

Pour ma part :

- ça a été super fun.

- l'ambiance était décontractée et conviviale.

- une valise de 40kg à trimballer, c'est lourd!

Merci à tous les participants de s'être prêté au jeu!

Cassandra Lan Party : We need you!

La nouvelle est tombée hier : il y aura une Cassandra Lan Party à Paris à Devoxx! Elle aura lieu pendant le Hands On Cassandra (la description du Hands On est en cours de mise à jour).

Nicolas, Florent, Sylvain et moi vous aiderons et vous accompagnerons lors de cette session.

Comment??? Vous étiez passé à côté de cette News??? Pourtant la terre a dû s'arrêter de tourner au moins pendant 2 secondes :-).

Une Cassandra Lan Party, c'est quoi?

Vous souvenez-vous des Lan Party Counter Strike ou Quake que vous faisiez dans votre garage ou dans un immense hangar quand vous étiez plus jeunes (ou que vous faites encore ;-))? 

(ok, nous serons beaucoup moins nombreux) 

L'idée de reprendre tous les ingrédients de ce type d'évènement plutôt fun, convivial et participatif et de l'appliquer à Cassandra.

Tous les détails de l'évènement se trouve sur le blog de Jaxio.

We need you!

Nous allons recréer un réseau ethernet pour l'évènement. 

Nous lançons donc un appel général pour que cet évènement puisse se réaliser : 

Nous sommes à la recherche de matériels réseaux à prêter pendant une quinzaine de jours :

- 3 gros switchs ethernet (20 ports mini par switch) en gigabit.

- des cables RJ45 de différentes tailles (3 mètres mini).

Nous faisons donc appel à vous, si vous avez ce type d'équipements et que vous souhaitez nous le mettre à disposition, nous en prendrons grand soin! Nous ne manquerons pas non plus de vous remercier pendant le Hands on!

Si vous n'avez pas ce type d’équipements, n'hésitez pas à en parler autour de vous!

Vous pouvez me contacter par mail à jsevellec at gmail dot com ou sur twitter @jsevellec

A bientôt à Devoxx!

CassandraUnit : un outil Dev & Ops!

CassandraUnit est un framework permettant de vous aider à développer des applications Java basé utilisant Cassandra.

Depuis la version 1.0.1.4, C'est maintenant un outil à la fois Dev & Ops, car il peut vous accompagner dans toutes les phases de votre projet :

Un outil @Dev:
CassandraUnit est initialement né de la volonté de vouloir faire du TDD en testant aussi la persistance dans Cassandra. Le but était de répondre à 2 problématiques : 

• Comment développer un service de lecture de données dans Cassandra en faisant du TDD sans avoir de cluster Cassandra?
• Comment faire en sorte que mes tests unitaires soient portables et isolés pour pouvoir faire de l'intégration continue?

L'idée directrice était de proposer un environnement au niveau des tests unitaires qui permettent avant leur exécution :

• de démarrer une instance embarquée de Cassandra.
• de remplir cette instance avec un keyspace et des données.

Comment ça marche ?

Il faut dans un premier temps définir votre dataSet, C'est le jeu de données qui sera inséré dans Cassandra pour votre test unitaire.

CassandraUnit vous permet selon votre préférence de définir un dataSet au format XML, JSON ou Yaml ( plus d'infos ici)

Il faut ensuite l'intégrer au niveau de votre test ou de votre code. Il est possible de faire ça de plusieurs manières :

• soit de manière native en manipulant l'APIs (donc pas forcément dans un test) : 

EmbeddedCassandraServerHelper.startEmbeddedCassandra();
DataLoader dataLoader = new DataLoader("TestCluster", "localhost:9171");
dataLoader.load(new ClassPathJsonDataSet("simpleDataSet.json"));

• soit par héritage au niveau de votre classe de Test :

public class yourTest extends AbstractCassandraUnit4TestCase {

    @Override
    public DataSet getDataSet() {
        return new ClassPathJsonDataSet("simpleDataSet.json");
    }

    @Test
    public void shouldHaveLoadASimpleDataSet() throws Exception {
        assertThat(getKeyspace(), notNullValue());
        /* and query all what you want */
    }

}

• soit sans héritage! merci Junit @Rule

public class SecondaryIndexWithRuleTest {

    @Rule
    public CassandraUnit cassandraUnit = new CassandraUnit(new ClassPathJsonDataSet("simpleDataSet.json"));

    @Test
    public void shouldHaveLoadASimpleDataSet() throws Exception {
        assertThat(getKeyspace(), notNullValue());
        /* and query all what you want */
    }

}

Un outil @Ops
Depuis la version 1.0.1.4, CassandraUnit propose un outil en ligne de commande multi OS : le "cu-loader".

Cet outil en ligne de commande permet de réutiliser vos dataSets pour créer vos keyspaces et/ou charger vos données dans d'autres cluster Cassandra que votre instance de Cassandra embarquée en @Dev.

L'outil permet de réutiliser les dataSets sans les modifier mais avec la possibilité de surcharger certaines déclaration liées à la configuration du cluster Cassandra (comme le replication factor, la stratégie, ...).

L'objectif de l'outil est d'éviter d'introduire des erreurs liées au changement d'environnement en créant un keyspace qui ne correspondrait au keyspace utilisé en développement.

CassandraUnit est diponible sous forme de distribution téléchargeable depuis github ici ainsi que sur le repo central maven. Il suffit donc de le décompresser et de rajouter

Voici ce que ça donne à l'utilisation :

> cu-loader
Missing required options: f, h, p
usage: CassandraUnitLoader is a tool to load CassandraUnit data Set into cassandra cluster
 -f,--file <arg>                dataset to load
 -h,--host <arg>                target host (required)
 -o,--onlySchema                only load schema (optional)
 -p,--port <arg>                target port (required)
 -r,--replicationFactor <arg>   override the replication factor set in the dataset (optional)
 -s,--strategy <arg>            override the strategy set in the dataset (optional)

Un exemple simple :

> cu-loader -f datasetDefaultValue.xml -h localhost -p 9160

Un exemple complet :

> cu-loader -f datasetDefaultValue.xml -h 10.10.10.01 -p 9160 -o -r 3 -s org.apache.cassandra.locator.NetworkTopologyStrategy

Vous trouverez plus de détails dans le doc ici

Voici des liens qui pourront vous être utile si vous voulez aller plus loin :
- github : https://github.com/jsevellec/cassandra-unit/
- mailing list : https://groups.google.com/group/cassandra-unit-users?hl=fr
- twitter : https://twitter.com/cassandraunit

Bref. Un bel outil. :-)

Cassandra pour les développeurs Java

Hier soir, au Ch'ti JUG il y a eu une double session sur NoSQL.

Steven Noels a présenté en première partie Lily,  une solution d'indexation basé sur HBase.
En deuxième partie, j'ai effectué une présentation de "Cassandra pour les développeurs Java" où j'y ai abordé les principaux concepts de Cassandra, présenté Hector et cassandra-unitl e tout avec un peu de live coding.

Voici les slides de cette présentation :

Cassandra pour les développeurs java

 

View more presentations from jsevellec

Ça a été une bien belle soirée et un after bien sympa et convivial :

@bientôt à une autre session du Ch'ti Jug!

Cassandra : Les problématiques à traiter lorsqu'on développe une application java

Cassandra fait parti de la famille des bases de données NoSQL. C'est une base de données dont on entend de plus en plus parler dès que l'on est confronté à devoir gérer de gros volumes de données, à être très performant et à vouloir monter en charge facilement.

De part sa conception, Cassandra a été nativement pensé pour être hautement distribué, hautement performant et avec une forte capacité de montée en charge. 

Cassandra est une très belle implémentation du modèle p2p. Tous les noeuds au sein d'un Cluster Cassandra ont le même rôle. Il n'y a pas de notion de maître/esclave...

Bref, Je ne vais pas vous énumérer les avantages à utiliser Cassandra car d'autres l'ont déjà très bien fait avant moi. Vous trouverez sur le wiki de Cassandra un ensemble de liens vers des présentation qui  décriront les concepts clés autour de Cassandra. Juste un dernier mot pour vous dire que Cassandra va bientôt sortir en v1.0.

Une fois votre choix arrêté : "ok, on part sur Cassandra", quelles sont les problématiques auxquels vous allez être confronté lors de sa mise en oeuvre? Je vais tenter d'apporter quelques réponses... C'est parti!

Design de votre modèle de données :

Une des premières choses à faire quand on commence à travailler avec Cassandra, c'est d'oublier tout ce qu'on vous a dit et ce que vous faisiez avec une base de données relationnelle : Le maître mot est dénormalisation.

Cassandra propose un modèle orienté "Column Family" inspiré par BigTable de Google. Je vous conseille dans un premier temps de bien comprendre le modèle de Cassandra (Keyspace, ColumnFamily, Column, SuperColum, Counter) avant de vous lancer. La documentation de DataStax sur le sujet ainsi que l'article sur le wiki sont un bon point départ.

Une fois le modèle de Cassandra compris, il faut axer la réflexion sur la façon dont vous allez requêter vos données. Le système de requêtage de Cassandra est limité (pas de jointures par exemple...). Il faut donc commencer par là pour être sûr de pouvoir faire ce que l'on veut faire.

Installer et paramétrer un cluster Cassandra

La force de Cassandra est de fonctionner avec un grand nombre de noeud dans un cluster. Le plus gros cluster dont j'ai entendu parler (dans cette interview de Jonathan Ellis) serait constitué de 400 noeuds... Juste énorme. Sans aller jusque là, il faut malgré tout rapidement vous familiariser avec le fonctionnement et l'administration d'un cluster Cassandra. Bref, il faut mettre les mains dedans. Je vous conseille cet article, cette video ou encore cette documentation DataStax décrivant la mise en oeuvre rapide d'un cluster cassandra. Cassandra fonctionne aussi en Single Node, cela peut toujours servir en terme de développement mais j'y reviendrai plus tard.

Il vous faut aussi comprendre le fichier de configuration principal de chaque noeud Cassandra : cassandra.yaml. Voici sa documentation.

Si vos serveurs acceptent le packaging Debian, Je vous conseille fortement d'utiliser celui proposé par Cassandra. Il vous permettra très rapidement de l'installer et surtout de le mettre à jour facilement!

Il faut aussi un peu de moyens... Pour pouvoir faire des tests sur votre cluster, il faut un environnement machines permettant de mettre en valeurs les capacités de Cassandra. Cela permet aussi pour vous rassurer avec des tests de performances valables avant d'arriver dans un environnement de production. La virtualisation de plusieurs noeuds sur un ("petit") serveur ne permettra pas de faire des tests de performances concluants.

Administrer et monitorer un cluster Cassandra

Cassandra fournit nativement un ensemble d'outils permettant d'administrer votre cluster :

• cassandra-cli : c'est l'utilitaire en ligne de commande permettant de lire/ecrire dans votre cluster
• nodetool : c'est l'utilisaire en ligne de commande permettant de monitorer et administrer les noeuds du cluster

En plus de ça, DataStax propose une application Web de monitoring et d'administration de votre cluster Cassandra : OpsCenter. C'est vraiment un superbe outil. Il y a une version gratuite pour le développement. J'ai cru comprendre (mais je me trompe peut être) qu'il y aura bientôt aussi une version production gratuite mais qui ne l'est pas pour le moment.

Gérer le "Eventuellement Consistant"

Cassandra propose un modèle "Eventuellement Consistant". Ces mots doivent normalement mettre la puce à l'oreille à n'importe quel développeur et faire un peu peur. 

Pour faire simple, selon le théorème CAP, il n'est pas possible d'avoir à la fois de la consistance (Consistency) , de la disponibilité (Availability) et une résistance au morcellement (Partition tolerance). Il n'est possible que d'en avoir 2 sur 3. Cassandra a choisi de mettre l'accent sur le "A" et le "P" et d'offrir la possibilité de choisir son niveau de consistance. Il est donc possible d'avoir un consistance forte avec Cassandra mais au détriment d'une dégradation du temps de latence (car il faut demander à plus de noeud dans le cluster de se mettre d'accord sur la valeur d'une donnée lors d'une lecture par exemple).

Il y est donc possible de choisir parmi plusieurs niveaux de consistances. Voici une documentation sur le site de DataStax sur le sujet pour vous guider dans votre choix.

Lock

Cassandra ne sait pas faire de Lock. C'est un inconvénient lié à son architecture. Il ne permet donc pas d’empêcher plusieurs clients de lire ou d'écrire un ensemble données portant sur les mêmes clés de votre modèle au même moment. Ce qui peut être fortement gênant, il ne faut pas le nier... Dans ce cas : "la réponse est ailleurs".

Il n'est pas impossible de faire du lock sur vos données mais en utilisant un système externe qui va gérer cela. Zookeeper va vous permettre de faire cela. C'est un système de synchronisation distribué de type sémaphore qui va vous permettre de faire des locks. Zookeeper n’entraîne pas de SPOF car il fonctionne aussi en cluster. Cage est une libraire Java qui s'appuie sur zookeeper et propose un système de lock basé sur des chemins. Voici un article qui vous explique en détail son utilité pour compléter l'utilisation de Cassandra. 

Transaction

Ok, vous faites du lock mais lock ne veut pas dire transaction... Cassandra assure une atomicité des données au niveau d'une même clé (même dans des columnFamily différentes). En revanche, comment faire si vous avez besoin d'une atomicité de données sur plusieurs clés car vos données sont fortement couplés et que vous ne pouvez pas faire autrement.

La réponse est "Just do it (yourself)". Une des approches est de mettre en oeuvre un système de transaction log dans une columnFamily dédiée. Le principe est donc : 

• de logger la transation en sérialisant les données qui ont besoin d'être atomiques (json, xml, ...) et en insérant le résultats de la sérialisation en une fois dans une colonne d'une columFamily.
• effectuer votre traitement en insérant vos données dans votre modèle.
• de marquer ou supprimer la log de la transaction une fois le traitement terminé.

Ce système vous donne alors la possibilité de rejouer la log de la transaction si un souci est survenu pendant votre traitement. Ce système est abordé dans cette présentation (à partir du slide 24).

Comment dialoguer avec Cassandra

Cassandra expose toute son Api cliente via Thrift. L'utilisation native de thrift est déconseillée car c'est plutôt une Api de bas niveau s'adressant à des clients développeur plutôt qu'à des applications clientes.

Il faut donc choisir votre client pour vous adresser à Cassandra : Ils sont listés ici.

En java, il en existe plusieurs. Hector semble clairement le plus utilisé et le plus configurable. C'est celui que j'utilise.

Environnement de développement

Si vous utilisez maven, la plupart des librairies dont vous avez besoin sont mavenisées et disponibles dans les repository centraux (l'exception est Cage qui nécessite de déclarer un repository spécifique).

Vous aimez faire des tests unitaires et du TDD, pas de problèmes, c'est possible et ça se fait même très bien. Il est possible de lancer Cassandra et Zookeeper de façon "embedded" dans votre JVM.

Il est même possible si vous le souhaitez de lancer Cassandra de façon embarquée et d'y charger des données avant d’exécuter vos tests unitaires. Je vous propose d'aller jeter un oeil du côté de cassandra-unit si vous souhaitez faire ça.

Ecosystème en évolution permanente

Que ce soit sur les fonctionnalités de Cassandra, son outillage, son écosystème, il y a beaucoup de changements, d'évolutions et d'améliorations.

De grosses et nouvelles fonctionnalités apparaissent constamment. Par exemple, il y a quelque mois, entre la version 0.7.8 et la 0.8.0, un langage de requêtage le "CQL" est apparu et très prochainement Cassandra sort en version 1.0... Ça va très vite.

Il faut globalement rester en veille sur les blogs, twitter, les mailing list (Cassandra et Hector par exemple) pour voir ce qui se fait, ce qui sort. La communauté autour de Cassandra est grossissante et est très réactive.

Ne pas avoir peur de défaire
Comme les choses changent et évoluent, Il ne faut pas avoir peur de jeter un peu, de modifier souvent, de refactorer beaucoup votre code. C'est dû soit à une évolution de compréhension de Cassandra qui vous fait dire qu'il faut mieux faire autrement, soit à l'apparition d'une nouvelle fonctionnalité soit à un lecture sur un blog...

Il n'y a pas de secret, ma meilleure arme pour gérer ses changements sont : mes tests unitaires et mes tests d'intégrations et ça se passe bien!

Pour aller plus loin

Vous pouvez aller jeter un oeil dans le code source de Cassandra sous svn ici ou sur le miroir sous Git ici.

Vous pouvez aller lire la documentation sur le wiki sur l'architecture interne de Cassandra ici et voir cette vidéo.

Vous pouvez contribuer en commençant ici.

Pour Conclure

Utiliser Cassandra comme backend pour stocker vos données à un réel impact sur votre façon de développer votre application. C'est quelque part assez normal dans le sens si vous utilisez Cassandra, c'est que vous avez normalement beaucoup de données à gérer et qu'il faut de toute façon obligatoirement prendre ça en compte pour développer votre application...

Une fois les efforts produits, quel plaisir de rajouter un noeud dans le cluster pour monter en charge...

En fait, Cassandra, c'est très "DevOps" :-).