Introduction

A OCTO, nous suivons depuis quelques années déjà l’évolution de la base NoSQL Apache Cassandra. La sortie de la version 1.2 en janvier 2013 nous donne l’occasion de faire le tour d’horizon des évolutions récentes du produit. En résumé, on observe récemment une amélioration de l’expérience d’utilisation de Cassandra grâce à une simplification de la modélisation des données, du requêtage et de l’administration pour les opérationnels. Le tout en gardant les fondamentaux de la solution à savoir les performances, la disponibilité et la scalabilité.

(Lire la suite…)

Cette partie se concentre sur la partie client et présente des exemples de code Java permettant de manipuler les concepts métiers définis dans la partie précédente.

Bien que les APIs Cassandra soient disponibles dans plusieurs langages, concentrerons nous sur l’API Java.
(Lire la suite…)

Cette partie aborde plus en détail la configuration de Cassandra. L’idée est d’implémenter une gestion des comptes simplifiée où un utilisateur à un compte, le compte a un solde…
Le système manipulera donc les concepts suivants :

• Un client (Customer), défini par plusieurs propriétés
• Un client a un compte (Account)
• Le compte a une liste d’opérations (retrait, transfert sont des types d’opérations)

(Lire la suite…)

Je l’avais déjà évoqué mais NoSQL parle de diversité et regroupe une grande diversité d’outils. Cassandra est l’un d’entre eux et est certainement le plus populaire de l’écosystème NoSQL. Initié par Facebook est actuellement en production chez des grands du web comme Digg ou Twitter, Cassandra est une solution hybride entre Dynamo et BigTable.

Hybride tout d’abord parce que Cassandra utilise une modélisation « Column-oriented » de la donnée (inspiré par BigTable) et permet d’utiliser Hadoop et Map/Reduce. Ensuite parce que Cassandra utilise des patterns issus de Dynamo comme « Eventually consistent », « Gossip protocols », une approche Master-Master des requêtes d’écriture et de lecture…
Un autre gène de Cassandra (et en fait de beaucoup de solutions NoSQL) est que Cassandra a été pensé et construit pour être complètement décentralisé, gérer de façon transparente (au maximum) la perte d’une partie du Cluster, fonctionner entre plusieurs Datacenter (il est possible de configurer Cassandra de manière à s’assurer que la donnée est répliquée entre plusieurs Datacenter…).

C’est ainsi que Cassandra est utilisée entre les Datacenter Facebook des côtes est et ouest des USA pour stocker (il y a déjà 2 ans) plus de 50+ TB de données réparties sur un cluster de 150 nœuds.

(Lire la suite…)

La présentation de Sylvain Lebresne sur Cassandra lors du dernier noSql User Group @Paris était excellente, encore bravo a Sylvain.
Si bien qu’en bon geek, j’ai voulu essayer tout de suite, ce qui m’a encore valu une courte nuit de sommeil.
Conclusion : si vous voulez faire tourner Cassandra en dix minutes, voila comment faire…
(Lire la suite…)

Vu les speakers annoncés, no:sql(eu) à Londres était très prometteur mais c’était sans compter sur mère nature et ce fameux volcan islandais qui allait bloquer l’espace aérien d’Europe du nord…Malgré tout, no:sql(eu) est resté disponible et a offert un mode de fonctionnement « graceful degradation ». Un mode finalement efficace puisque quelques speakers ont réalisé leur présentation via Skype, principalement depuis les USA (quelques fois très tôt à cause du décalage horaire). Cela a également été l’occasion de discuter avec le CTO d’Amazon : Werner Vogels.

Quoiqu’il en soit, voilà ce que j’ai envie de retenir.
(Lire la suite…)