Maintenant que j’ai une application In Memory Data Grid en production, je n’y crois plus, je dirais plutôt que la RAM, c’est comme les spectacles d’assiettes chinoises au cirque

This is RAM !

J’ai eu la même impression que toi il y a un an. Nati Shalom (Gigaspaces) m’a convaincu et je pense aujourd’hui que les In Memory Data Grids (IMDG) resteront « in memory » sur la niche de l’hyper-performance alors que le NoSQL « sur disque » prendra le non-relationnel à performances normales et les fortes volumétries (BigData). Les cultures disque et mémoire sont trop différentes.

Nous demanderons à Nati de nous expliquer sa motivation fin Janvier lors de la soirée « Concevez une application Data-Grid/NoSQL hautement scalable avec Nati Shalom, fondateur et CTO Gigaspaces » qui dérape sur le planning mais aura bien lieu. Merci de votre indulgence pour ce retard

Pourquoi je pense que les In Memory Data Grid et les NoSQL ne convergeront pas :

* Dans le monde relationnel, les base de données mémoire (TimesTen, SolidDB, …) n’ont pas convergé avec les bases de données classiques sur disque.

* Les In Memory Data Grid sont cantonnées à un marché de niche du fait de leur coût et complexité d’utilisation. Très grande complexité aussi bien côté DEV que côté OPS :
** DEV : bouleversement culturel de mettre du traitement au coeur de la donnée, défi de l’évolutivité des données (POF en Coherence, etc), difficulté des tests, …
** OPS : manager des dizaines de petites JVMs (ca devrait changer bientôt …), perpetuel défi du full GC qui prend trop de temps, déploiement noeud après noeud pour ne pas avoir à recharger les données, …
** DevOPS : le chargement ‘initial’ de la grille qui n’arrive pas qu’une fois car les déploiement dans la vraie vie se font en général par un arrêt complet. Cette réalité interdit les scénarios d’IMDG de centaines de Go au commun des mortels.

* Les IMDG actuelles (Coherence, Gigaspaces, Gemfire & Websphere eXtreme Scale) n’ont pas été designées pour supporter la lenteur d’un accès disque lors de leurs traitements. Elles ont été designée pour l’hyper vitesse. Oracle a trouvé une solution d’offload avec des SSD.
** L’offload SSD des In Memory Data Grid est une sorte de « panic button » pour éviter la perte de données des OutOfMemoryError, l’esprit de ces produits n’est pas de faire du traitement sur ces données offloadées. L’offload SSD n’est pas un mécanisme de pagination, c’est une sécurité.
** Un cas où l’offload SSD trouve sa place en fonctionnement nominal interactif : quand l’IMDG est utilisée en « distributed cache » mais étant donné le prix et les complexités d’exploitations, je regarderais alors des grosses distributed hashtables (Riak, Redis, etc).

Pour résumer, je pense que
** Le NoSQL « sur disque » traitera BigData et le non relationnel « classique« , le non-relationnel qui n’a pas besoin d’hyper performance,
** les IMDG vont rester cantonnées à un marché de niche de l’hyper performance (finance de marché, ecommerce à très fort traffic pour encaisser Cyber Monday, …).

Nous pourrons en rediscuter plus en détails avec Nati Shalom en Janvier !

Cyrille qui a codé du Coherence ce matin encore

On en avait déjà parlé au NoSQL UG (et on a eu des présentation Gigaspace), les problématiques techniques sont, à la base, essentiellement les mêmes, sauf que :
– dans les DataGrid, on remplace les tuyaux réseaux par des bus mémoire
– les interfaces programmatiques sont, en générale natives Java (au lieu d’API REST ou protocole/couche transport)
– on met les machines les plus proches les unes des autres, pour avoir des tout petits bus super rapides

L’écart semble se réduire entre data grids et bases NoSQL (bien qu’il y ait des éléments de différenciation) comme l’exprime bien Manik Surtani dans le post suivant:

Enterprise Caches Versus Data Grids Versus NoSQL Databases – myNoSQL
http://nosql.mypopescu.com/post/14129808043/enterprise-caches-versus-data-grids-versus-nosql

Il est vrai que Gemfire avait déjà commencé (IMHO) à bousculer cette frontière…

J’adore le bavardage de geek. Et la plupart des personnes qui suivent le blog de Xebia aussi je pense.

Le « bavardage de geek », comme vous dites, c’est une confrontation de points de vue sur des technologies. Si on ne s’intéresse pas aux technologies, mais uniquement aux usages que l’on prévoit, alors il n’y aurait jamais d’innovation technique, mais uniquement des innovations marketing.

Il est impossible d’être architecte logiciel sans aimer le bavardage de geek (c’est une condition sine qua none).

Le NoSQL n’est pas un produit ou une solution, mais un mouvement, un ensemble de technologies de persistances (il me semble que l’article est clair la dessus), qui ont uniquement en commun d’essayer de ne pas respecter la contrainte d’être des SGBDR, et qui, bénéficient grâce à cela de caractéristiques intéressantes, comme :
– de meilleures performances
– une tolérance au partitionnement réseau
– une meilleure adéquation entre la technologie et le besoin de persistance

Le reste c’est du bavardage de geek !

J’y redis, en partie, ce que j’ai déjà dit plus haut.

D’autre part, avant l’étape du remplacement de la base du back-end tiers, je défends l’introduction/l’usage des bases NoSQL en les « définissant » comme bases à utiliser pour le middle tiers.

* Etape_1 : une base NoSQL pour le middle tiers et une base SQL pour le back-end tiers (voir qques exemples d’usage dans mon post).

* Etape_2 : la base NoSQL du middle tiers « monte en puissance » et éventuellement, remplace même la base du back-end tiers.

Selon moi, cette famille de base de données NoSQL est la plus complexe à maitriser car il s’agit d’une manière de modéliser les données totalement différente. Je reviendrai sur ces problématiques dans un article à venir.

Michael Figuière (Xebia)

Clairement les indexes Lucene ne sont pas une solution de persistance à part entière. En effet, bien qu’il soit possible d’utiliser certains champs pour le stockage via Field.Store.YES, leur utilisation doit idéalement être restreinte au stockage d’informations nécessaire pour retourner les résultats d’une recherche à l’utilisateur.
L’implémentation de ces indexes a été pensée avant tout pour la recherche et ne les rend guère adaptés aux problématiques de base de données :

* Les données insérées dans l’index n’apparaitront pas à la lecture avant la prochaine opération IndexReader.reopen(). Et à moins d’utiliser le mode near-realtime introduit dans Lucene 2.9, il sera également nécessaire d’effectuer une opération commit() sur l’IndexWriter ou de le fermer.

* Toutes ces opérations sont couteuses en temps car Lucene est optimisé pour favoriser la latence de recherche et non celle d’indexation.

* L’opération updateDocument() de Lucene consiste en une suppression puis un ajout de document. Ceci n’est pas réellement gênant dans un contexte d’index de recherche, mais l’est pour une utilisation de type base de données puisque l’opération n’est pas atomique.

* Les 3 points précédents montrent que l’indexation ne peut être assimilée à une opération d’insertion dans une base de données.

* Les documentId de Lucene ne sont que des identifiants propres à Lucene qui changent au cours du temps, par exemple lorsque les segments d’index sont mergés. Il sera donc nécessaire de définir un champs Id spécifique dont la valorisation devra être gérée par le code applicatif.

* Lucene n’offre pas de mécanisme de réplication. Solr et Hibernate Search proposent une réplication asynchrone, du master vers les slaves, qui introduira une latence de plusieurs minutes entre l’indexation d’un document et son apparition dans les résultats de recherche, ce qui là encore est parfaitement acceptable pour un index de recherche mais probablement pas pour une base de données.

Cette liste, non exhaustive, montre que les indexes Lucene ne peuvent être considérés comme une solution de persistance à part entière.

Michael Figuière (Xebia)

Merci pour cette réponse.

Oui, je comprends et j’avais déjà identifié JBoss Infinispan comme concurrent de Oracle Coherence, JBoss Infinispan dont la roadmap est effectivement prometteuse.

Reste que, qui peut le plus peut le moins, et quelqu’un va bien finir par s’apercevoir qu’il y a déjà beaucoup de chose dans Cassandra et que ce serait intéressant de partir de là pour offrir une (autre) offre de grilles de données ; plutôt que de réaliser un développement de zéro, comme Hazelcast par ex (autre fournisseur d’une grille de données, mais avec une « force de frappe » largement inférieure à Oracle ou Red Hat).

@Lorber Sebastien: En effet les différents acteurs du monde du NoSQL s’accordent à bien définir ces technologies en tant que « Not Only SQL » et non en tant que « No SQL ». Ainsi Facebook, le créateur de Cassandra, possède également l’une des plus grosse installation Memcached+MySQL au monde. Il s’agit donc clairement d’utiliser la bonne solution de persistance pour chaque type de données, le tout bien sûr en tenant compte des contraintes d’exploitation que les entreprises connaissent dans le monde réel…

@Fanf: Ces arguments en faveur de LDAP sont en effet tout à fait louables. Je pense que LDAP n’est pas considéré parmi ces options de stockage alternatives liées au NoSQL en raison de sa complexité d’une part et de sa nature read mostly d’autre part. En effet un annuaire LDAP n’est pas la solution de stockage adaptée à des données qui évoluent régulièrement. Cassandra, Riak ou encore MongoDB se comportent très bien avec des ratios de lectures / écritures différents.

@Dominique De Vito: Johnatan Ellis, le projet leader de Cassandra, affichait lors de la conférence de meilleurs performances en écriture qu’en lecture pour Cassandra. Les retours de Twitter sur Cassandra, où encore l’utilisation qu’en fait Digg, tendent à montrer qu’il est raisonnable de le considérer comme un stockage globalement tolérant à divers types de ratio lecture / écriture. En outre, notons que les performances de Cassandra sont en évolution permanentes depuis plusieurs versions.
Les retours d’expérience sur Cassandra suivront dans d’autres articles la semaine prochaine. Et idéalement nous publierons quelques retours de nos propres expérimentations plus tard sur ce blog.

En ce qui concerne la comparaison à Oracle Coherence et aux datagrids de manière générale, il apparaît que les cas d’utilisations sont différents bien que se recoupant légèrement. En effet Coherence est adapté au stockage d’information en mémoire, et bien qu’il offre des mécanismes optionnels de persistance sur disque ou dans un SGBDR lors de chaque écriture, il semble raisonnable de le considérer plutôt comme une solution de persistance non durable, et donc mieux adapter aux données live.
L’alternative Open Source comparable à Coherence me semble plutôt être JBoss Infinispan, évolution de JBoss Cache en datagrid, dont le project leader affiche des objectifs très ambitieux.
On peut considérer ces nuances de catégorisation des solutions de persistance comme minimes, mais vu l’importance capitale de cette problématique en entreprise, il est intéressant de pouvoir trouver des produits répondant très exactement au besoin requis, lorsqu’une telle exigence est de mise.

Michael Figuière (Xebia)

imho, Cassandra se rapproche de plus en plus d’une grille de données comme Coherence.
Cassandra inclut des tables de hachage distribuées, partitionnement, haute disponibilité/tolérance aux pannes, map, reduce, select, etc.

J’ai lu/recu des avis divergents à ce sujet :
- Certains indiquant que Cassandra fonctionne bien avec un ratio lecture/écriture de 10, voire plutôt de 100 et que Cassandra devait être envisagée uniquement pour des To de données (MySQL Cluster pouvant être utilisée quand il s’agit de traiter des Go).
- D’autres indiquant que Cassandra fonctionne bien aussi quand ce ratio n’est pas atteint, et même pour des Go, voir http://linuxfr.org/2010/04/16/26743.html

Perso, je crois que la techno Cassandra devrait/va finir par se rapprocher encore plus du fonctionnement d’une grille de données, et pourrait être envisagée comme alternative à Oracle Coherence.

Quel est votre avis à ce sujet ?
Merci

Avez-vous évalué Cassandra ?
Sous l’angle d’une grille de données ?

Il y a un non-dit dans le domaine des bases de données.
Ce non-dit concerne : les bases de données objet !
Apparemment, elles sont frappées d’ormeta.

Pour moi, la situation est claire : les bases NoSQL, voire les data grids, sont, en gros, un revamping des bases objet !

Détaillons la situation:
* Les bases NoSQL clé-valeur = stockage BLOB d’une base objet
* Les bases NoSQL orientées document = stockage normal d’une base objet
* Les bases NoSQL orientées colonnes = stockage colonne d’une base objet
* Les bases NoSQL orientées graphe = stockage normal d’une base objet

Idem, une data grid = espace de stockage objet + trigger + requêtage possible (select)
Une data grid, c’est, pour moi, une base de données objet distribuée sans mécanisme transactionnel (encore que cela va arriver dans la v3.6 de Oracle Coherence).

On réinvente la roue, mais sous une forme légèrement différente, et avec une autre nom.
Et cela fonctionne mieux car on ne prend que les fonctionnalités/contraintes qui répondent à tel ou tel besoin.

Je rejoins donc « Fanf » quand il indique de ne pas passer à la trappe les annuaires LDAP dans cette affaire !

Et je m’étonne, et je trouve dommage, que les fournisseurs d’annuaires LDAP et de base objet n’aient pas senti le vent tourner pour revamper leurs solutions, en solutions NoSQL…

Voici un exemple de cas d’utilisation mixte SGBD/ »NoSQL » dans la vrai vie: http://debasishg.blogspot.com/2009/12/case-for-hybrid-sql-nosql-stack.html
Et de façon plus générale, un exemple de système hétérogène: http://debasishg.blogspot.com/2010/01/new-way-to-think-of-data-storage-for.html

@Xebia: une remarque: on oublie systématiquement les annuaires LDAP comme base de données NoSQL. Pourtant, ils ont de nombreux avantages, qui complètent bien le paysage (typiquement, pour les parties API publiques, avec pourquoi pas de la gestion de droits complexes, vu que c’est donné):
- ils ont une organisation semi-structuré en arbre, avec des schémas pour les entrées (donc à mi-chemin d’une base de données orienté document et d’une base orientée graphe),
- LDAP est un protocole normalisé, répandu et pour lequel il existe au moins un client/une bibliothèque pour chaque langage/OS/etc,
- les annuaires ont des années d’existence et de débuggage derrière eux,
- ils ont été parmi les premiers à faire pencher le compromis performance/complexité des requete vers les premières : un annuaire OpenLDAP sur un serveur correct a permis de créer une base de 6 *milliards* d’entrées, avec des dizaines de milliers de requêtes par secondes traitées – malheureusement pas de sources sur le sujet, les plus récente que je trouve date d’une éternité (2006), mais restent parlantes: http://www.openldap.org/pub/hyc/LDAPcon2007.pdf ).

Bémols: pas de transaction, pas de langage de requêtes avec join – mais apparemment, depuis que le mouvement NoSQL prend de l’ampleur, on se rend compte que le trade-off peut être intéressant.

Pour continuer dans l’ouverture