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

41PARTAGES

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

Une erreur dans cette actualité ? Signalez-le nous !

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 +
4  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 confirmé 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 piklein
Futur Membre du Club 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 ?
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 chevronné 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