Discussion :

[Gordon Fowler]

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)

Trouvez-vous cette refcard utile ?

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 :

Twitter adopte la base de donn�es Cassandra
Le mouvement anti-SQL s�amplifie-t-il ?

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

MySQL
PostgreSQL
Et tous les SGBD

[Hayaxx]

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

[Traroth2]

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...

[saad.hessane]

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.

[subzero82]

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.

[Emmanuel Lecoester]

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 )

[hgomez]

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.

[Hayaxx]

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)

[metagoto]

�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.

[pseudocode]

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 )

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.

[kervoaz]

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.

[pseudocode]

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.

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.

[dillinger91]

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.

[B.AF]

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.




�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.

[bugsan]

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.

[deadalnix]

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

[Faiche]

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

[saad.hessane]

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.

[clavier12AZQSWX]

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.

[Patriarch24]

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 ?