Plateforme BigData (Cloudera) sur un Cloud: automatisation avec Cloudify

Le Big Data est un sujet incontournable chez FastConnect: pour élargir son business, il est maintenant critique d’élargir son champ de vision à l’aide des données externes et les données non-structurées et sous-exploitées.
Hadoop et son écosystème répond à ces challenges, et cette plateforme Big Data devient de plus en plus mature grâce aux différents éditeurs comme Cloudera, HortonWorks, MapR ou Pivotal.

Mais la mise en œuvre de cette plateforme constitue aussi un challenge:

  • Pour répondre à des problèmes complexes, la communauté a développé plusieurs outils indépendants: Sqoop, Flume, HBase, HDFS, etc.
    La multiplicité de ces outils rend le déploiement plus complexe.
  • Pour traiter des volumes conséquents, le déploiement de la plateforme doit se faire sur plusieurs nœuds. De plus, on veut pouvoir augmenter ou réduire le nombre de nœuds de manière élastique en fonction du besoin.
  • Avec un grand nombre de nœuds, on est sujet à plus de risque de pannes, ce qui nécessite une attention particulière sur la HA (High Avaibility / Haute Disponibilité)

L’article présent traite de l’automatisation à l’aide de Cloudify du déploiement et de la configuration sur un Cloud d’une telle plateforme, basée sur la distribution Cloudera de Hadoop.

Besoins

une plateforme BigData configurée

Nous souhaitons effectuer des traitements sur un gros volume de données et obtenir par exemple des statistiques sur un fait, ou encore faire des prédictions. Oui on souhaite faire du « BigData », et il nous faut une plateforme adéquate déployée et configurée. Une solution serait de se servir de la plateforme pré-installée que propose Cloudera sous forme d’une machine virtuelle « All-in-One »

Oui mais… j’ai vraiment beaucoup de données!!

Ça se corse un peu! Le volume est énorme, tout stocké sur une seule machine ne me permettra pas de bénéficier de la réduction du temps de traitement que nous offre la faculté de distribution du traitement. On voit là une limite du mode StandAlone (All-in-One): il nous faut une plateforme en architecture « distribuée« , et donc plusieurs machines qui servirons de DataNode / TaskTracker (Nœud de stockage de données et de traitement ).

Je n’ai pas assez de budget..

Oui c’est vrai, il faut du budget pour s’offrir une plateforme comportant plusieurs serveurs. Pourquoi ne pas se tourner vers le Cloud? En effet, avec la particularité IaaS du Cloud Computing, il est désormais possible d’obtenir de l’infrastructure (machines virtuelle en l’occurrence) et de payer en fonction de la durée d’utilisation. Ainsi plus besoin d’une plateforme de serveurs physiques, car il est possible de louer des machines virtuelle (VMs) à l’heure chez un fournisseur ( Amazon EC2 par exemple ) ce qui ne nécessite pas forcement un gros budget au départ ;)

Oups… j’ai fait une erreur lors de la configuration: trop longue et répétitive :|

Le fait de louer des VMs pour un certain temps et de les détruite après, entraîne la réinstallation et la reconfiguration de la plateforme chaque fois que le besoin se pose. Cette opération est longue et répétitive quand elle est effectuée manuellement. Aussi, les risques d’erreurs de configuration sont grands. Automatiser le processus permet d’être sûr d’avoir les mêmes configurations d’un déploiement à l’autre, et de gagner considérablement en temps.

Cloudify est un outil qui permet d’effectuer une telle tâche: nous n’avons plus qu’à décrire les procédures d’installation et de configuration de la plateforme, et d’exécuter le tout quand bon nous semble avec une seule ligne de commande: install-application cloudera

Nous pourrons aussi jouir des autres fonctionnalités de Cloudify telles que:

  • Multi-cloud : le prototype hébergé chez un fournisseur public (Amazon EC2 par exemple) pourra être migré facilement sur l’infrastructure interne (Openstack, ou bare metal par exemple)
  • Custom Command : pour automatiser des tâches d’administrations sur l’ensemble des nœuds
  • Gestion du cycle de vie de l’application: pour la gestion de crash (fail over)
  • Élasticité: possibilité d’ajouter à chaud des nœuds DataNode+TaskTracker en cas de besoin
  • Monitoring: avoir une vue d’ensemble du cluster, en connaître la charge et ainsi anticiper l’ajout de nouveaux nœuds

L’application cloudify-cloudera

Cloudify-cloudera est le nom que nous avons donné à l’application Cloudify qui permet de faire tout ce qui a été cité plus haut. Le Cloud utilisé ici est Amazon EC2 (mais Cloudify est Multi-Cloud: cela fonctionne aussi bien sur OpenStack, sur un environnement de développement avec VirtualBox, ou même un datacenter traditionnel [sans virtualisation]).

Les recettes dans leur état actuel permettent d’obtenir une plateforme BigData composée d’un Cloudera Manager et d’une distribution Hadoop repartie sur deux types de noeuds : Master et Slave. Un service de base de données MySQL est aussi disponible en cas de besoin. En plus de la distribution Cloudera, nos recettes sont capables de déployer un MongoDB en mode Sharding afin d’y effectuer du MapReduce.

archi cluster cloudera on demand

Nous nous servons de Cloudera Manager (CM) pour configurer les composantes de la plateforme. CM expose une API REST pour permettre son pilotage programmatiquement, dans notre cas, par des scripts Groovy exécutés par Cloudify.

Les Briques (noeuds) et services installés

L’application installe quatre principaux middlewares :

  • Cloudera Manager
  • Cloudera distribution of Hadoop
  • La base de données MySQL : optionnelle
  • La base de données MongoDB: Sous forme de cluster (mode sharding).

L’installation et l’implémentation de ces services se font sur des instances de machines, appelées nœuds du cluster.

Les services Cloudera supportés sont:

ZOOKEEPER, HDFS, MAPREDUCE, OOZIE, HIVE, HBASE, SQOOP, FLUME, HUE

Le concept de Hadoop veut lui-même que l’on dispose principalement de deux entités ou types de rôle : le maître (Master) (NameNode, JobTracker) et l’esclave (Slave) (DataNode, TaskTracker). Le service MongoDB étant déployé en mode sharding, il est nécessaire pour son architecture de lui fournir aussi deux types d’instances : master et slave. MySQL quant à lui sera déployé sur une instance de machine propre à elle.
Si nous récapitulons, nous pouvons dire que notre système sera composé principalement de quatre types de noeuds (service Cloudify).

Cloudera Manager : (code : cdh4-manager)

Représente une instance de Cloudera Manager. Ceci permet d’administrer l’ensemble du cluster via une interface Web.

Master CDH : (Code : cdh4-master)

Nœud sur lequel seront installés les composantes NameNode, JobTracker, et tout autre service ou composante de service Cloudera qui implémente une division Master/ Slave, à l’instar de MongoDB (partie Master).

Slave CDH : (Code : cdh4-slave)

Nœud sur lequel seront installés les composantes DataNode, TaskTracker, et tout autre service ou composante de service Cloudera qui implémente une division Master/ Slave, à l’instar de MongoDB (partie Slave).

MySQL : (Code : mysql-cdh4) sur lequel sera installé le middleware MySQL.

web-ui-cloudify

Opérations annexes et/ou d’administrations

Backup / Restauration HDFS

Une problématique assez fréquente est la sauvegarde des données potentiellement résultantes des traitements effectués à la fin de l’utilisation du cluster, de façon à les réimporter une prochaine fois pour continuer les traitements.

Deux custom commands ont été développées et implémentées aux noeuds de type cdh4-master pour cet usage. La commande backup prend en paramètre le nom du répertoire à sauvegarder sur Amazon s3 ; la commande de restauration prend en paramètre le nom de la sauvegarde à restaurer.
Il est à noter que le nom de fichier à persister sur S3 est généré de façon intelligente selon un pattern « hdfs-backup-yyy-mm-dd~hh.mm.ss » ce qui permet de s’y retrouver très rapidement lorsqu’on cherche à restaurer une sauvegarde précise.
L’invocation de ces commandes via le Shell Cloudify se fait de la façon suivante :

Invoke cdh4-master s3HdfsBackup /test
// Sauvegarde un répertoire HDFS /test dans un repertoire « hdfs-backup-yyy-mm-dd~hh.mm.ss »

Invoke cdh4-master s3HdfsRestore /hdfsBackups/hdfs-backup-yyy-mm-dd~hh.mm.ss /test
 // Restaure le contenu du répertoire s3 hdfs-backup-yyy-mm-dd~hh.mm.ss dans un répertoire /test du HDFS

Une autre façon de faire est d’exploiter le montage des EBS d’Amazon dans Cloudify: on aurai pu démonter les EBS en cas de destruction du Cluster, pour les re-monter lorsqu’on a besoin à nouveau du Cluster. Ce mécanisme est d’ailleurs nécessaire pour ne pas perdre les données en cas de crash d’une VM.

Mongo sharding

Possibilité offerte via custom commands d’activer le sharding sur des bases de données et collections MongoDB.

Conclusion

Au terme de cet article, nous avons présenté quelques besoins qui se posent concernant la gestion d’une plateforme BigData et les solutions que nous y avons apportées, se résumant en l’automatisation du déploiement et de la configuration. Le déploiement opéré par Cloudify est multi-cloud, c’est-à-dire que le prototype développé sur Amazon (pour des raisons de budget) pourra être migré facilement sur votre plateforme Openstack interne. De plus nous bénéficions des fonctionnalités d’auto-réparation offerte par Cloudify (remplacement et reconfiguration des composants en panne).

L’utilisation de l’application développée est aisée. Le projet n’est pas clos, nous continuons d’y ajouter des fonctionnalités et améliorations. Quelques évolutions à venir :

  • Possibilité d’utiliser des EBS comme support de stockage: ce qui rassurerait l’utilisateur quant à la sauvegarde de ses données
  • Custom command pour ajout / suppression de services cloudera
  • Combiner Puppet / Cloudera: Puppet permettra de gagner en temps et en performance pour tout ce qui est installation et déploiement, tandis que Cloudify gérera les dépendances entre les services et la configuration du cluster une fois le tout installé.
  • Custom command pour importer / exporter des Job Oozie au format XML,

On démontre ici une fois de plus, la puissance de l’association BigData + Cloud, ainsi que les nombreuses possibilités que nous offre l’outil Cloudify.

Formation BigData – Hadoop – module Développeur

Bonjour,

Le BigData n’est plus réservé aux géants du Web, c’est maintenant l’affaire de tous.
On estime que 80% des données d’une entreprise sont non-structurées et inexploitées… et le volume augmente de plus en plus rapidement. De plus, les infrastructures modernes nous permettent de conserver de plus en plus de données à moindre coût : rien n’est à jeter, tout peut être utile.

FastConnect a le plaisir de vous présenter sa nouvelle formation BigData Hadoop orientée Développeurs.
Ce module de 3 jours, alternant cours théoriques et pratiques, vous offre une introduction sur les enjeux du BigData, ainsi qu’une mise en pratique avec la technologie Hadoop. (télécharger le programme de la formation)

L’objectif de cette formation est de démystifier Hadoop, savoir utiliser les outils principaux autour de son écosystème et traiter les données de diverses manières, dont le Machine Learning, afin de présenter les résultats de manière graphique.
Une prise en charge par votre OPCA est possible (numéro d’agrément 11921636592).

La prochaine session aura lieu du 17 au 19 septembre dans notre centre de formation d’Issy les Moulineaux, au prix réduit de 1 700€ HT par participant au lieu de 1 900€.

Les places sont limitées, si cette formation vous intéresse, n’hésitez pas à nous contacter.

Cordialement,

L’équipe FastConnect Training
+33 (0)1 45 07 81 65
training@fastconnect.fr

Soirée FastConnect avec Software AG / Terracotta

Le Mardi 22 Janvier 2013 s’est déroulée une soirée FastConnect, et nous avons eu le plaisir d’accueillir Software AG / Terracotta pour nous parler de EhCache / BigMemory.

Personnellement, je trouve que cette solution répond à pas mal de besoins que je rencontre chez les clients.
De plus, la force de la solution est de pouvoir commencer avec un « petit cache » à l’aide d’EhCache (opensource, et qui s’intègre avec Hibernate ou Spring), puis bénéficier du cache « off-heap » avec BigMemoryGO, puis le rendre distribué avec BigMemoryMax.

600_198449722

A titre d’information, cette solution a été mise en production chez un client pour de la détection de fraude en temps réel, avec un volume de 16To en mémoire! Le mot « BigData » prend tout son sens.

Capture d’écran 2013-01-24 à 16.14.58

Je ne vous en dit pas plus, et je vous laisse découvrir EhCache / BigMemory à travers la documentation officielle.

GigaSpaces Document API and JAXb

I wrote this article and the plugin that ships with it last year when GigaSpaces 8.0 was released and realized that I never finally published both the sources and article so here it is!

GS8 introduced a new way to store data in a flexible manner: the space document.

Document is an evolutive object storage that allow users to dynamically add or remove properties and even dynamically add indexes on any property.

Some of my clients uses XML to model their data and where quite happy to be able to seamlessly be able to make evolve their Space object as easily (or even more easily) as their XML schema.

As this need sounded quite interesting to me I build a small plugin for JAXb that allows to generate Document compliant classes directly from your XML Schemas.

You can download the source code and test it from here: https://github.com/fastconnect/jaxb-gigaspaces

Morning with MongoDB et MUG

Le 7 Novembre 2012 se sont déroulés 2 événements: le « Morning with MongoDB » et le « MongoDB User Group (Paris)« .

Morning with MongoDB

Vous pouvez retrouver les slides des présentations sur le site de 10gen.
Pour plus d’information sur l’événement, regardez ici.
L’agenda de cette matiné été le suivant:

  • Présentations de 10gen (MongoDB et BigData)
  • Présentations de cas d’utilisations des clients
  • Présentations de cas d’utilisations des partenaires (dont FastConnect!)

Je ne vais pas vous détailler toutes les présentations, mais juste quelques remarques qui me semble interessantes.

10gen ont parlé de la Roadmap, et on note les prochaines fonctionnalités pour la 2.4:

  • Intégration de Kerberos et LDAP/AD
  • Hash comme clé de répartition pour le Sharding
  • Moteur V8 pour le MapReduce
  • Recherche par intersection de polygones pour la recherche GeoSpatial
  • Amélioration du framework d’aggregation

Criteo et le Figaro on un usage commun: stocker des données de sources hétérogènes dans MongoDB grâce à la flexibilité du schéma. Pour Criteo, ils peuvent stocker dans une seule même base les catalogues de produits de plusieurs vendeurs, et pour le Figaro, ils peuvent stocker les données des différents sites web au même endroit.

Je remarque aussi un retour d’expérience qui revient fréquemment: grâce à des performances bien supérieurs aux RDBMS (dans leurs cas d’usages), MongoDB supprime la nécessité d’un cache, et la complexité qui va avec (gestion de l’eviction, mise-à-jour, etc.)

MongoDB s’avère être aussi efficace pour stocker les logs: en effet, les « Capped Collections » sont très utiles pour cet usage, et on peut choisir un niveau de « Write Concern » différent en fonction de l’importance du log (DEBUG, WARN, etc.)

Enfin, MongoDB et sa simplicité à mettre en place la réplication, sert à fournir des données à travers le monde (WAN).

Je vous laisse consulter les présentations ici, ainsi que ma présentation sur un cas d’usage MongoDB avec Hadoop:

MongoDB User Group

Ce MUG était orienté Cloud:

Nous avons eu une première présentation de la plateforme Cloud Scalr, et comment déployer et monitorer MongoDB dessus.

S’est suivie une présentation sur un retour d’expérience avec MongoDB sur le Cloud (Azure) par Pierre Couzy (Microsoft) et Yann Shwartz.
Cette session était très intéressante, car on découvre les pièges à éviter et les problèmes que l’on peut rencontrer dans des situations réelles.
J’ai beaucoup aimé cette présentation car elle recoupe beaucoup avec notre retour d’expérience avec MongoDB sur le Cloud. C’est pourquoi nous essayons de mettre en place ces bonnes pratiques sous la forme de scripts Cloudify!

Pour terminer, nous avons eu le plaisir d’accueillir Matt Bates qui nous a présenté le nouveau framework d’aggregation de la version 2.2 de MongoDB, ainsi que les futures évolutions.

Je remercie au passage les organisateurs du MUG, les hébergeurs et les différents speaker.

En conclusion, c’était une journée riche et interessante !

FastConnect Inside : le vendredi du connaisseur

Pour notre session de juillet du « Vendredi du connaisseur » (session technique où chacun parle d’un sujet/problématique qu’il a rencontré pendant le mois), nous avons choisi de faire simple : pizza pour tous & prez en freestyle.

Finalement au menu, nous avons eu droit à :

  • une introduction résumée de la formation MongoDB que Mael & Florian ont suivie le mois dernier dans les locaux de FastConnect à Issy (en partenariat avec 10gen)
  • une petite présentation sur la gestion de la mémoire par la JVM et le pourquoi du classique « java.lang.OutOfMemoryError: PermGen space » par Arnaud
  • un survol sur le fonctionnement du SSO & intégration CAS accompagné d’une démo qui marche :) par Marc

Sans oublier les 6 pizzas (de 2 personnes) : Ananas, Cap Horn, Bolognaise, Catalane, Los Angeles et Orientale ;)

Rendez vous à la prochaine session …

Équipe FastConnect Rennes

Paris JUG Juillet 2012 – Couchbase

Mardi 3 Juillet s’est déroulé le Paris JUG. Cette session était orientée 100% NoSQL.

La première partie fut animée par Raghavan « Rags » N. Srinivas sur une présentation de Couchbase.


Attention : on parle bien de Couchbase, pas de CouchDB !
Je reviendrai sur la différence entre les deux dans quelques lignes…

Avant de parler de Couchbase, Rags nous explique l’intérêt du NoSQL, comme la scalabilité horizontale et donc un coût maitrisé.
Si vous n’êtes pas encore convaincu, je vous suggère de voir leur document « Why NoSQL ? » sur le site de Couchbase : http://www.couchbase.com/why-nosql/nosql-database

Qu’est-ce que Couchbase ?

Maintenant se pose la grande question : qu’est-ce que Couchbase ?
La réponse courte : C’est une base NoSQL, orienté « clé/valeur » mais avec des fonctionnalités orientées « document ».

Avant Couchbase, il y avait Membase : un Memcached survitaminé, avec réplication des caches, persistances, une interface d’admin Web bien sympa, etc.
Membase n’existe plus, Couchbase le remplace et l’intègre.

On peut donc utiliser Couchbase comme un cache mémoire pure, en mode clé/valeur, avec l’API cliente de Memcached.

Mais alors, quel est le rapport entre Couchbase et CouchDB ?
Couchbase intègre CouchDB !
Pour prendre un exemple simple : quand vous sauvegardez un document JSON, ce dernier va être envoyé dans le cache Memcached, puis persisté sur disque avec le moteur de CouchDB (de manière asynchrone).

On peut comparer le processus avec celui de MongoDB, à la différence que MongoDB ne possède pas son module de Caching, mais délègue cette gestion à l’OS à l’aide de « Memory-mapped files », qui va flusher sur disque de temps en temps.

Pour mieux illustrer mes propos, voici l’écran de monitoring lorsque je fais une écriture massive :

On remarque un pique de « ops per second » : ce sont mes écritures massives
Mais la donnée se trouve seulement en mémoire, pas encore sur le disque !
On voit alors que le « disk write queue » augmente d’un coup : c’est la file d’attente avant persistance sur disque.
Quelques secondes plus tard, on voit que cette dernière diminue petit à petit.
En même temps, on voit que la base augmente sur le disque dans « couch disk/data size ».
Et toujours en même temps, on voit des « creates per sec » pendant cette phase de persistance.

Pour comprendre comment fonctionne Couchbase, et comment il intègre CouchDB, vous pouvez lire ceci : http://www.couchbase.com/couchdb

Comment lire/écrite dans Couchbase (en Java) ?

Couchbase est donc très orienté performance, puisqu’on va exploiter au mieux la mémoire.
De plus, les opérations de l’API sont de type « fire and forget » : quand on demande de sauvegarder un document, l’API nous rend la main tout de suite sans savoir si la sauvegarde a bien fonctionné !
Pour cela, il va y avoir un mécanisme semblable aux « Future » en Java, ou au « Write Concern » en MongoDB ou Cassandra.
L’API va donc nous renvoyer un objet « OperationFuture », sur lequel on va pouvoir, plus tard, demander d’attendre la fin de la sauvegarde.
Voici un exemple de code, plus parlant je l’espère :)

CouchbaseConnectionFactory factory = new CouchbaseConnectionFactory(
  Arrays.asList(URI.create("http://localhost:8091/pools")),
  "default",
  "");
client = new CouchbaseClient(factory);

GsonBuilder builder = new GsonBuilder();
Gson gson = builder.create();

// on stocke ici les futures des opérations d'insertion
List<OperationFuture<Boolean>> futures = new ArrayList<OperationFuture<Boolean>>();

for (int cpt = 0; cpt < 80000; cpt++) {

 // création d'un document
 People people = new People();
 people.setFirstname("Mathias");
 people.setLastname("Kluba");

 // j'utilise ici GSON pour construire mon JSON à partir de mon POJO
 String json = gson.toJson(people);

 // on va générer un ID pour chaque item
 UUID uuid = UUID.randomUUID();

 // sauvegarde de l'objet
 OperationFuture<Boolean> setResult = client.set(
 uuid.toString(),
 0,
 json);

 // on conserve le future pour plus tard...
 futures.add(setResult);
}

// maintenant qu'on a balancé les sauvegarde sur le server,
// on attend la fin de chacune d'entre elles,
// et on vérifie que la sauvegarde a réussie
for (OperationFuture<Boolean> f : futures) {
 Assertions.assertThat(f.get()).isTrue();
}

Ce qui est sympa, c’est que même la lecture peut être asynchrone : on balance plein de requête au serveur, et on demande ensuite le résultat en asynchrone à l’aide du Future.

Comme tout fonctionne en mode asynchrone, cela peut poser des problèmes lors de l’écriture : comment gérer les écritures concurrentes ?
En base relationnelle, on va vouloir faire une transaction, pour être sûr que personne ne modifie la même donnée.
Mais Couchbase ne supporte pas les transactions !
Ceci dit, il y a moyen de gérer la concurrence de manière « Optimiste » : on va admettre que tout va bien dans la plupart des cas, et s’il y a un problème de concurrence, alors on va gérer l’erreur au niveau de l’application.

Pour ça, il y a le mécanisme de CAS (Check and Set).
Le CAS va se servir d’une sorte de Checksum qui va nous permettre de vérifier si quelqu’un n’a pas modifié le même objet entre temps.
Ex :

  • Je récupère un objet avec son CAS
  • Je le modifie en mémoire
  • Quelqu’un d’autre le récupère aussi, le modifie et le sauvegarde en base
  • Lorsque je le sauvegarde, je précise la valeur du CAS que j’ai obtenu
    • ERROR : la valeur du CAS fournie n’est pas le même en base : quelqu’un a modifié le même objet entre temps : la sauvegarde échoue

Comme Linus Torvalds disait : TALK IS CHEAP. SHOW ME THE CODE !

GsonBuilder builder = new GsonBuilder();
Gson gson = builder.create();

// création d'un document
People people = new People();
people.setFirstname("Mathias");
people.setLastname("Kluba");

// j'utilise ici GSON pour construire mon JSON à partir de mon POJO
String json = gson.toJson(people);

// on va générer un ID pour chaque item
UUID uuid = UUID.randomUUID();

// sauvegarde de l'objet
OperationFuture<Boolean> future = client.set(
 uuid.toString(),
 0,
 json);

Assertions.assertThat(future.get()).isTrue();
System.out.println(future.getStatus());

// obtient l'objet avec son CAS
CASValue<Object> withCas = client.gets(uuid.toString());

people = gson.fromJson((String)withCas.getValue(), People.class);
people.setFirstname("Roi Mathias 1er");

json = gson.toJson(people);

// tente de mettre à jour l'objet avec son CAS
CASResponse response = client.cas(uuid.toString(), withCas.getCas(), people);

Assertions.assertThat(response).isEqualTo(CASResponse.OK);

// tente de mettre à jour une seconde fois:
// mais qui ne va pas marché car on n'a pas le bon CAS

response = client.cas(uuid.toString(), withCas.getCas(), people);

Assertions.assertThat(response).isEqualTo(CASResponse.EXISTS);

Un autre truc sympa, hérité de Memcached, c’est la notion de TTL (Time To Live).
Si je reprends le code de la sauvegarde, on remarque un 2 ème argument de type Integer :


// sauvegarde de l'objet
OperationFuture<Boolean> setResult = client.set(
 uuid.toString(),
 0,
 json);

C’est en fait le TTL en seconde : je peux ainsi dire « sauvegarde moi cette donnée, mais elle expire dans 60sec ».
Ici, cas particulier, je ne veux pas d’expiration, la valeur du TTL est donc 0.

Bon, faire un « set/get » en mode clé/valeur, c’est bien mais parfois ça peut être limitant…
Et si je veux maintenant requêter sur le « lastname » ?

C’est là que l’approche « orienté document » de Couchbase est intéressante :
Ils prennent pour postula que la majorité de vos requêtes seront de type « clé/valeur ».
Tout d’abord, quand vous sauvegardez une valeur au format JSON, cette valeur sera traitée de manière très spéciale par Couchbase.
Mais par défaut, on ne peut donc pas requêter sur les champs de votre JSON. Pour ce faire, il faut créer une sorte d’index sur les champs que vous avez besoin de requêter.

Je dis bien « une sorte d’index », car en Couchbase on appelle ça une « Vue » (comme les Vue SQL), mais le plus fun c’est qu’on code cette vue avec une fonction de Map-Reduce (ou Map seulement) ;)

En résumé : les Vues sont des « Map-Reduce » à la demande.

Quand on interroge une vue, on peut demander le résultat déjà calculé au préalable, ou re-indexer la base en re-exécutant la fonction de Map-Reduce.
Voici ce qui se passe si j’interroge une vue en forçant la re-indexation :

Voici un exemple de Vue et son utilisation en Java :


Query query = new Query();

query.setReduce(false);
query.setIncludeDocs(false);
query.setStale(Stale.FALSE);

View view = client.getView("people", "bylastname");

Paginator paginator = client.paginatedQuery(view, query, 500);

while (paginator.hasNext()) {
 ViewRow row = paginator.next();
 System.out.println(
  "ID: " + row.getId() +
  " Key: " + row.getKey()  +
  " Value: " + row.getValue());
}

Et voilà à quoi ça ressemble coté Couchbase :

Petit détail : si vous forcer la re-indexation, ça ne s’applique bien sûr qu’aux nouvelles données ou aux données changées… donc si vous avez déjà 80000 items, que le Map-Reduce est terminé, et que vous ajoutez 80 items, le Map-Reduce sera plus rapide :)

Pour conclure sur les aspects requêtages, Couchbase, offre une API Memcached (pour de la haute performance) mais offre aussi une API REST, beaucoup plus « Web friendly ».
Les applications Web peuvent alors récupérer le JSON avec une URL REST qui ressemble à cela :
http://localhost:8091/couchBase/default/00006e0b-4b58-465d-b045-e2a485baaa51

Pour obtenir le résultat d’une vue, cela ressemble à cela :
http://localhost:8091/couchBase/default/_design/dev_people/_view/bylastname?limit=10&skip=0

La présentation de Couchbase s’arrête à peu près là. On voit alors que Couchbase est orienté Web, Performance, Scalabilité Horizontale, et que son installation et utilisation est très simple.

Couchbase et Cluster

Mais je souhaite aller plus loin,  j’ai voulu savoir comment fonctionne les aspects « scalabilité horizontale » de Couchbase.
Premièrement : tout comme Cassandra, chaque nœud Couchbase fonctionnent de la même manière, aucun n’est spécialisé.

Couchbase utilise Memcached, donc exploite le même mécanisme de répartition de charge grâce au « Consistent Hashing » : les données sont uniformément réparties sur tous les nœuds disponibles.
Et si j’ajoute un nœud ?
Et bien il n’est pas exploité tout de suite : il est en attente de Re-Balancing.
Cette opération vous permet donc de re-balancer les données sur plusieurs nœuds à la fois, si vous en ajoutez plusieurs :

Attention : c’est une opération bloquante et elle peut prendre du temps, ce qui rend donc votre serveur indisponible. Il faut alors choisir le moment de son exécution judicieusement…. mais au moins, ce n’est pas automatique, et ça ne va pas planter votre prod lors d’une forte charge !

Le même mécanisme fonctionne quand on supprime un nœud :

Tout ça, c’est pour répartir la charge, et donc :

  • Exploiter le disque + mémoire de plusieurs machines pour accélérer les requêtes de lecture/écriture
  • Exploiter le CPU de plusieurs machines pour accélérer le Map-Reduce des Vues

Mais qu’en est-il de la résilience ?
Elle est assuré grâce à la réplication, et on configure ça au niveau d’un « Bucket ».

Un « Bucket » c’est l’équivalent d’une base en SQL.
Il n’y a pas de notion de « table » (ou « collection » comme en Mongo), si vous voulez séparer des données alors il faut créer un autre Bucket.
Ce dernier possède un quota en mémoire, et un nombre de réplica.
Si le nombre de réplica est 1, alors la donnée sera écrite sur 2 nœuds.

Conclusion

En conclusion, j’ai été agréablement surpris.
Premièrement, j’ai confondu Couchbase et CouchDB : Couchbase c’est un mixe des meilleurs choses de Memcached et CouchDB, c’est donc pas mal :)
L’approche « Vue avec Map-Reduce » est intéressante : on ne ralentit pas les écritures pour mettre à jour un index, ou construire un « b-tree », alors que finalement on va requêter sur seulement quelques champs du document…
Il y a donc de très bonnes idées, même si, à mon avis, il reste des choses à améliorer.
Couchbase est donc différent des autres solutions NoSQL, avec ses avantages et ses inconvénients.
Vous avez donc une base de données qui vient étoffer votre panel de solutions NoSQL, ce qui vous donne encore plus de choix, mais ce qui rend la tâche encore plus complexe :)

MongoDB Day Paris 2012 – 8 – MongoDB 2.2

La journée s’est conclue par un aperçu des principales fonctionnalités apportées par la version 2.2 de Mongo qui sortira dans le courant de l’été 2012.

  • Nouveau framework d’agrégation de donnée, en complément du map-reduce existant.
  • TTL collections permettant d’avoir des objets effacés automatiquement après un temps donné.
  • Meilleure concurrence, le lock se faisant maintenant au niveau d’une base de donnée au lieu de se faire sur tout un processus mongod
  • Data aware sharding permettant d’ajouter un niveau d’affinité aux données pour aider mongo à placer les chunks sur les différents shards. Particulièrement utile en environnement multi-datacenter pour faire en sorte que les données d’une région restent sur celle-ci.
  • Amélioration des optimisations de requêtes

Le détail des changements peut être trouvé ici

Ce billet fait partie de la série sur la journée MongoDB Day Paris 2012:

MongoDB Day Paris 2012 – 7 – Déploiement et Monitoring – Mathias Kluba, Fastconnect

Suite à notre partenariat avec 10gen, et notre engouement autour de MongoDB, nous avons décidé de parler de déploiement et supervision lors du passage en Prod d’un cluster MongoDB.

Cette session a été présentée par notre consultant Mathias Kluba, ainsi que Loic Dachary de eNovance, société spécialisée dans les services Cloud et l’infogérance.
eNovance, de par leur infrastructure Cloud OpenStack, ont une grande expérience autour du déploiement et du monitoring, et la demande de déploiement de cluster MongoDB augmente de jours en jours…
eNovance sont aussi très actif atour de la technologie de déploiement Puppet, et contribuent avec Puppet Labs sur le sujet.
Ça a donc été un grand honneur de pouvoir co-animer cette session avec Loic.

Cette présentation est constituée de 2 axes: le déploiement et le monitoring.

Déploiement

Le déploiement peut s’avérer complexe quand on souhaite déployer un cluster MongoDB avec ReplicatSet et Sharding…
Mais de nombreux outils supportent MongoDB grâce une communauté très active.

Voici des outils OpenSources qui peuvent vous aider à cela:

Lors de cette session, nous avons montré une démo de déploiement MongoDB sur Amazon EC2 avec Cloudify.
Là où Chef et Puppet vont déployer le nécessaire sur une machine en fonction de son rôle, Cloudify s’oriente sur le déploiement d’une application, avec tous les middlewares nécessaires, et s’assure aussi de créer les machines virtuelles si besoin.
Cette démo montre alors le déploiement d’un cluster en mode Sharding à l’aide des Recipes de Cloudify (script Groovy).
A noter que Cloudify peut déléguer le déploiement à Chef ou Puppet, et ainsi re-utiliser vos Recipes existantes.

Lors de cette démo on voit aussi la possibilité de définir des « Custom Commands » dans Cloudify, ce qui nous a permis d’exécuter un « mongodump » sur tous les nœuds du cluster à l’aide d’une seul commande (dump ensuite déposé sur Amazon S3).
Vous pouvez alors automatiser de nombreuses tâches de support par ce biais.

Monitoring

La seconde partie de la session s’oriente sur le monitoring d’un cluster MongoDB.
Si MongoDB vient avec quelques outils de monitoring, ces derniers ne seront pas suffisant en condition réel de production.

Si vous n’avez pas une infrastructure de monitoring déjà existante, et que vous ne voulez pas payer le coût d’installation/maintenance, vous avez la possibilité d’utiliser des services de Monitoring (Monitoring as a service) comme:

  • MMS: le service de monitoring de 10gen, spécialisé MongoDB, complétement gratuit et pouvant aider le support 10gen à diagnostiquer vos problèmes
  • Server Density: un service de monitoring générique mais avec une très bonne intégration MongoDB out-of-the-box.

Par contre, si vous voulez intégrer le monitoring de MongoDB à vos outils de monitoring existants, tout comme pour le déploiement, de nombreux outils OpenSources supportent MongoDB grâce à la communauté: Munin, Nagios, Cacti, etc.

Mais ces outils ont généralement une vision « machine »: vous sélectionner votre serveur, et vous avez les statistiques du nœud qui y est installé.
Cloudify gère aussi le monitoring mais du point de vue d’une application: on a l’état de santé de l’application en agrégeant les informations des différents middlewares, ou des différents nœuds du cluster MongoDB.
La session s’achève alors avec une démo de la partie monitoring de Cloudify, avec un cluster MongoDB en Sharding soumis à une charge simulée par une application JMeter.

En conclusion, on remarque que les efforts des communautés OpenSources rend possible l’automatisation des déploiements et le monitoring de MongoDB.
Mais vous pouvez aussi être acteurs dans ces communautés, il en revient donc à vous la responsabilité d’adopter ces outils, remonter les bugs existants, ou les faire évoluer, plutôt que de re-inventer des scripts de votre coté…

Vous pouvez voir la démo de déploiement et monitoring de MongoDB sur Amazon EC2 avec Cloudify sur notre chaine Youtube:

Ce billet fait partie de la série sur la journée MongoDB Day Paris 2012:

MongoDB Day Paris 2012 – 6 – The New Aggregation Framework – Ross Lawley, 10gen

Ross Lawley a présenté pour la dernière conférence de la journée le nouveau framework d’agrégation de données qui va bientôt être disponible avec la prochaine version 2.2 de Mongo.

Le but annoncé de cette nouvelle fonctionnalité est d’apporter un outil complémentaire au map-reduce. La construction de nombre de tâches simples telle que faire une somme, une moyenne ou trouver un minimum/maximum a été grandement simplifié. De plus les performances sont bien meilleures puisque tout est écrit directement en C++ ce qui évite l’overhead de la transcription du javascript utilisé par map-reduce.

Le principe est de décrire une chaîne d’opérations à appliquer, voilà un petit aperçu de la syntaxe :

  • $math : requête, équivalent du find
  • $project : met en forme les résultats, notamment en enlevant/ajoutant des champs
  • $unwind : permet de faire du streaming de tableau, chaque élément du tableau sera traité comme un document
  • $group : agrège les données
  • $sort : fonctionnalités de trie
  • $limit : limite le nombre de documents renvoyés
  • $skip : exclue certains documents du résultat

La syntaxe donne une idée des possibilités du framework, Ross a montré un bon nombre d’exemples pendant la conférence pour illustrer cela. A noter que le sharding est supporté, dans ce cas c’est le mongos qui se charge d’invoquer la chaîne d’opérations.

N’hésitez pas à consulter la documentation officielle pour plus de détails et d’exemples.

Ce billet fait partie de la série sur la journée MongoDB Day Paris 2012: