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 :)

Soirée Paris JUG – Les annotations Java

Le 14 décembre 2010 s’est tenu la  soirée du ParisJUG à l’ISEP portant sur les annotations Java. J’ai eu la chance d’y assister dans le cadre du sponsoring de FastConnect.

La soirée à été animé par Olivier Croisier, auteur du blog The Coder’s Breakfast.

La soirée s’est découpé en deux parties :

  • Le concept d’annotations.
  • Les possibilités offertes par les annotations.

Les annotations Java sont des méta-informations qui peuvent être utilisés dans les différentes phases du cycle de vie d’une applications, à savoir :

  • à la génération du code.
  • à l’exécution de l’application.

Les annotations Javadoc sont les ancêtres des annotations qui sont apparus avec Java 1.5.

/**
* Documentation sur une méthode.
* @param args Le permier argument de la méthode.
* @return Ce que retourne la méthode.
*/

Ce bout de code présent juste au dessus d’une méthode permet à l’outil Javadoc de générer la documentation de l’application.

Mais où trouve-t on des annotations ?

Tout ou presque est annotable en Java, du package à l’argument d’une méthode en passant par les classes. Olivier Croisier nous donne l’exemple suivant de l’utilisation de l’annotation @Deprecated fournit par Java 5 :


@Deprecated
public class Pojo {

@Deprecated
private int foo;

@Deprecated
public Pojo() {
@Deprecated
int localVar = 0;
}

@Deprecated
public int getFoo() {
return foo;
}
public void setFoo(@Deprecated int foo) {
this.foo = foo;
}
}

Les annotations sur les packages peuvent être renseigner dans un fichier package-info.java :


/**
 * La documentation sur ce package.
 */
@UneAnnotation
package org.fastconnect.unpackage;

La création d’une annotation.

Une annotation est une interface qui réponds à certaines spécificités, comme nous pouvons le voir dans l’exemple suivant :

@Retention(RetentionPolicy.RUNTIME)
@Target({ElementType.FIELD,ElementType.TYPE})
public @interface Toaster {

 public static enum Level { LOW , MIDDLE , HARD }

 String toasterName() default "";

 Level level() default Level.MIDDLE;

}

Notre annotation « @Toaster » est définit donc une @interface. Elle est elle-même annotée par @Retention et @Target.

  • @Retention permet de définir la durée de vie de notre annotation dans le cycle de vie du code. Ici, nous décidons de la garder jusque dans le Runtime.
  • @Target permet de définir les cibles qui pourront porter notre annotations. Nous décidons ici de permettre aux attributs et aux classes d’être annotées par @Toaster.

Comme une interface, notre annotation peut comporter des attributs, comme nous pouvons le voir avec notre énumération Level.

La différence avec les interfaces réside dans les signature des méthodes. En effet, le mot clé default permet de définir une compile-time constant qui sera utilisé par défaut.

Les annotations, a quoi ca peut servir cette bête la ?

Il est possible d’utiliser les annotations à différents moment du cycle de vie de l’application. A l’image des métas données pour Javadoc, il est possible de se faire des annotations pour la réalisation de documentation. L’exemple d’une annotation @Todo est souvent utilisé dans ce sens.

Si les annotations sont conservées au Runtime, les mécanismes de réflexion Java permettent de récupérer les annotations ainsi que leur contenu. Il peut donc être possible de faire de la méta programmation à l’aide des annotations. Les annotations JPA ou des EJB 3 sont des bons exemples de méta programmation.

APT pour Annotation Processing Tool est un outil qui permet de processer les annotations lors de la compilation. Il est ainsi possible se servir des annotations pour étendre des règles de compilation ou de développer un générateur de code.

Conclusion

Comme nous avons pu le voire, les annotations offre de nombreuses possibilités, que ce soit lors de l’écriture du code. Cependant, il ne faut pas oublier que trop d’annotations tue les annotations.

Soirée Paris JUG – Moteurs de règles

La 38e soirée du Paris JUG a eu lieu Mardi 09 Novembre 2010 à l’ISEP.

FastConnect y était représentée par Xavier Degenne et moi-même dans le cadre du sponsoring du Paris JUG par FastConnect.

Le thème de cette soirée était les moteurs de règles.
4 experts se sont succédés au micro lors de cette soirée :

  • Emmanuel Bonnet (Genigraph) a présenté les concepts de moteurs de règles et de BRMS.
  • Laurent Magnin (In Fine) a donné des exemples concrets d’utilisation, au travers des projets sur lesquels il est intervenu, des solutions JBoss BRMS/Drools et ILOG Websphere JRules.
  • Daniel Selman (IBM) a expliqué l’intéret et l’impact des moteurs de règles dans le cycle de vie d’une application, pourquoi externaliser certaines règles, quel gain cela peut apporter et quelles limites il faut cependant maintenir afin de conserver une qualité de service. Il a également présenté les outils IBM Websphere JRules Rule Studio et Rule Team Server.
  • Geoffrey De Smet (Red Hat) a présenté son produit, Drools Planner, qui permet de résoudre des problèmes complexes via les moteurs de règles et des algorithmes heuristiques.

Limitées en durée (30 minutes chacunes), ces présentations faisaient office d’introduction au monde des BRMS. Il n’était pas question ici d’aborder le fonctionnement du moteur de règles ou sur les optimisations à apporter. On a tout de même pu voir quelques exemples de règles, notamment les différentes manières de les exprimer (tableaux, règles SI/ALORS, arbres, flows, …).

Concernant l’intérêt des BRMS, il est clair : elle permet de redonner de la visibilité et même la main au métier sur des applications qui tendent le plus souvent vers une « boite noire ». Deux avantages à cela : le fonctionnement de l’application est partiellement démystifié pour le métier, et le métier peut intervenir directement pour implémenter des règles trop complexes ou qui demandent des compétences qui sortent du périmètre du développeur.

Un autre avantage est que les outils d’édition de règles permettent de documenter les règles et de les présenter d’une manière la plus lisible possible. Cela permet de réduire la perte de connaissances liée au turn-over sur le projet.

L’utilisation de BRMS permet aussi de faciliter l’audit : on peut tracer les différentes règles appliquées, ainsi que les versions de packages de règles. Cela permet de comprendre pourquoi le résultat n’est pas celui que l’on a obtenu.

Malgré tous ces avantages, il y a tout de même certaines limites à l’utilisation d’un BRMS. Les règles suivent un cycle de développement similaire à du code classique : il faut les saisir dans un éditeur de règles, les packager, les tester, etc … Il est également nécessaire de les versionner. Les utilisateurs métiers doivent donc être sensibilisés à ces problématiques de gestion de version, avec potentiellement des conflits et des branch/merge à réaliser.

La phase de test est également nécessaire, si les BRMS répondent bien au besoin de rendre les règles lisibles, ils nécessitent malgré tout de structurer les règles afin de rendre les effets de bord plus faciles à identifier. Cependant les dernières versions de ces outils proposent également des outils de test. L’absence d’un développeur dans la mise en place de la règle ne signifie pas pour autant que les cas aux bords se résolvent seuls, et eux aussi nécessitent d’être testés avant déploiement.

Un autre mythe des BRMS a été cassé d’entrée de jeu : les BRMS ne scallent pas tous seuls. L’intégration d’un BRMS à une application est simple, mais faire en sorte que celui-ci supporte une montée en charge est plus complexe et nécessite une réelle connaissance de l’outils.

Ayant pu utiliser ILOG Jrules (d’avant le rachat d’ILOG par IBM et l’intégration de JRules dans la suite Websphere), je ne peux que confirmer : l’utilisation de JRules a permis de remonter une partie du travail des développeurs vers les analystes fonctionnels, de faire un reporting des règles vers les utilisateurs, …

Cependant un certains nombres de limites se sont imposées :

  • nombre de règles très important, en partie dû à un historique de plusieurs années
  • modèle objet complexe qui multiplie les conditions
  • absence de test exhaustifs.

Ces 3 points ont provoqués un certains nombres de régression lors de déploiements en production non-maitrisés.
De plus certains problèmes se sont posés, notament la gestion des versions, lorsque plusieurs versions peuvent entrer en conflit. Ainsi que l’utilisation de fonctions de manipulation de données, qui nécessitent tout simplement d’être codées en Java.

Malgré tout cela, la migration vers JRules de ce projet s’était révélée positive car les performances (débit et temps de réponse) ont été améliorées, ainsi que la souplesse et la visibilité sur la manipulation des données.

Globalement cette session du Paris JUG est restée très ciblée vers les personnes n’ayant jamais eu affaire à un moteur de règles et constituait une bonne introduction. Cependant elle ne présentait pas un réel intéret pour tous ceux qui ont déjà utilisés un de ces produits, même très rapidement.

Vous trouverez plus de détails et les slides des présentations sur la page du meeting : http://parisjug.org/xwiki/bin/view/Meeting/20101109

Présentation Data Grid au Paris JUG

Demain soir à 19h30 se déroule le traditionnel Paris JUG, événement réunissant la communauté Java parisienne autour d’un certain nombre de sujets d’actualité. Je précise pour les non initiés ;-)
Il est vrai que d’ordinaire nous ne postons jamais au sujet de cet événement car d’autres confrères le font très bien.
Cependant, il me semblait important de mentionner la présentation Data Grid qui me semble très intéressante et d’actualité dans un certain nombre de projets.

Qu’est ce que le Data Grid ?

Tous ceux qui sont confrontés à des problématiques de temps d’accès aux données ou de traitements massifs de ces données recherchent des solutions alternatives aux bases de données relationnelles.
Les Data Grid en mémoire permettent de clusteriser la mémoire d’un parc hétérogène de machines tout en fournissant un accès simple (clef valeur, ?QL, template d’objet) et transactionnel, à cet espace mémoire virtualisé.
Le stockage des données en mémoire est fiabilisé par un certain nombre de mécanismes et le Data Grid fournit les indispensables mécanismes d’intégration au SI dont, notamment, les bases de données existantes.
Lorsqu’on revient aux fondamentaux; j’aime considérer les technologies en identifiant leur impact sur les éléments matériels sous-jacents (CPU, mémoire, disque, réseau); on se rend compte que les technologies Data Grid fournissent une réponse très adaptée dans beaucoup de situations car les temps d’accès et la bande passante de la mémoire sont infiniment supérieurs à ce que peuvent proposer les disques.
Évidemment, on peut toujours payer très cher pour essayer d’atteindre les mêmes performances que la mémoire avec des disques spécialisés, mais le veut on ?
Oui me diront certains, ça rassure ! Mais c’est un autre débat et puis ces temps-ci, en période de crise, ça fait pas très classe ;-)

La base de données change de rôle

En tant que partenaire GigaSpaces, un des leaders de ce domaine, nous voyons de plus en plus d’entreprises de toute taille qui démarrent des études afin de choisir le Data Grid qui permettra à leurs projets stratégiques de gérer les problématiques de stockage haute-performance et de traitements de données.
Depuis un peu plus de 3 ans environ, une grosse partie de notre activité a été de concevoir avec nos clients, et mettre en production, des systèmes stratégiques fondés sur les technologies Data Grid. Non seulement ça marche, mais les performances sont au rendez vous :
– plusieurs dizaine de milliers d’appels par seconde
– des temps de réponse inférieurs à la milliseconde sur des réseaux classiques 1GB
tout çà sur une « lame » d’entrée de gamme à quelques milliers d’euros pièce.

Lorsqu’on voit la prolifération d’offres alternatives aux bases de données relationnelles, il est désormais clair que le rôle de la base de données est en train de changer (ou a déjà changé pour certains) dans le système d’informations.
La base de données a imposé son hégémonie dans nos systèmes d’information depuis des années et a fait la richesse de certains acteurs du secteur, mais il est désormais acquis que la base de données ne peut pas monter en charge sans faire la richesse des vendeurs de matériel.
D’ailleurs, curieusement, dans certains cas, ce sont les mêmes ;-)

Le Data Grid s’est donc imposé avec le temps; projet après projet, secteur d’activité après secteur d’activité comme la solution alternative à la base de données, notamment lorsque celle ci se trouve sur le chemin critique des transactions.
Des pionniers de ce secteur comme GigaSpaces martèlent ce message depuis une dizaine d’années maintenant.
D’autres utilisateurs et fournisseurs d’infrastructures massivement distribuées ont utilisé un certain nombre de concepts  d’informatique distribuée sous-jacents aux technologies Data Grid dans leurs infrastructures internes.
Je pense notamment à Google, Amazon, Facebook qui n’ont pas eu le choix, pour des raisons économiques que de créer des alternatives pour stocker et exploiter de manière efficace leurs données.
Comme il faut rendre à César ce qui appartient à César on peut même dire que ces acteurs incontournables du Web poussent à leurs limites les technologies traditionnelles et dans certains cas poussent (ou tirent comme vous voulez) l’innovation. Le concept MapReduce a été popularisé par Google par exemple.

Le Data Grid, la boite à outils pour le traitement massif de données

Lorsqu’il m’arrive de présenter GigaSpaces, je fais souvent l’analogie entre GigaSpaces et les concepts sur lesquels s’appuient ces énormes infrastructures en indiquant que GigaSpaces peut être vu comme une technologie permettant de productiser, et rendre accessible de manière simple un ensemble de concepts d’informatique distribuée.
Cela nous permet à nous, architectes et développeurs, d’avoir les outils permettant d’assurer la performance et la scalabilité de nos applications distribuées.
D’ailleurs à ce propos, je voudrais mentionner cet article qui explique bien un certain nombre de principes de l’informatique distribuée : http://www.hfadeel.com/Blog/Files/ArtofDistributed.pdf tels que les concepts de Grid Computing, de Master Worker ou de MapReduce.

Au delà de la gestion des données en mémoire, de manière fiabilisée et très performante, le Data Grid permet de paralléliser les traitements sur les données en permettant l’implémentation de patterns tels que Master Worker ou Map Reduce.

Les capacités du Data Grid sont multiples, les technologies Data Grid sont matures (car d’autres ont débuggé pour vous, vous savez ce que c’est ;-) ), et les cas d’utilisation foisonnent, tous secteur d’activités confondus.

Voilà, j’espère que je vous aurai donné envie de venir assister à cette présentation Data Grid si vous n’étiez déjà convaincus, et je serai présent ainsi qu’un certain nombre de nos consultants (dont Jean-Michel qui participe à cette présentation) pour discuter de tout çà avec vous.

Pour venir : http://www.jugevents.org/jugevents/event/16041
Les détails de la présentation : http://www.parisjug.org/xwiki/bin/view/Meeting/20090512