IdentifiantMot de passe
Loading...
Mot de passe oubli� ?Je m'inscris ! (gratuit)

Vous �tes nouveau sur Developpez.com ? Cr�ez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et �tre connect� pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Cr�ez-en un en quelques instants, c'est enti�rement gratuit !

Si vous disposez d�j� d'un compte et qu'il est bien activ�, connectez-vous � l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oubli� ?
Cr�er un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

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

Le , par Gordon Fowler

340PARTAGES

1  0 
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
Vous avez lu gratuitement 10 articles depuis plus d'un an.
Soutenez le club developpez.com en souscrivant un abonnement pour que nous puissions continuer � vous proposer des publications.

Une erreur dans cette actualit� ? Signalez-nous-la !

Avatar de vosaray
Membre actif https://www.developpez.com
Le 02/02/2011 � 22:55
Tiens ca fait un bout de temps que j'ai pas vu de notif sur le sujet que je viens de relire.

Citation Envoy� par ezmac
ou je suis d�bile, mais si je ne me trompe pas SQL est un dinosaure du '92, et rien n'a chang� depuis,
Bon je ne vais pas tirer sur l'ambulance, mais que dire du C dans ce cas la ? Faut t'il remplacer toutes les couches natives �crites en C par un autre langage juste parce que le C n'a pas �volu� ?

Franchement, des fois il y a des paires de cla... pardon accolades qui se perdent :

Puis je vous donne une petite info vite fait : apr�s 1 an d�exp�rimentation sur les bases noSql, en l�occurrence CouchDB, j'ai jet� l��ponge pour plusieurs raisons :

1. performances m�diocres

Sur un volume de donn�es somme tout pas si gros que ca, mais pas ridicule non plus ( 800.000 documents d'environ 30Ko chacun ), les perfs ne sont pas au rdv.

Certains arguent que les perfs seront les m�mes pour un volume de donn�es gigantesque. Ok, presque vrai en terme de recherche, mais compl�tement faux en terme de mise � jour des index.

Donc si votre appli doit pr�senter des mises � jour de donn�es dans un temps relativement court, il faut trouver autre chose ...

2. consommation disque affolante !

Donc 0.8 millions de docs, 6 indexes �a fait 45Go sur le disque rien que pour les indexes .

Chaque index utilisant un (1, uno, one .. ) ficher. On se retrouve avec des fichiers de l'ordre de 9Go.

Je vous laisse imaginer la joie de l'append du fichier en question.

Et aussi m�diter sur le fait que cacher les indexes en RAM demande tout de m�me un budget plus que consid�rable.

3. pas adapt� � des "requ�tes applicatives"

Franchement on a beau tourner autour du pot, si votre appli pr�sente les donn�es dans un front-end classique, disons un tableau sortable sur plusieurs colonnes et un pager, le noSql ou en tout cas CouchDB il vaut mieux oublier.

Si vous voulez connecter un tel compo, qui est somme toute un grand classique du web sur une base CouchDb, alors il faut soit utiliser un produit d'indexage (avec le cout cpu/disque inherent) externe, soit cr�er un index par colonne et gerer un cache des cl�s (first,last) cot� appli.

Donc plus d'indexes = plus de disque et un temps de mise � jour peu acceptable, tout en consommant pas mal de CPU et d'I/O. De quoi franchement saturer votre syst�me (linux pour ma part).

Quant aux produits d'indexation externe, type Lucene, ca marche, mais la prise en compte des changements est assez lente et le tout consomme pas mal de ressources suppl�mentaires.

4. S�curit� ou est tu ?

Ok on peut s�curiser l'acc�s � la base via un login/mdp. Tr�s bien mais il n'y a rien pour s�curiser les droits sur les documents. Donc en gros vous acc�dez � la base, et vous pouvez voir tous les docs qui y figurent.

Acceptable si les donn�es n'ont pas de contraintes de "data privacy", compl�tement � cot� de la plaque si jamais une telle contrainte apparait dans votre appli ( ce qui fut mon cas )

Le sujet est effectivement complexe mais je trouve difficilement acceptable de ne pas y songer et de refuser d'avancer dans cette direction.

Quant aux "alternatives officielles" pour bypass cette contrainte elles varient entre la bidouille et le grotesque : une base par utilisateur r�sout le pb. disent les "experts". Non mais franchement ....

5. Equipe de dev, pourrais tu descendre de ton nuage ?

Euuh, franchement et tr�s subjectivement : l��quipe core est comp�tente sur plein de sujets, mais compl�tement born�e en terme de compr�hension du monde "applicatif", bref de ceux qui souhaiteraient utiliser Couch comme storage.

Il y a bein eu qq tentatives de patching pour aller dans le sens (par exemple le multi-view, une mani�re de combiner les index/vues pour fournir du multi crit�re) mais elles ont �t� isol�es jusqu'� ce que les contributeurs abandonnent leur id�e ou se d�sint�ressent du sujet ...

Ce type de comportement arrive sur pas mal de projets open source, mais je dois avouer qu'il est assez flagrant dans le cas de Couch.

Dommage je pensais que ce projet avait un avenir plus concret et ouvert en terme d�utilisation applicative ....

Conclusion :

Pour palier � tout ces maux, j'ai fini sur une solution hybride :

- tout ce qui concerne l'indexation, la recherche, la s�curit� & co => SQL
- storage des documents et r�plication/f�d�rations des donn�es => CouchDB

Bref j�utilise couchDb comme un disque partag� accessible par http . Tout mes indexes sont dans une base sql optimis�e.

Je commence vraiment � me demander � quoi me sert Couchdb car je pourrais aussi bien avoir des fichiers sur disque et les r�pliquer via un rsync ou autre syst�me du genre et y acc�der via un banal serveur http ...

Par ailleurs, l'id�e �tait de partir sur du CouchDB pour �viter les r�plications de bases SQL pas toujours performantes et pas toujours utilisables dans tous les cas de figure (full meshing par exemple ... ). De ce point de vue c'est rat� aussi ....

Bref, tentative peu concluante pour un cout humain toutefois consid�rable.

Donc le prochain qui me sort que SQL c'est fini je lui colle les deux accolades vite fait bien fait et je compile le tout en %F, nouveau langage d�riv� du Cb�mol7 et du Hmaj7 dans une suite A/D/A sur un rythme pseudo binaire ..
6  0 
Avatar de SQLpro
R�dacteur https://www.developpez.com
Le 01/07/2010 � 16:33
Quelques remarques<...

Citation Envoy� par ZashOne Voir le message
Et c'est pas bien ca ?
Selon moi, les temps de d�veloppement c�t�" base de donn�es sont plus rapides � mettre en place que du d�veloppemnt c�t� application.
Oui, lisez les �tudes de Paul Dorsey et Toons Koopelars sur le sujet. Y'a pas photo.

Citation Envoy� par B.AF Voir le message
Maintenir une appli faites quasi exclusivement de SQL c'est un vrai retour dans le pass� quand tu as gout� aux joies de langage plus r�cents.
Vous oubliez le point noir : les langages it�ratifs n�cessite un d�ploiement et une interruption de service m�me pour des serveurs d'objets, alors qu'avec du SQL toute interruption est inutile puisque le code est strictement dynamique !

Citation Envoy� par psychadelic Voir le message
c'est vrai que maintenir du SQL, surtout en proc�dures stock�es est une vraie gal�re.
L� vous plaisantez j'esp�re, c'est un probl�me de culture et donc de connaissance et formation...
Le code C#, Java est aussi abscons pour un n�ophyte que du SQL !
Mais l'avantage de SQL c'est qu'il est tr�s richement document�, ce qui n'est pas le cas des langages les plus r�cents !

Au total, je me demande si vous n'�tes pas des techno victimes comme il y a des fashion victimes ???

A +
5  0 
Avatar de piklein
Membre � l'essai https://www.developpez.com
Le 09/07/2010 � 12:45
Citation Envoy� par Katleen Erna Voir le message

Des d�veloppeurs vous offrent une m�thode d'utilisation de NoSQL, cette technologie est-elle un must ou un feu de paille ?


Un peu de failles ?
3  0 
Avatar de dillinger91
Membre du Club https://www.developpez.com
Le 09/04/2010 � 23:11
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.
2  0 
Avatar de clavier12AZQSWX
Membre �clair� https://www.developpez.com
Le 12/04/2010 � 9:38
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.
2  0 
Avatar de B.AF
Membre chevronn� https://www.developpez.com
Le 30/04/2010 � 13:06
Citation Envoy� par el_slapper Voir le message
et � maintenir? (je pose la question, je n'ai jamais eu le cas, mais j'ai des doutes)
Maintenir une appli faites quasi exclusivement de SQL c'est un vrai retour dans le pass� quand tu as gout� aux joies de langage plus r�cents.
2  0 
Avatar de Hayaxx
Membre du Club https://www.developpez.com
Le 09/04/2010 � 12:15
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
1  0 
Avatar de Traroth2
Membre �m�rite https://www.developpez.com
Le 09/04/2010 � 12:18
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...
1  0 
Avatar de Emmanuel Lecoester
Membre expert https://www.developpez.com
Le 09/04/2010 � 14:28
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 )
1  0 
Avatar de hgomez
Membre � l'essai https://www.developpez.com
Le 09/04/2010 � 14:41
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.
1  0