Des développeurs proposent une méthode d'utilisation de NoSQL
Cette technologie est-elle un must ou un feu de paille ?

Le , par Gordon Fowler, Expert éminent sénior
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 aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de pseudocode pseudocode - Rédacteur http://www.developpez.com
le 04/02/2011 à 17:42
Citation Envoyé par vosaray  Voir le message
Quand on a besoin de stocker, indexer et rechercher des données accèssibles par plusieurs applications ou entitiés, on pense très souvent à une BD pour ce faire.

On peut en discuter, mais en dehors de ce contexte je ne vois pas pour quelle raison utliser une bd ....

J'ai juste fait cette remarque par rapport à ta conclusion sur ta solution hybride.

Pas vraiement, Mongo ne supporte pas la réplication "meshed", uniquement le master/slave à la mysql.

Effectivement, je ne savais pas que tu avais des contraintes de ce type.

Pour conclure, je dirais que le NoSQL n'est pas un souci en soi. Raisonner en clés/valeurs est tout à fait accèptable. Cependant il faudrait :

- pouvoir combiner les vues de manière à effectuer des recoupements ( bref faire de la recherche un minimum multi criteria )
- proposer des fichiers index (vues) un minimum plus dimensionées et pas faire de l'append systematique.

Bref, se rapprocher du monde applicatif et du point de vue intégration plutot que de proposer des solutions, disons intellectuelement valables , mais dont le champ d'application reste très restreint

Il est certain que les base NoSQL sont pour l'instant uniquement des solutions techniques (à l'instar des bases SQL). Il n'y a pas encore vraiment de solutions applicatives clé-en-main.

C'est vrai que se construire un DataStore avec du NoSql ca nécessite à l'heure actuelle pas mal de plomberie, et ton système hybride me semble une bonne approche.
Avatar de vosaray vosaray - Membre actif http://www.developpez.com
le 05/02/2011 à 18:16
Effectivement , j'ai peut être fait un petit post, disons à vocation "thérapeutique" histoire que "ça" sorte.

Du coup les idées sont peut être dans le désordre

Au début du projet on s’était fixé les contraintes suivantes

- un accès aux données via http
- une base de données documentaire avec possibilité de chercher sur les elements de la structure du doc
- une base répliquable en plusieurs modes, pas seulement le master/slave
- une base permettant de chercher rapidement à travers un jeu de documents relativement conséquent ( 800k docs ), quitte à indexer les docs au fur et à mesure de leur création
- une archivage facile et rapide des données

CouchDB semblait, sur papier, taillé pour ce type d'utilisation.

Si on fait sauter la réplication, on peut effectivement considérer le fait d’utiliser une base de données classique ( avec ou sans file system auxiliaire, le blob peut bien marcher pour des documents courts ).

Et c'est c'est malheureusement ce qui se passe au final avec notre solution hybride .

Citation Envoyé par pseudocode
Il est certain que les base NoSQL sont pour l'instant uniquement des solutions techniques (à l'instar des bases SQL). Il n'y a pas encore vraiment de solutions applicatives clé-en-main.

Disons qu'avec CouchDB tu peux utiliser écrire une "CouchApp", un concept d'appli "embarquée" dans Couch !

L'idée est simple et pas bête : l'appli n’étant qu'une suite de docs autant stocker l'appli dans le serveur couch.

Sur papier c'est sympa. En pratique, développer une couch app veut dire : écrire du javascript à gogo, le dispatcher, le gérer sur la base & so on ...

Bref un joli concept technique avec comme preuve d’implémentation l'appli Futon qui administre la BD.

C'est sympa, mais Futon est une appli dont les traitements et l'ergonomie restent simplissimes voire spartiates.

Il est difficile d'imaginer une appli web avec des contraintes métiers rentrer dans la CouchApp. Et si jamais l'appli doit gerer des droits par doc/page, alors ce n'est même pas la peine .

Et ce qui me "tue" c'est que l’équipe de dev est prête à claquer du temps de dev et de discussion sur l'histoire de la "CouchApp", mais que les demandes concernant la sécurité, les perfs des i/o ou tout simplement plus de fonctionnalités sur le moteur de recherche restent lettre morte ...

HS : dsl pour la longeur des posts, mais je suis de nature bavarde
Avatar de budtucker budtucker - Membre habitué http://www.developpez.com
le 21/10/2012 à 22:50
Bonjour à tous,

1 an plus tard, je pense que la communauté a du prendre plus de recul sur le noSQL et sa mode.

1 an plus tard, je relance ce billet pour relancer ce débat (combat ?) entre le noSQL et le pure SQL. J'aime PostgreSQL et les dernières versions nous montrent qu'il est capable de gérer bien des choses. J'ai tenté MongoDB et malgré l’engouement de certains adeptes, je ne comprends pas comment fonder une architectures convenable et stable avec. Je m'y prends sûrement mal et ce post n'a pas à vocation à dévaloriser aucune base.

Cependant, j'aimerai que l'on m'explique pourquoi et quand utiliser noSQL. Est ce une question de performance (pourtant certains blog montrent que PostgreSQL serait plus performant, à voir), le clustering, autre...

A+
Avatar de pseudocode pseudocode - Rédacteur http://www.developpez.com
le 21/10/2012 à 23:58
1 an plus tard, je pense que le NoSQL a trouvé sa place en tant que "Not only SQL".

SQL reste la solution la plus simple pour des applications raisonnables (données structurées, jusqu'à la centaine de Go, avec peu de modifications).

Le NoSQL reste la solution la plus performante pour gérer du "Big Data" (structures variables, +1000 Go, souvent modifiées).

Après, il y a les cas particuliers où une approche mixte/hybride vaut la peine d'être envisagée.
Avatar de rimram31 rimram31 - Membre averti http://www.developpez.com
le 22/10/2012 à 22:10
Citation Envoyé par pseudocode  Voir le message
Le NoSQL reste la solution la plus performante pour gérer du "Big Data" (structures variables, +1000 Go, souvent modifiées)...

C'est plutôt bien résumé et c'est bien ce qui me gène avec le buzz autour de NoSQL. Il est trop souvent "vendu" par des gens dont les compétences SGBD, en restant gentil, sont assez limitées et vont te proposer du NoSQL de n'avoir su utiliser correctement une SGBD et un layer efficace au dessus.

D'autant plus qu'il est le plus souvent proposé par des gens du web, qui citent Google, Facebook ... Mais quand on sait qu'une BDD est capable de plusieurs milliers de transactions seconde, comme tu le dis, pour peu qu'on ait du 80/20 voir plus de R/W, on a quand même une sérieuse marge

Après un souci de taille pour moi, concrètement, ça donne quoi a l'exploitation? Ou trouve-t-on des "DBA" NoSQL? Quel retour d'expérience en comparaison aux dizaines d'années des SGBD ???
Avatar de vosaray vosaray - Membre actif http://www.developpez.com
le 25/10/2012 à 19:35
Salut,

Un an et demi plus tard, je trouve que l'offre "NoSQL" s'est plutôt bien étoffée et a gagné en maturité. Au point même de proposer du SQL aux utilisateurs (Apache Hive par exemple ). On peut trouver ca rigolo, schizophrène, mais en fait à bien y regarder tout cela se tient.

Donc pour ma part j'ai investi pas mal de temps sur Cassandra, une des implémentations de BigTable de Google reprise sous Apache.

Actuellement je travaille sur un proto, qui gère 1T de données compressées contenues dans 4 nodes Cassandra et je suis plutôt très agréablement surpris :

• Les performances de lecture sont très intéressantes (j’ai plus les chiffres en tête mais ca vaut largement une bd sql bien optimisée )
• Les performances d'insertions le sont moins, néanmoins on arrive tout de même à faire ingurgiter environ 8 Milliards de données primitives (strings ou floats) à l’heure
• Le système est vraiment linéairement scalable, on ajoute des nodes et on augmente la bande passante en R et W. (en pratique, les clusters Cassandra n'ont jamais été déployées sur plus de 400 nodes .... J'ai de la marge ...)
• Le système consomme peu d'I/Os (Memory tables, log update, async data flush) et si prend la précaution de séparer les logs du stockage on obtient un système très performant
• L'administration est simple. Plusieurs sociétés proposent de l’expertise, de la formation et on peut aussi souscrite à du support auprès de Datastax. Notez qu’il est très facile d’ajouter ou de démissionner un node.
• Le schéma est variable et column oriented. On peut altérer le schéma de manière dynamique en cours de runtime.
• L’accès peut se faire en Java, mais aussi avec n’importe quel langage
• On peut faire du Map/Reduce Hadoop sur la base car le stockage SSTables est « compatible » HDFS
• On peut faire des requêtes csql , un espèce de mini language sql like, avec possibilité de filtrages et de requêtes imbriqués ( donc relations applicatives )
• On peut ordonner les données en « cube », en fait du hash de hash , assez adapté pour du « analytics », pardon analyse de données multidimensionnelles chère à nos décideurs et data geeks

Pour les inconvénients je dirais que :

• La compression n'est pas très efficace
• Les compactions des tables est longue et consomme pas mal de ressources, pénalisant le système global
• j'ai noté plusieurs instabilités lors de tests aux limites. Malgré un sacré tuning des paramètres de la JVM j’arrive à planter les process … Un peu plus de self defense ne ferait pas mal dans le code.
• Les performances sont en grande partie dues a un design pertinent du modèle de stockage. C'est certes une généralité, mais avec Cassandra c'est flagrant. Donc si on utilise les mêmes données dans des use case différents, on a peut être interret à les dupliquer ( donc plus de place et charge ).

Dans l'ensemble je dirais qu'il s'agit d'un produit prometteur et très adaptée à la distribution, la haute dispo, la réplication et fédération de données intra et inter sites !

Je trouve qu'il lui manque juste un coté un poil plus robuste pour être proche de la solution idéale dans mon cas. Mais cela a encore le temps de s’améliorer dans les mois qui suivent.

Voilà j’avoue être très très agréablement surpris par Cassandra. Au moins autant que j’ai été décu par Couch et Mongo un an auparavant.

Après, si vous me permettez, je trouve qu'il est encore plus difficile de s'y retrouver aujourd'hui avec les nouvelles "tendances marketing" et "keywords" comme "columnar database", "big data", "analytics" et ainsi de suite.

Tout le monde aime les tartines sans savoir ce qu'on va vraiment manger
Avatar de Chavenay Chavenay - Candidat au Club http://www.developpez.com
le 05/12/2012 à 11:27
Avatar de el_muchacho el_muchacho - Nouveau membre du Club http://www.developpez.com
le 03/03/2013 à 9:49
Plus utiles, les comparaisons sur le site de Riak.
http://docs.basho.com/riak/1.2.0/ref...ed-to-MongoDB/
Avatar de SQLpro SQLpro - Rédacteur http://www.developpez.com
le 09/03/2013 à 18:28
Citation Envoyé par pseudocode  Voir le message
Le NoSQL reste la solution la plus performante pour gérer du "Big Data" (structures variables, +1000 Go, souvent modifiées).

1000 Go cela ne fait qu'un Tera octet... pas vraiment terrible, j'ai plein de client dépassant cette volumétrie dans un seul serveur...

Comme j'en avais marre de voir que les gens pensent que des bases de données relationnelles ça doit reste à quelques centaines de Go, je me suis fendu d'un article pour vous monter qu'il existe bien des bases de plus de 1 Petoctet sous MS SQL Server et ça se porte comme un charme !
J'ai fouillé certains document en interne chez MS pour vous donner cette analyse :
http://blog.developpez.com/sqlpro/p1...-en-petaoctets

A +
Avatar de pseudocode pseudocode - Rédacteur http://www.developpez.com
le 09/03/2013 à 20:09
Citation Envoyé par SQLpro  Voir le message
1000 Go cela ne fait qu'un Tera octet... pas vraiment terrible, j'ai plein de client dépassant cette volumétrie dans un seul serveur...

Comme j'en avais marre de voir que les gens pensent que des bases de données relationnelles ça doit reste à quelques centaines de Go, je me suis fendu d'un article pour vous monter qu'il existe bien des bases de plus de 1 Petoctet sous MS SQL Server et ça se porte comme un charme !

Je n'ai pas dit qu'il était impossible de gérer des gros volumes de données en SGBD-R. Je soutiens juste qu'il est plus performant (i.e. simple, économique, rapide, extensible ...) dans ce cas d'utiliser du NoSQL.

Je n'ai pas dit non plus qu'il était impossible d'utiliser du NoSQL pour gérer sa vidéothèque ou un site de e-commerce. Je soutiens juste qu'il est plus "performant" dans ce cas d'utiliser un SGBD-R.

J'avoue que c'est un avis totalement subjectif. Par exemple, je trouve plus "performant" de stocker les blobs sur le système de fichier et les metadata dans une BdD SQL plutôt que de tout mettre en fichier ou tout en base. Je suis de la vieille école: prendre l'outil le mieux adapté à la tâche.
Avatar de JeitEmgie JeitEmgie - Membre expert http://www.developpez.com
le 11/03/2013 à 8:44
Citation Envoyé par pseudocode  Voir le message
...prendre l'outil le mieux adapté à la tâche.

Entièrement d'accord sur ce point, surtout si l'on étend le concept de tâche au contexte logistique et financier du client et pas seulement aux aspects purement technologiques.

D'autant plus que tous ceux qui vantent les mérites de leur "machin" favori - quel qu'il soit - ont tous une facheuse tendance à mentir par omission, ne fut-ce que sur le coût opérationnel pour que "tout fonctionne comme un charme"...
Donc tant qu'on ne vous montre pas les factures, le nombe de personnes derrière, l'infrastructure et les logs d'incidents, (sans parler de l'analyse de risques liée à l'exploitation de telles quantités de données)... du "comme un charme" dès que çà dépasse les centaines de Tera de données vivantes (qui sont consultées aléatoirement et exploitées de manière "intelligente" - pas des "bêtes" logs - et par plus d'une personne à la fois ...) : cela reste du domaine du compte de fées ou du père Noël, et ceci quelle que soit la technoloqie vantée.

Que cela existe : certes, que cela fonctionne : sans doute, mais que cela se passe "comme un charme" : à d'autres...
Offres d'emploi IT
Assistant chef de projets/édition multimédia h/f
Hachette Livre - Ile de France - Île-de-France
Développeur senior ios mélomane, startuper et fun
Mobiskill - Ile de France - Paris (75000)
Reconversion, futurs ingénieurs java jee h/f
Adaming - Nord Pas-de-Calais - Lille (59000)

Voir plus d'offres Voir la carte des offres IT
Contacter le responsable de la rubrique Accueil