Des développeurs vous offrent une méthode d'utilisation de NoSQL, cette technologie est un must ou une mode ?

Mise à jour du 09.07.2010 par Katleen
Des développeurs vous offrent une méthode d'utilisation de NoSQL, cette technologie est-elle un must ou un feu de paille ?

Une équipe de développeurs passionnés (du site DZone) vient de publier une carte de référence intitulée "Débuter avec NoSQL et l'extension de données".

Les bases de données NoSQL (et les technologies opérationnelles sur les données associées) sont en effet désormais incontournable pour les développeurs web. Elles sont largement utilisées pour les grandes boutiques en ligne et commence à se faire une place dans les infrastructures IT.

Donc, cette carte de référence est là pour aider les professionnels à se poser les bonnes questions concernant les implémentations spécifiques de NoSQL ; tout en apportant les outils de base pour identifier les différentes technologies NoSQL et les utiliser.

Source : Getting Started with NoSQL and Data Scalability (PDF)

:fleche: Trouvez-vous cette refcard utile ?

:fleche: Pensez-vous qu'un développeur doive maîtriser le NoSQL, ou bien n'est-il qu'une mode passagère ?

Faut-il en finir avec la mode NoSQL ?
Ou est-ce plus qu'une simple mode passagère ?


La question est volontairement provocante. Elle est posée, en des termes encore plus crus, par Ted Dziuba dans un billet intitulé « I Can't Wait for NoSQL to Die ».

« Certains ingénieurs pensent que l'évolutivité et l'architecture sont la solution [de tous les problèmes]. C'est comme cela qu'est né le mouvement NoSQL », y écrit-il. « L'idée développée avec NoSQL est que toutes les bases de données relationnelles, telles que MySQL et PostgreSQL, sont caduques et que les bases de données fondées sur des documents ou les bases de données sans schéma représentent l'avenir».

Une position qui irrite visiblement l'auteur pour qui NoSQL est avant tout (pas que, mais avant tout) un effet de mode : « Peu importe bien sûr que MySQL ait été la solution parfaite pour absolument tout jusqu'à très récemment […] Peu importe que de véritables entreprises stockent toutes leurs données dans de vraies bases de données SQL, (pour les lecteurs de la Silicon Valley, Walmart (NDR : équivalent de Carrefour) est une vraie entreprise, pas Twitter) », aujourd'hui, MySQL serait injustement éclipsé par NoSQL.

Dans le cas d'une montée en charge liée à une forte utilisation, Dziuba explique que la solution fondée sur MySQL peut rencontrer quelques problèmes de performances et qu'« à ce stade, un développeur qui valorise la dernière technologique à la pointe plaidera en faveur de "réécrire le tout en un week-end avec Cassandra" .[...] Et donc, comme par magie, vous avez changé votre stockage de données de MySQL à Cassandra ».

Tout devrait mieux fonctionner.

« Eh bien, non ! Saviez-vous que Cassandra nécessite un redémarrage lorsque vous modifiez la définition d'une colonne dans une table ? Et oui, les développeurs de MySQL avait effectivement réfléchi à la façon de mettre en œuvre un ALTER TABLE, mais pour Cassandra c'est un problème difficile car cela représente bien peu de cas ».

Et Ted Dziuba d'en conclure que NoSQL n'est certainement pas la solution miracle que certains voudraient faire croire. Migrer d'une solution MySQL à une solution NoSQL reviendrait plutôt à « échanger une liste de limitations et de bugs connus pour [...] une liste de limitations et de bugs inconnus ». Avec un risque énorme pour l'entreprise.

Et c'est bien là où le bât blesse. Car se bercer d'illusions sur NoSQL et mal cibler les besoins de la majorité des sociétés pourrait être très dangereux : « Développer une application à une échelle comparable à celle de Google est un gaspillage de votre temps. […] Ce n'est pas que vous n'êtes pas assez intelligent pour le faire, c'est que vous n'avez pas l'expérience suffisante pour savoir quels problèmes vont se poser à cette échelle ».

Seul Google aurait donc besoin de solutions NoSQL ? A en croire Ted Dziuba, même pas.

« [Saviez-vous] que Google AdWords est implémenté sur une base MySQL ? Le cœur de métier le plus critique de Google[...] n'utilise pas BigTable? Et non. En fait […] Google identifie les problèmes avec InnoDB et applique des correctifs au lieu de dire "MySQL n'est pas bon à cette échelle, il faudrait le remplacer par autre chose" ».

Alors quel avenir pour NoSQL ?

« NoSQL ne mourra jamais », nous rassure Ted Dziuba. Pour mieux ré-attaquer : « mais il finira par devenir marginalisé, de la même manière que Rail a été marginalisé par NoSQL ».

Une prophétie qui, on s'en doute, ne trouvera que peu d'échos positifs dans la communauté NoSQL.

Mais alors, qui croire ?

Le chant prometteur des sirènes du NoSQL ? Ou l'humour doux-amère du très septique Ted Dziuba ?


Source : Le billet de Ted Dziuba


Lire aussi :

:fleche: Twitter adopte la base de données Cassandra
:fleche: Le mouvement anti-SQL s’amplifie-t-il ?

Les rubriques (news, tutos, forums) de Developpez.com :

:fleche: MySQL
:fleche: PostgreSQL
:fleche: Et tous les SGBD

Personnellement, je n'ai pas encore expérimenté le NoSql et je me demande encore comment construire une architecture solide sans le modele relationnel :?.

Mais de ce que j'ai pu apprendre sur le mouvement NoSql, il ne vise absolument pas a contrer MySql, mais a proposer des alternatives pour des cas particuliers.

Je ne pense pas que ce soit une menace mais plutot un complément.
Ça me rappelle un peu Windows vs Linux... J'aimerai croire que Linux prendra le dessus sur windows très bientôt, mais cela reste un systeme en marge face à Windows qui est bien assis sur ses positions. Je trouve que c'est comparable à MySql vs NoSql...

Néanmoins j'espère avoir l'occasion de tester ces bases pour m'en faire une idée plus juste :ccool:

Personnellement, j'ai l'impression que les services qu'on attend de ces nouveaux systèmes de persistance, c'est essentiellement des trucs gérés en principe par des surcouches de la base, comme la réplication de données.
Quant au langage SQL proprement dit, je ne comprends pas ce qu'on lui reproche. Ces nouveaux systèmes (pas encore eu le temps de trop regarder) doivent bien avoir un langage d'interrogation eux aussi. SQL marche très bien et permet de gérer tous les cas. Ça revient à réinventer la roue. Je dis ça, car j'ai vu quelque part comme justification au NoSQL que SQL serait "difficile à apprendre". Pas évident qu'un nouveau langage d'interrogation soit plus simple. Personnellement, je fais partie des gens qui pensent que l'informatique, c'est un métier...

Cela dit, le mouvement NoSQL est intéressant dans le sens où il permet peut-être de faire émerger de nouvelles idées de fonctionnalités à intégrer aux SGBD. Toute idée est bonne à prendre. Mais sinon...

Moi je pense que la concurrence c'est bien, et que tout le monde aille dans la même direction c'est mal. Oui SQL est super, oui il est simple à apprendre, oui les bases de données modernes offrent des mécanismes d'optimisation du parsage et de l'exécution de la requête. Mais il faut laisser la chance à d'autres idées émerger.
Et pour info, il y a plusieurs cas où l'utilisation du SQL n'est pas judicieux, comme le développement pour mobile par exemple.

Je suis de l'avis de Hayaxx. Beaucoup prennent NoSQL pour un groupe de névrosés qui remet en question les bases de données conventionnelles en totalité.

En fait, cela n'est pas vrai. L'objectif est de faire bouger les choses dans le monde des bases de données. Ces dernières années les leaders du marché des BDD se sont endormis sur leurs lauriers.

On remarquera une sorte de stagnation d'un point de vue architecture interne et capacités de traitement.

NoSQL tente de faire bouger les choses et répondre aux nouveaux besoins qui ne sont pas supportés sinon de manière bizarre dans les bases de données conventionnelles. Exemple :
- interrogation de documents structurés. Beaucoup diront que cela est déjà supporté. Mais dans les faits c'est tout autre chose.

De manière plus générale, NoSQL vise à faire avancer les choses sur 2 points :
- Monté en charge à terme totalement synchrone ;
- stockage, indexation et interrogation d'entités complexes ; telles que des images, vidéos, cartes routières, etc.

NoSQL versus SGBDR ? C’est à la mode en effet !

Maintenant c'est une mode, les SGBDR existent depuis bien plus longtemps donc attendons que la mode soit passée.

Ces idées ne viendraient-elles pas aussi du fait que l'espace disque coute de moins en moins cher et que donc d'avoir des données totalement dénormalisées revient dans l'air du temps (bientôt on aura des fichiers texte :aie:)

Pourquoi est-ce que NoSQL serait une mode ?

N'est-ce pas tout simplement une réponse possible dans l'aspect persistance ?

Je me rappelle d'une époque pas si lointaine ou le stockage et la persistance n'utilisaient pas des SGBR. Et je ne parle pas d'applications personnelles en environnements pré-web 1.0, mais de solutions professionnelles utilisées par exemple dans des environnements financiers (boursier ou bancaire).

Pendant longtemps on concevait avec des modèles mixtes, mélangeant stockage mémoire et disque, par exemple avec des systèmes ISAM.

Et puis et arrivé le SQL qui permettait de tout stocker et de définir, à postériori tout champ comme clé d'accès à l'information, avec bien évidemment les dérives connues de lazzy indexing.

Et on s'est donc mis à chercher plus seulement par les colonnes principales, mais par tout champ présent dans une table.

Pire on a monté ceci en paradigme suprême, le SQL permettait tout.

Je pense sincèrement que l'initiative NOSQL est un retour à des sources plus saines et quelque part plus pertinentes.

A ceux qui doutent de l'applicabilité de NOSQL dans leur environnement de travail de tous les jours, je demanderais juste que se demander qu'elles soient les clés d'accès aux informations que leur processus traitent tous les jours ?

Un identifiant client, un code valeur ISIN, une référence d'article ?

Est-ce que ce type d'information ne pourrait être pas stocké en NOSQL avec une réconciliation dans la partie applicative (Java, C/C++, .NET) ?

Il serait bon que les plus âgés parmi les réfractaires à NOSQL se rappellent qu'ils ont produits des applications et solutions avant que les SGDBR n'envahissent nos contrées et ne se répandent dans l'esprit des développeurs puis des utilisateurs.

NOSQL est une approche pertinente et efficace dans de très nombreux cas d'applications, où souvent un SGDBR est sur/sous-utilisé par rapport au besoin réel en terme de persistance.


Bien amicalement.

Voila un article tres clair sur les principes et les buts du NoSql pour ceux qui n'en auraient pas trouvé : http://5.freshminutes.it/2010/02/17/...Java%2B&%2BIT)

Ça me rappelle un peu ce qui s'est passé avec l'arrivée de l'OOP (même si je n'étais pas né ), de java, de ruby on rails, etc. (et plus tard, le Cloud).

Beaucoup de hype, des success-stories, des échecs et puis finalement les choses se tassent. La raison l'emporte.

Les solutions "NoSQL" ont leur rôle à jouer, tout comme le reste.

Citation:

---

Envoyé par Emmanuel Lecoester

Ces idées ne viendraient-elle pas aussi du fait que l'espace disque coute de moins en moins cher et que donc d'avoir des données totalement dénormalisées revient dans l'air du temps (bientôt on aura des fichiers texte :aie:)

---

Oui, l'espace disque est une des raisons.

Mais il faut remonter aux origines de ce problème :

1. la durée de rétention des données

et son corolaire :

2. la volumétrie des données stockées

et finalement son impact :

3. la performance d'accès en fonction de la volumétrie

La durée de rétention est généralement infinie. C'est rare les gens qui acceptent que leurs vieilles données soient purement et simplement inaccessibles => on garde tout, que ce soit les pages indexées par Google, les messages du forum, les photos/mp3 sur son PC, ...

Le corolaire c'est que la volumétrie est en augmentation constante. D'ou le problème d'avoir des espaces de stockages de plus en plus gros (et donc ta remarque sur le prix des DD). Et finalement, la performance d'accès a ces grosses quantités de données.

Et c'est la que, pour moi, il y a une différence entre SGBD et NoSQL :

- Pour améliorer la performance accès/volumétrie d'un stockage SGBD, il faut modifier le SGBD (algos, architecture, schéma)

- Pour améliorer la performance accès/volumétrie d'un stockage NoSql, il faut ajouter de nouvelles machines.

Bonsoir,
Plus j'essaie de comprendre le NOSQL et moins je le comprends.
En regardant de loin ( Memcached ) le but de redis ou memcached, je ne vois pas de quoi à casser 3 pattes à un canard. Memcached est .. un cache de données. La belle affaire. Les sgbd dignes de ce nom, Oracle par exemple, gère le cache avec des algorithmes pointus de LRU. Toujours pour Oracle, on trouve RAC(oracle cluster) où le cache est "partagé"(echangé) entre serveur ou bien TimesTen (Oracle in memory avec fusion de cache pour l'écriture). Pourtant, ces produits sont classés dans les SGBDR.
Enfin l'exemple, toujours
Memcached, me semble être simplement de la bonne pratique de développement: je crée très souvent des tableaux de données issues de requêtes SQL lorsque je dois accéder souvent aux mêmes informations. Cependant, lorsque l'on a mis "trop" de données en cache sous forme de tableaux/hashmap, on est obligé de faire des boucles, des if pour rechercher la donnée pertinente. Il arrive un seuil où il est préférable(= plus performant) de demander au SGBD de nous trouver lui même nos données, avec ses propres algorithmes optimisés et...avec une bonne vieille requête SQL.

Bon cela dit, les Hashmap ne sont qu'un type de NOSQL, je vais essayer de comprendre les autres.

Citation:

---

Envoyé par kervoaz

Bonsoir,
plus j'essaie de comprendre le NOSQL et moins je le comprends.
En regardant de loin(wikipedia) le but de redis ou memcached, je ne vois pas de quoi à casser 3 pattes à un canard. Memcached est .. un cache de données. La belle affaire. Les sgbd dignes de ce nom, Oracle par exemple, gère le cache avec des algo pointus de LRU. Toujours pour Oracle, on trouve RAC(oracle cluster) où le cache est "partagé"(echangé) entre serveur ou bien TimesTen(Oracle in memory avec fusion de cache pour l'écriture). Pourtant ces produits sont classés dans les SGBDR.

---

:arrow: Memcached's APIs provide a giant hash table distributed across multiple machines.

Le mot "distribué" est important. A ne pas confondre avec "partagé/échangé".

Distribué signifie que chaque machine contient UNE PARTIE seulement des données (parfois en doublon avec une autre machine). Et que l'algorithme d'accès au cache permet de trouver les données, sans pour autant avoir besoin d'avori la liste exhaustive des machines et des clés présentes sur ces machines.

Moi je ne comprend pas trop en quoi le NoSql dérange.
On a bien plusieurs paradigme de programmation, encore plus de langages
Je rejoins donc les quelques avis précédant en disant que SQL est peut-être génial mais que ça n'empêche pas d'aller voir ailleurs ce qui se passe.
C'est un peu comme ça qu'on avance.
Au niveau des entreprises je ne vois pas en quoi NoSql ou tout autres façons d'aborder les données serait un risque.
Après tout si l'entreprise n'a pas assez de compétence dans ses rangs pour discerner les effets de modes des vraies solutions qui valent le coup ils finiront par se casser les dents un jour ou l'autre alors que ce soit sur ça ou sur autres choses le résultat ne sera pas forcément très différent.

2010, où l'informatique découvre que depuis qu'elle existe, la donnée n'a pas fait l'objet exclusif d'une base de donnée relationnelle implémentant SQL.


:mouarf:

Ça devient un grand nawak cette société de buzz.

Lire ce genre de truc sur le noSql, ça me fait l'effet d'une polémique sur Eric Zemmour : C'est tellement provocateur qu'on sent que c'est écrit pour seulement faire parler de l'auteur.

Mais les tautologies sur la mode est passagére (ouh ouh!), la migration entraine des effets de bords (ah ah!) et un développeur a une tendance a vouloir utiliser les technologies les plus récentes (eh eh!)...C'est un peu vide de contenu.

Je crois d'avantage aux bases de données produisant des résultats en XML.

Le tout objet n'a pas d'avenir pour les bases de données, tout simplement parce que dans 95% des cas les données extraites doivent être resérialisées dans un autre format (HTML, XML, PDF, etc...). Dans le cas d'une extraction de donnée, l'objet devient donc un intermédiaire contraignant.

Avec un peu de recul on se rend compte que les technologies OXM comme Hibernate, sont une réponse à une problématique mal formulée, surtout en ce qui concerne le Web. Avec la démocratisation d'ajax, de plus en plus de données sont transmises en XML, ce qui oblige les développeurs à utiliser deux technologie : Hibernate + JAXB/Json. On peut facilement virer les deux et remplacer par une base XML.

C'est vrai, mais XML, c'est massif et lourd. Ça ne conviendra pas à tous les usages.

Là où tout le monde se plante, c'est que NoSQL n'est pas le remplaçant de SQL mais le complément (NOSql = Not Only SQL).

D'abord, avant que vous n'ayez à vous poser la question de "oh, mon cluster de mysql comment à devenir compliquer à scaler horizontalement", vous avez de la marge. Seul les plus gros connaissent ce problème et ont dû trouver une solution.

Ensuite, la plupart de ces sites ont une partie de leurs bases en sql et d'autres dans différentes configurations. Facebook utilise HBase (de hadoop) pour ses logs et ses statistiques !

Evidemment, certains sont allé plus loin, comme Digg qui a remplacé sa base principale par Cassandra. Mais la grande majorité utilise un mélange des deux mondes.

Voila quelques liens pour vous aider à mieux voir le truc :
Les boites qui utilisent HBase, comment et pourquoi
Un exemple plus précis de pourquoi et comment Adobe utilise HBase (et le reste des produits hadoop, c'est dont la HStack)
Digg utilise Cassandra

Enfin, une série d'article pour comprendre comment marche Cassandra, c'est la stack NoSQL la plus avancée actuellement

Voila

Citation:

---

Envoyé par hgomez

Je me rappelle d'une époque pas si lointaine où le stockage et la persistance n'utilisait pas des SGBR. Et je ne parle pas d'applications personnelles en environnements pré-web 1.0, mais de solutions professionnelles utilisées par exemple dans des environnements financiers (boursier ou banquaire).

---

Cela est toujours le cas quand il faut maintenir une application vieille de 10 ans en COBOL, qui marche à merveille et qui n'utilise que des fichiers plats.

je pense qu'avant d'envisager de passer à nosql pour un souci de performance, il faut déjà passer de mysql à postgres, et de postgres à oracle/MS server et seulement en dernier recours abandonner le sql pour NoSQL.

C'est par parce que mysql ne tient pas la charge que les autres sgbrs ne le peuvent pas.

Je trouve quand même incroyable que certains pensent encore et toujours que SQL (et les bases de données relationnelles) seront la solution ultime de manière éternelle.
Il existe des domaines où ce n'est pas la panacée, et il existe des solutions bien plus performantes, n'en déplaisent aux fanatiques : déjà citée, la gestion de documents notamment. Pour autant, ces alternatives spécifiques à des métiers seront-elles généralisées ? Non SQL, ne disparaitra pas de sitôt, et oui, de nouvelles solutions vont continuer d'émerger. Et c'est tant mieux.
Je termine par le "buzz" NoSQL : le nom est volontairement provocateur, pour mettre en lumière le fait qu'il existe d'autres solutions, et cela permet aux gens de se poser des questions. Se remettre en cause, chercher des solutions optimales à nos problèmes, n'est-ce pas là une de nos compétence ?