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.

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

[Katleen Erna]

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 ?

[piklein]

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 ?

[Porkepix]

Un peu de failles ?

Joli, joli!

[pseudocode]

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

Hum. Pour moi il n'existe pas de NoSQL à "maîtriser", sous-entendu il n'y a pas une spécification unique de ce qu'est le NoSQL. Pour moi c'est plus un philosophie consistant à réfléchir quelques instants avant de courir vers une solution SGBD.

Je pense aussi que c'est plus qu'une "mode", dans le sens où le problème de font est bien réel : comment gérer efficacement des (grandes) quantités de données non structurées, à la disponibilité changeante, et liées entre elles par des relations floues (non booléennes, temporelles, ...) ?

Je ne sais pas si la solution consiste en une évolution des SGBD actuels, où en la création d'un nouveau concept.

[daedric]

Mais est ce qu'il y a quelqu'un qui a *vraiment* regardé ce qu'etait une base de donnée NoSQL ? Le débat ici est totalement inutile et à côté de la plaque.

Vous vous contentez de dire pour la majorité:
'SQL c'est bien' et 'NoSQL c'est bien'

La comparaison des deux n'a pas lieu d'être faite ... C'est fait pour des problèmes différents ...

Exemples:

Redis peut servir à mettre en cache des données, comme memcache.
A la base c'est pour du stockage 'in memory'
Donc ça pourrait être mis en place pour mettre en cache le résultat d'une requête SQL.

Riak: Bonne distribution. On peut ajouter des nodes les doigts dans le nez, les supprimer. Map-Reduce sur les donnees reçu. Deploiement facile.

MongoDB: Base de données distribuées. Stocke du BSON. peut faire du sharding: stock dans tel ou tel noeud les données reçu selon la valeur de certaine clefs.

Cassandra: P2P mais très statique dans sa configuration (et ses super-column), stocke du json de mémoire.

Toutes gerent plus ou moins de la replication, master/slave, etc.


Une base de données relationnelles comme son nom l'indique sert à stocker des données aillant des relations. Donc je ne vois pas ou est le débat:

Par exemple: Je veux stocker des metrics d'un pool de serveur, j'utilise un Riak d'autant plus si je veux les traiter a la volée à la reception, (typiquement un retour de collectd).

Je veux faire un blog, donc: utilisateur associés avec des articles, des commentaires ... j'utiliserais un *SQL (postgres, mysql, sqlserver, oracle et j'en passe)

[pseudocode]

c'est toi qui a décidé d'en faire "2 problèmes différents" en segmentant leur utilisation par domaine. Mysql n'est plus spécialement destiné aux blogs que Riak aux métriques.

Réduire le débat a SQL=relation et NoSQL=indexation est a mon sens très restrictif.

Exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
Imaginons une application gérant des individus (A, B, C, ...) 
et une relation "fait confiance à" représentée par une valeur entre 0% et 100%. 
 
En l'absence de relation directe entre 2 individus, on utilise la transitivité :
 
si A --(fait confiance à 80% à)--> B 
et B --(fait confiance à 50% à)--> C
alors A  --(fait confiance à 50%*80%=40% à)--> C

Il s'agit donc bien ici de stocker des entités avec relations. Est-ce que SQL est le plus adapté pour gérer des requêtes du genre "quels sont les individus auquel 'A' accorde +50% de confiance" ? Et si on ajoute une notion temporelle dans la relation (valeur de confiance variant en fonction de la date) ?

[daedric]

c'est toi qui a décidé d'en faire "2 problèmes différents" en segmentant leur utilisation par domaine. Mysql n'est plus spécialement destiné aux blogs que Riak aux métriques.

Malgré tout je pense que si, après ça dépend evidemment du volume, du traitement et de la manière de les stocker.

Réduire le débat a SQL=relation et NoSQL=indexation est à mon sens très restrictif.

Je le reduis pas a ce point là il est quand même de faire des requêtes assez puissantes en NoSQL.

Simplement ce n'est pas aussi puissant que des requêtes SQL avec des jointures entre tables ...

Exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
Imaginons une application gérant des individus (A, B, C, ...) 
et une relation (fait confiance à) représentée par une valeur entre 0% et 100%. 
 
En l'absence de relation directe entre 2 individus, on utilise la transitivité :
 
si A --(fait confiance à 80% à)--> B 
et B --(fait confiance à 50% à)--> C
alors A  --(fait confiance à 50%*80%=40% à)--> C

Il s'agit donc bien ici de stocker des entités avec relations. Est-ce que SQL est le plus adapté pour gérer des requêtes du genre "quels sont les individus auquel 'A' accorde +50% de confiance" ? Et si on ajoute une notion temporelle dans la relation (valeur de confiance variant en fonction de la date) ?

A ce niveau la je pense que l'architecture rentre en compte. Si le tout doit être distribué il sera peut-être plus simple de mettre une db NoSQL qu'une base de donnée relationnelle.