Un screencast de shell un peu comme showterm (http://infomee.fr/links/?SbD6og)

Slides du meetup d'hier soir :

http://fr.slideshare.net/ClmentLARDEUR/deep-into-cassandra-data-repair-mechanisms#

Le 17 décembre à 18h30, Xebia accueille dans ses locaux le Cassandra Paris Meetup. Dans cette troisième édition seront abordés :

• Une présentation détaillée des mécanismes internes de réparation des données fournit par Cassandra (hinted handoff, read repair, nodetool repair, ...) par Clément Lardeur ;

• Un retour d'expérience sur l'optimisation de performances sur un modèle clé/valeur avec Cassandra (key cache, row cache, ...) par William Montaz.

Mécanismes internes de réparation des données

Cassandra propose un certain nombre de fonctionnalités intégrées de réparation afin de s'assurer que les données restent cohérentes à travers les différents noeuds du cluster. Ces mécanismes de réparation sont les suivants :

• Read Repair - Mécanisme activé par défaut se déclenchant lors d'une lecture afin de réparer d'éventuelles incohérences de données entre les replicas ;

• Anti-Entropy Repair Node - Mécanisme qui permet de réparer les incohérences de données d'un noeud complet et de ses replicas. La commande nodetool repair doit être executée dans certaines situations (opérations de maintenance, redémarrage d'un noeud après une panne, ajout d'un noeud, ...) ;

• Hinted Handoff - Mécanisme activé par défaut se déclenchant lors d'un échec d'écriture sur un des noeuds. Le coordinateur enregistre cette écriture afin de la rejouer lorsque le noeud sera de nouveau disponible.

Cette présentation a donc pour but d'expliquer le fonctionnement de ces 3 mécanismes, en partant de leurs fonctionnements globaux, jusqu'à leurs implémentations techniques, afin de comprendre quand et comment les utiliser.

Speaker : Clément Lardeur (45 min)

REX : Optimisation de performances sur 2 exemples

Cassandra est une base de données très performante. Pourtant, nous n'arrivons pas toujours à en tirer immédiatement le maximum. Loin de prétendre que nous avons poussé Cassandra dans ses ultimes retranchements, ces deux retours d'expérience pourront vous servir d'inspiration pour tirer le meilleur parti de votre cluster Cassandra.

• Twenga : Optimisation d'un automate de real time bidding. Lorsqu'un utilisateur se loggue sur un site disposant d'un bandeau publicitaire, le fournisseur de l'espace publicitaire propose aux annonceurs un espace de pub pour un utilisateur à un moment précis dans le temps. Les annonceurs proposent alors leur enchère. La meilleure, à la fin du temps imparti, remporte l'enchère au tarif du second plus offrant. Les réponses doivent être fournies en moins de 80ms. Pour cibler correctement les espaces publicitaires, twenga stocke des informations sur les urls cibles sous la forme clé/data.

• Optimisation d'un batch de calcul de prix. Une utilisation de Cassandra sous la forme "wide row". La problématique dans ce cas particulier : peu de clés requêtées en simultané mais un volume de données important à faire transiter.

Au programme :

• Les caches,

• Les bloom filters,

• Le commitlog,

• La JVM,

• Le sharding,

• Le driver java Datastax.

Speaker : William Montaz (45 min)

exemple de split file avec awk

Pratique
Génère en inline en plus, donc plus condensé

chat chiffré coté client

via sebsauvage

to check

Logstash c'est bien.

En fait c'est mieux avec ses deux copains : elasticsearch et kibana !

Logstash permet de :
1) récupérer "des choses" (parmi des input, comme par exemple des logs),
2) de les traiter (par exemple, appliquer des regex pour récupérer des champs),
3) de balancer la structure obtenue après traitement "quelquepart" (il existe des tas d'output, par exemple : elasticsearch)

Une fois que vous avez ça en place, vous pouvez visualiser vos données stockées dans elasticsearch avec kibana! (et ça donne ça : http://www.elasticsearch.org/overview/kibana/)

Sympa pour exploiter des access.log par exemple :)

Sympa le one-click to broadcast !

Comment passer en prod une app django