CASSANDRA est de la famille des SGBD dit «NoSQL». L’abandon de certains dogmes et le choix du compromis où les données ne sont plus liées de manière relationnelle (clef primaire / clefs étrangères), ont permis de répondre efficacement aux besoins croissants et gourmands des mécanismes d’analyse de données massives et proposent par la même occasion, des architectures techniques scalables (Master to Master) et redondantes (Multi data-center).

Les bases de données NoSQL peuvent être de type document, graphe, colonne ou clés/valeurs. Ces solutions ont émergé sous l’impulsion de grosses entreprises du web qui ont vu exploser le volume de leur DATA : Twitter, Facebook, Amazon ou encore Google. CASSANDRA n’est qu’un maillon de la chaine dans l’architecture technique qui va permettre aux décisionnels de traiter, d’extraire et de faire parler les datas.

CASSANDRA peut être utilisé en cluster et offrir tout ce qu’un cluster a à offrir comme par exemple :

  • tolérance aux pannes,
  • mécanisme de «scalling» linéaire,
  • rapidité sur les écritures,
  • réplication simplifiée et bien d’autres choses encore

Dans un premier point, on abordera la structure de CASSANDRA pour bien comprendre comment sont enregistrées les données. Dans un deuxième point, on installera CASSANDRA et nous ferons nos premiers scripts PHP.

Structure de la base de données CASSANDRA ?

CASSANDRA est orientée colonnes, et cette approche peut laisser perplexe car on est dans un modèle dit «dénormalisé». Avant de rentrer dans le détail, listons quelques propriétés intéressantes :

  • le schéma est très flexible : comme MongoDB (orienté document), on n’a pas besoin de se soucier des champs adéquates dans nos requêtes. On peut, à la volée, ajouter ou supprimer des champs. Les mécanismes d’«INSERT» et d’«UPDATE» sont d’ailleurs les mêmes,
  • la représentation spatiale de la donnée (que nous expliquerons) permet de traiter un grand nombre de ligne,
  • une sélection par clés de manière ordonnée et clé/valeur (sous certaines conditions),
  • la scallabilité horizontale : les lectures et les écritures peuvent avoir lieu sur n’importe quels noeuds du cluster. Si on a besoin de plus de puissance, on rajoute simplement un serveur (gain linéaire),
  • »tunning» sur la cohérence et jouer sur la vitesse des écritures. CASSANDRA dans le modèle «Cohérence ; Disponibilité ; Partitionnement» a fait le choix de la haute disponibilité et du partitionnement. On va jouer sur le curseur de la cohérence pour que la donnée au sein du cluster soit «jugée» valide. Cela nécessite de définir une stratégie :
      En écriture :

    • «CL.NONE» pas de vérification (écriture très rapide mais aucune garantie que la donnée est bien présente sur l’ensemble des noeuds),
    • «CL.ONE» : Au moins 1 noeud valide la transaction,
    • «CL.QUORUM» : La moitié + 1 des noeuds du cluster concerné par le réplicat doivent répondre favorablement,
    • «CL.All» : tous les noeuds concernés par le réplicat (perte significative des performances en insert)
      En lecture :

    • «CL.ONE»,
    • «CL.QUORUM» : La moitié + 1 des noeuds du cluster concerné par le réplicat,
    • «CL.All» : tous les noeuds concernés par le réplicat (perte significative des performances en insert)
  • la réplication multi data-center est simple et il est possible de mettre en place une stratégie de réplication pour chaque espace de travail ou «keyspace».

Organisation des données dans CASSANDRA

Les données dans CASSANDRA sont organisées en colonne et s’articulent autour de 3 concepts principaux que nous allons aborder dans un certain ordre : du plus général au plus fin (la donnée). On tachera de faire une corrélation simpliste avec le modèle relationnel afin de bien comprendre l’organisation de cette structure dans CASSANDRA.

  • l’espace de nom ou «keyspace» est comparable au nom que l’on va donner à une base de données. Dans un cluster CASSANDRA, on peut définir plusieurs espaces de nom pour structurer son modèle et séparer ainsi, les organes métiers de son application. Les espaces de nom peuvent bénéficier d’une stratégie de réplication individualisée,
  • une famille de colonne ou «column family» représente la notion de «table» et appartiennent à un «keyspace». Le contenu de la «column family» est composé de tuples de type clés/valeurs. Chaque clé est unique et va permettre de récupérer du contenu qui est organisé en colonne.
  • la colonne ou «column» est la plus petite structure qui accueillera la donnée. Comme la «column family», elle est de type clé/valeur avec un champ de type TIMESTAMP géré par le cluster.

Exemple de représentation spatiale dans le contexte «keyspace» + «column family» + «colums»

Pour bien comprendre la structure de CASSANDRA, voici un exemple concret. Nous allons représenter une liste d’utilisateur identifiable par leur «uid» et un certain nombre d’informations à leur sujet comme par exemple :

  • le «nom»,
  • le «prénom».

Ci-dessous le code PHP qui permet de faire la création de notre référentiel, de jouer les «INSERT» et le «SELECT». On reviendra sur l’installation des librairies adéquates pour exécuter correctement ces scripts PHP. La figure 1 ci-dessous est une capture d’écran du résultat du code et liste l’ensemble des utilisateurs enregistrés dans la «column family» «users» pour le «keyspace» «mytest»

<?php
// Connecteur PDO_CASSANDRA
$db = new PDO('cassandra:host=127.0.0.1;port=9160');
$db->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
$db->setAttribute(PDO::ATTR_DEFAULT_FETCH_MODE, PDO::FETCH_ASSOC);

// Création de l'espace de travail
$db->exec ("CREATE KEYSPACE mytest with strategy_class = 'SimpleStrategy' and strategy_options:replication_factor=1;");

// Utilisation
$db->exec ("USE mytest");

//création de la column family
$db->exec ("CREATE COLUMNFAMILY users (uid varchar PRIMARY KEY, name varchar, last_name varchar);");

//insertions
$request = $db->prepare ("INSERT INTO users (uid, name, last_name) VALUES (:id, :name, :last_name);");
$request->execute (array (':id' =>'xbgf12kj', ':name' => 'stéphane', ':last_name' => 'raymond'));

$request = $db->prepare ("INSERT INTO users (uid, name, last_name) VALUES (:id, :name, :last_name);");
$request->execute (array (':id' =>'hjsbv56s', ':name' => 'fabien', ':last_name' => 'callard'));

$request = $db->prepare ("INSERT INTO users (uid, name, last_name) VALUES (:id, :name, :last_name);");
$request->execute (array (':id' =>'nbx45Aqd', ':name' => 'toto'.$t, ':last_name' => 'au bistro'));

//requete de sélection
$request = $db->prepare ("SELECT * FROM users");
$request->execute ();
var_dump ($request->fetchAll());
?>
cassandra dump requette CQL

cassandra dump requette CQL

La sortie du «var_dump()» ne donne pas une représentation de type clés/valeurs comme on aurait pu s’attendre. Dans notre modèle,la clé est pourtant «uid». La figure ci-dessous montre comment sont effectivement rangées ces données dans la structure de CASSANDRA

cassandra shema colonne

cassandra shema colonne

Plus loin dans la structure de CASSANDRA

Une des propriétés intéressantes de CASANDRA déjà évoqué en introduction, c’est la flexibilité de son modèle. Reprenons l’exemple ci-dessus et adaptons le script PHP et rajoutons des colonnes dynamiquement.

<?php
// Connecteur PDO
$db = new PDO('cassandra:host=127.0.0.1;port=9160');
$db->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
$db->setAttribute(PDO::ATTR_DEFAULT_FETCH_MODE, PDO::FETCH_ASSOC);

// Utilisation
$db->exec ("USE mytest");

$request = $db->prepare ("INSERT INTO users (uid, name, last_name,mobile) VALUES (:id, :name, :last_name, :mobile);");
$request->execute (array (':id' =>'fghtae23', ':name' => 'Stéphanie', ':last_name' => 'raymond',':mobile'=>'0608124527'));

//requete de sélection
$request = $db->prepare ("SELECT * FROM users");
$request->execute ();
var_dump ($request->fetchAll());
?>

L’image ci dessous vous montres comment sont rangées les nouvelles colonnes.

cassandra shema famille de colonne

cassandra shema famille de colonne

Comme vous pouvez le constater, la colonne a été rajoutée dynamiquement. Dans un modèle relationnel comme sous MySQL, il aurait été nécessaire de faire un «ALTER TABLE» pour pouvoir ajouter cette nouvelle information.

CASSANDRA, en plus de cette flexibilité sur le modèle, propose de rajouter une dimension qui permet de regrouper des ensembles de colonnes : on parlera de «SUPERCOLUMN». On utilise la «SUPERCOLUMN» pour regrouper de manière temporelle ou en fonction d’un contexte des «column». La super colonne est une clé particulière dans la «column families». Ci dessous la représentation de nos données avec deux «SUPERCOLUMN» : «mandatory» et «fac»

cassandra shema des supers colonnes

cassandra shema des supers colonnes

Comme pour les colonnes, les «column family» peuvent avoir leur «SUPER COLUMN». On parlera de «SUPER COLUMN FAMILY». Leur structure est du même format que la super colonne mais à un niveau au dessus.

Il n’est peut être pas évidant de comprendre cette organisation en colonne. Le point suivant vous permettra (je l’espère) d’installer CASSANDRA et les différentes librairies connexes pour pouvoir l’utiliser avec PHP. J’ai fait le choix de ne pas employer de librairies écrites en PHP pour la communication avec l’API de CASSANDRA : «thrift». J’utiliserais dans ce billet la librairie PDO_CASSANDRA qui implémente un pseudo langage SQL : «CQL» et qui utilise l’API «thrift».

Installation de CASSANDRA et de l’outillages

Installation de la base de données

L’installation de CASSANDRA est très simple. On récupère un tarball et on a juste besoin de configurer certaines variables d’environnements. CASSANDRA est écrit en JAVA et nécessite un JDK à jour. La première étape consiste donc à mettre à jour la version de votre JVM, de récupérer la version stable de CASSANDRA et de la décompressez là où vous souhaitez l’installer. Personnellement, j’ai fait les choix suivant :

  • création du répertoire « cassandra-1.0.6» dans /usr/local/» et décompression du tarball,
  • création du répertoire « cassandra-1.0.6» dans «/var/»
  • création du répertoire «data» dans «/var/cassandra-1.0.6»
  • création du répertoire «saved_caches» dans «/var/cassandra-1.0.6»
  • création du répertoire «cassandra» dans «/var/log/» pour la gestion des log

Il convient de modifier le fichier de configuration de CASSANDRA et d’initialiser les variables d’environnement dans votre profile système : «.profile». Il faut impérativement avoir une JVM installée dont la version est > à 1.6. Dans ma configuration actuelle, voici les valeurs de mon PATH. Adaptez bien en fonction de votre configuration !

    .profile

  • export JAVA_HOME=/System/Library/Frameworks/JavaVM.framework/Home/
  • export PATH= »/System/Library/Frameworks/JavaVM.framework/Versions/1.6/Home/bin:$PATH »
  • export CASSANDRA_HOME= »/usr/local/cassandra-1.0.6″
    /usr/local/cassandra-1.0.6/conf/cassandra.yaml

  • cluster_name: ‘stephane cluster’
  • data_file_directories: – /var/cassandra-1.0.6/data
  • commitlog_directory: /var/log/cassandra/commitlog
  • Il est important pour avoir de bonne performance que les «commitlog» soit sur un disque séparé ou positionné en mémoire !
  • saved_caches_directory: /var/cassandra-1.0.6/saved_caches
  • vérifier cette directive, mais par défaut c’est bien«localhost» : listen_address: localhost

Pour lancer le démon :

/usr/local/cassandra-1.0.6/bin/cassandra -f
démarage de cassandra

démarage de cassandra

CASSANDRA est démarré et est à l’écoute d’un client qui utilisera l’API «thrift». Vérifions que nous pouvons bien nous connecter à CASSANDRA avec le client :

/usr/local/cassandra-1.0.6/bin/cassandra-cli --host 127.0.0.1 --port 9160
cassandra connexion et description du keyspace "mytest"

cassandra connexion et description du keyspace "mytest"

On va par la même occasion installer une libraire supplémentaire «mx4j» qui permettra à certains outils d’administrations de récupérer des métriques de fonctionnement et de les grapher comme le montre l’image ci desous.

cassandra libraire jmx pour les métriques systèmes

cassandra libraire jmx pour les métriques systèmes

Installation de « mx4j»

    L’installation est très simple.

  • récupérer le tarball et décompressez le
  • placez dans le dossier «lib» de CASSANDRA les «.jar». Dans notre cas ce sera : «/usr/local/cassandra-1.0.6/lib/»
  • relancer CASSANDRA
  • on reviendra dessus pour visualiser ces données.

Pour pouvoir faire nos tests et notre première implémentation, il nous reste plus qu’à installer «thrift», «boost» et «PDO_CASSANDRA»

Installation de «thrift», «boost» et «PDO_CASSANDRA»

«thrift» est une API de communication pour les langages de programmation. Elle est dépendante de «boost» qui permet entre autre d’accélérer les communications clients thrift.

Une fois que vous avez compilé les deux librairies, nous pouvons installer la libraire PDO_CASSANDRA. Il existe d’autres librairies PHP pour utiliser CASSANDRA comme par exemple «PHPCassa» ou PANDRA. Elles implémentent nativement en PHP un client «thrift». Le bon usage voudrait utiliser une librairie qui permet de préparer les requêtes. Je vous recommande donc PDO_CASSANDRA et l’utilisation du CQL.

CQL est un pseudo langage SQL avec la même syntaxe que PDO_MySQL. Attention toutefois, il n’est pas possible de faire du transactionnel. CASSANDRA ne supporte pas ce protocole que l’on trouve sur des SGBD relationnel.

Récupérer les sources de PDO_CASSANDRA et compiler la lib :

phpize
./configure
make
make install

#éditer votre php.ini et rajoutez l’extension.

extension = pdo_cassandra.so

relancer votre serveur web et faite un «php -m» pour vérifier que le module est bien opérationnel. Dans le package que vous avez récupéré, il y a un ensemble de tests que vous pouvez réaliser. Ces fichiers sont intéressants car ils peuvent vous donner quelques indications pour utiliser la librairie dans votre code PHP.

Mes premier pas avec CASSANDRA & PHP

Premier script PHP

Tout au long de cet article, j’ai utilisé des scripts PHP. Reprenez les et faites vos propres tests. N’hésitez pas à analyser les scripts de test qui sont livrés avec le tarball.

Outillages et ressources pour CASSANDRA

Il existe un ensemble d’outils qui permettent de gérer son cluster ou son noeud CASSANDRA. J’ai installé deux outils d’administration tous les deux de type WebUI

  • « opscenter » de datasax : Il y a une version Free et une commerciale,
  • Cassandra Cluster Admin : écrit en PHP et réalisé par Sébastien Giroux. Le projet utilise la librairie PHPCASSA comme client «thrift». Le module de métrics (cf image ci dessus) est issue de ce projet.
cassandra cluster admin

cassandra cluster admin

Conclusion

J’espère que cette présentation de CASSANDRA vous a donné les clés pour approfondir le sujet. Je traiterais dans un prochain billet du langage CQL et des index au sein de CASSANDRA. Comme dit en introduction, CASSANDRA n’est qu’un maillon dans une architecture permettant l’extraction, la manipulation et l’interprétation de données massives.

Le BIG DATA fait appel à plusieurs technologies et mécanismes qui permettent, mis bout à bout, d’exploiter cette volumétrie de données. voici un exemple possible d’une chaîne de traitement :

  • On stock des «logs» bruts comme par exemple des logs web + flux financiers + toutes les interactions utilisateurs etc,
  • On traite les logs bruts par des mécanismes de Mape/Reduce et on stock le résultat du Reduce dans un dépôt comme par exemple HADOOP,
  • On créer d’autres routines de traitement «MAP» & «REDUCE» afin d’extraire des métriques interprétables d’un point de vue business,
  • En fonction des métriques calculées, on pourra les intégrer dans le SGBD adéquate comme par exemple CASSANDRA, MySQL, REDIS, MongoDB…,
  • Un utilisateur en se connectant à son BI full web va visualiser dans un « Chart » en html5 toutes ces métriques.

Ceci n’est qu’un schéma possible ! Le BIGDATA fait appel à de multiples compétences : Marketing, Statistique, Informatique, Science du langage, Economiste …

8 réflexions au sujet de « Débuter avec CASSANDRA et PHP »

  1. Article intéressant, mais il y a peut être un truc que je n’ai pas compris, depuis quand est-on obligés de faire un truncate pour rajouter une colonne sur une table en mysql ?

  2. Merci pour l’article. Oui parfaitement raison ce n’est pas un « truncate » mais un « ALTER TABLE » . C’est corrigé dans l’article.

  3. Ping : Découvrez la base de données NoSQL CASSANDRA et... - Live NextSeo

  4. Petite précision à propos de PDO_CASSANDRA, il ne fonctionne qu’avec Thrift 0.6 or la dernière version de Thrift est la 0.8.
    Il existe cependant PHPCassa qui gère le CQL avec Thrift 0.8 mais bon c’est pas PDO…

  5. Ça semblerai réglé depuis la version 0.2 (Juillet 2012)

    Merci pour cette article, vraiment bravo, ça fait plaisir de voir un mec qui pond un tuto qu’on peut suivre sans ce perdre, détaillé et clair.

    Resterai plus qu’à parler rapidement de la notion de Multi-Node (qui doit être sur le site j’imagine, mais j’ai pas encore regardé)

    En tout cas, un grand bravo

    • Bonsoir,

      merci pour votre message qui est encourageant pour continuer même ci en ce moment, je ne suis pas actif pour mettre à jour ou développer sur le sujet (working oblige :) )

  6. Ping : Big data et NoSQL - Arnaud Guignant

Répondre à Nico Annuler la réponse.

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

*

Vous pouvez utiliser ces balises et attributs HTML : <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>