Discussion :

[Arsene Newman]

Pourquoi je ne suis pas adepte du NoSQL ?
Un professionnel justifie ce choix sur la base de plusieurs critères

Fondateur de CYPRESSNORTH, entreprise spécialisée dans le marketing Internet, les services IT et le développement logiciel, Matthew Mombrea explique aujourd’hui sa lassitude vis-à-vis des bases de données NoSQL.

L’un des plus grands freins vis-à-vis du NoSQL selon Mombrea est la multiplication des solutions qui partagent toute la même devise lorsqu’il est question d’en choisir une : « Cela dépend de vos besoins », alors ce qui semble être justifié et part d’un principe de bon sens se révèle être un véritable casse-tête.

En effet, même si le développeur arrive à définir ses besoins, la multitude de solutions existantes nécessite une lecture approfondie et plusieurs recherches pour saisir et comprendre toutes les facettes et les spécificités qui se cachent derrière chaque solution, ce qui ne facilite pas la tâche du développeur.

Aussi, à la lecture de ces spécificités, il n’est pas rare de s’apercevoir qu’il s’agit plus de solutions de rechanges ou de compromis vis-à-vis de certains principes comme ACID.

Plus encore, le NoSQL qui s’affranchit des tables relationnelles et qui permet un stockage de données indépendamment du type, de la forme et de la nature de la donnée, tend à créer un système hétérogène plus complexe, où le développeur doit implémenter les mêmes mécanismes existants sous les bases de données traditionnelles, pour chaque application. Ainsi, une certaine partie de l’ingéniosité et de la structuration des données derrière les bases de données relationnelles est perdu avec le NoSQL.

Alors, les performances promises par le NoSQL en matière de vitesse d’exécution, de flexibilité et de montée en charge valent elles le détour ? Pas si sûr selon Mombrea. Le besoin pour le NoSQL ne se fait ressentir que dans quelques situations, de plus la plupart des applications qui recourent au NoSQL sous prétexte d’une montée en charge, ne passeront pas finalement à une très grande échelle.

Enfin, Mombrea souligne que le NoSQL n’a pas encore suffisamment mûri pour révéler tout son potentiel, sans oublier que les bases de données relationnelles sont largement utilisées pour les sites à forte audience, ce qui révèle une certaine capacité du passage à l’échelle des solutions traditionnelles à condition de se doter d’une certaine puissance de calcul, actuellement à la portée de plus en plus d’entreprises.

Source : Article de Matthew Mombrea

Et vous ?

Pensez-vous que le NoSQL est une solution de remplacement ou une solution complémentaire aux bases de données relationnelles ?

[spyserver]

Encore une fois le NoSQL n'est pas une solution de remplacement du SQL et n'a jamais eu vocation à l'être, simplement l'attrait d'Amazon, Facebook et autre Google pour ces bases a créé un effet de mode qui a généré beaucoup de "faux besoins" dans l'IT.

Après pour ce qui est des véritables applis qui tournent avec ce type de SGBD pour répondre à une problématique clairement identifiée (charge, type de données utilisateur peu liées entres elles mais volumineuses,persistance des données spécifique,etc.) il est clair que la "jungle" actuelle regorge de framework plus ou moins redondants qui ne facilitent pas le choix d'intégration.Le travail d'Oracle pour standardiser le langage SQL au NoSQL est une bonne chose mais il reste encore un process de selection naturelle qui doit se faire entre les différentes solutions afin de ne garder les plus stables et les plus robustes (Cassandra, MongoDB, etc.).

Recréer une nouvelle solution qui in fine est plus une évol. de quelque chose d'existant qu'une véritable révolution est assez tendance, résultat on ne sait plus quoi adopter et ça créé de l'instabilité dans les solutions et génère des coûts inutiles.

[Mouke]

De mon point de vue d'étudiant, je pense que NoSQL est une alternative au Relationnel, qui révèle son intérêt dans certains cas précis.

Je reste convaincu que des systèmes relationnels suffisent amplement pour la plupart des besoins, à condition de choisir le bon SGBD et bien l'utiliser.
Qui plus est, mais ceci est un avis personnel, je trouve NoSQL plus compliqué à "comprendre".

Après je pense que SpyServer a utilisé le bon mot : "Effet de mode". Mais il est clair que le NoSQL est à ses débuts et qu'il réserve de bonnes surprises pour le futur. Si son besoin est justifié.

[super_navide]

Pour moi le NoSQL ne sert à rien du tout car il repose tout comme les plus des SGBD sur des index implémenté via des BTREE.
Un SGBD comme oracle peux servir pour tout a condition de bien modéliser le model de donnée et mettre les bon index.

[Haseo86]

Mode caricature : en gros ce qui gène ce monsieur c'est de devoir réfléchir pour choisir la solution adaptée ? :p

Plus sérieusement, il semble avoir une vision simpliste du monde, dans lequel il oppose absolument NoSQL et SQL. Pourtant un projet peut très bien avoir un besoin pour les deux. Je vois par exemple un projet sur lequel j'étais il y a encore un an, une partie des données étaient stockées dans une base MySQL, et une autre dans MongoDB, parce que c'était plus adapté.

Désolé si ça ne lui convient pas, mais si, il faut réfléchir en démarrant un projet, et sur bien d'autres points encore que le choix de base de données.

[jmosqu]

J'avais lu à quelque part qu'il y avait méprise sur le terme même de NoSQL :

NoSQL <> "No SQL - renoncer au SQL"
NoSQL = "Not Only SQL"

Est-ce correct ?

[L0rD59]

[SQLpro]

De mon point de vue d'étudiant, je pense que NoSQL est une alternative au Relationnel....

Non, pas du tout ! Et c'est même ce qu'exprime les "auteurs" du NoSQL. Pas une alternative, mais un complément dans les rares cas ou les SGBDR pourraient s'avérer inefficaces...

De toute façon le No SQL ne survivra pas si :
1) il n'y a pas un "langage" commun pour manipuler ces bases
2) on change de technologie régulièrement (ce qui a déjà été le cas de plusieurs outils noSQL obligeant ceux qui avaient développé des applications NoSQL à tout jeter)
3) les éditeurs actuels de SGBD Relationnel intègrent une partie de noSQL à leurs solutions, ce qui commence à être le cas pour Oracle et SQL Server...

Donc, à mon avis, dans 5 ou 6 ans, Mongodb comme Cassandra, direction... poubelle! Comme l'ont été les SGBD OO ou les SGBD xml.

A +

[iberserk]

Que les développeurs apprennent déjà à manipuler et modéliser une base de données relationnelle a peu près correctement avant de basculer (souvent pour de mauvaise raisons) sur du NOSQL.
Je rappel que le NOSQL n'a pas vocation à réellement améliorer les temps de réponse mais à assurer une montée en charge... ce qui n'est pas tout à fait la même chose.

[Patriarch24]

NoSQL = "Not Only SQL"

Pour info, NoSQL est à l'origine un hashtag twitter. Les interprétations qu'on a donné sont presque toutes fausses : NoSQL = not SQL (en clair : non-relationnel).

De toute façon le No SQL ne survivra pas si :
1) il n'y a pas un "langage" commun pour manipuler ces bases
2) on change de technologie régulièrement (ce qui a déjà été le cas de plusieurs outils noSQL obligeant ceux qui avaient développé des applications NoSQL à tout jeter)
3) les éditeurs actuels de SGBD Relationnel intègrent une partie de noSQL à leurs solutions, ce qui commence à être le cas pour Oracle et SQL Server...

1) Le langage commun ne peut exister que si le paradigme est le même. Comment espérer un langage commun entre une base graphe et une base clé valeur (par exemple) ?
2) Il faut donner aux outils le temps de se stabiliser : les bases relationnelles ne sont pas devenues du jour au lendemain stables, performantes, etc.
3) Et on voit apparaître des solutions dites NewSQL aussi : en clair, on n'arrête pas le progrès...

Donc, à mon avis, dans 5 ou 6 ans, Mongodb comme Cassandra, direction... poubelle! Comme l'ont été les SGBD OO ou les SGBD xml.

Je n'en serai pas si sûr : Google aussi bien que Facebook, Twitter etc. utilisent ce type de solutions depuis une dizaine d'années déjà (pour Google et Amazon au moins). Pour le reste, bien malin qui peut affirmer ce qui va se passer...

Je rappel que le NOSQL n'a pas vocation à réellement améliorer les temps de réponse

Tout dépend : certaines bases spécialisées de type clé-valeur, si (Riak est ultra-rapide, par exemple).

Je conseille la visualisation de cette

pour mieux comprendre ce qui se cache derrière ce terme "NoSQL".

[skuatamad]

Tiré du blog :

To make matters worse, you have to wade through engine-specific documentation to read about how you would accomplish your goals, most of which seem like workaround efforts if you have relational data or would like ACID transactions.

Ben du coup, le choix semble plutôt simple, non ?
Par ailleurs stocker des données non relationnelles dans un SGBDR, c'est également souvent de la bidouille.

Compare that to a relational SQL database where, for the most part, you know how the engine will work regardless of the particular product.

Vu que justement en fonction du produit le moteur fonctionne différemment (même entre SGBDR MVCC il y a des subtilités), sa remarque est plutôt un total non sens...

[SQLpro]

1) Le langage commun ne peut exister que si le paradigme est le même. Comment espérer un langage commun entre une base graphe et une base clé valeur (par exemple) ?

Et c'est bien là le problèmes en multipliant les les langages on divise les application (tiens c'est du Audiard... "Les bénéfices, ça se divise, la réclusion, ça s’additionne !) Bref, les développeurs apprendrons un des langages du NoSQSL ferons tout avec et ça merdera et on en entendra plus parler !

2) Il faut donner aux outils le temps de se stabiliser : les bases relationnelles ne sont pas devenues du jour au lendemain stables, performantes, etc.

FAUX : à l'origine des SGBDR une théorie et non pas le bricolage actuel du NoSQL. Une fédération très rapide autour d'un langage (SQL 1974 avant même les premiers SGBDR) et donc une normalisation très rapide (1986)... Ce qui en a fait le succès ! Cela existe t-il dans le noSQL ???

3) Et on voit apparaître des solutions dites NewSQL aussi : en clair, on n'arrête pas le progrès...

Vous parliez de technologie mature ??? ;-)

Je n'en serai pas si sûr : Google aussi bien que Facebook, Twitter etc. utilisent ce type de solutions depuis une dizaine d'années déjà (pour Google et Amazon au moins).

D'accord mais pour quel usage ? Du blabla, mais rien de concret... Autrement dit pour faire du web documentaire (forums, blogs...), ça va bien. Pou faire des appli de gestion c'est pas du noSQL qui est utilisé !

A +

[iolco51]

Vision simpliste.

Les bases NoSQL sont apparues parce que les bases relationnelles ACID classiques ne pouvaient pas répondre aux problématiques (montée en charge, bases hyper-relationnelles, haut volume, disponibilité).
C'est aussi pourquoi le monde NoSQL est si vaste et hétéroclite, chaque solution a été conçue pour un besoin.


Quand les SGBD relationnels ACID sauront gérer des petaoctets de données de facon performante, efficacement en termes de stockage, et sans un sharding manuel des données, alors le NoSQL sera bien moins intéressant.

Cela n'arrivera pas demain et les bases NoSQL ont de beaux jours devant elles car le volume de données à traiter croit exponentiellement.

[spidetra]

Vision simpliste.

Les bases NoSQL sont apparues parce que les bases relationnelles ACID classiques ne pouvaient pas répondre aux problématiques (montée en charge, bases hyper-relationnelles, haut volume, disponibilité).

Tu aurais des exemples de bases hyper-relationnelles ? C'est une notion que je ne connais pas.
Est-ce que tu fait référence aux bases orientés graphes et aux hyper-graphes ?

[iberserk]

Tu aurais des exemples de bases hyper-relationnelles ? C'est une notion que je ne connais pas.
Est-ce que tu fait référence aux bases orientés graphes et aux hyper-graphes ?

Je pense qu'il voulais parler de bases fortement normalisées

[spidetra]

Je pense qu'il voulais parler de bases fortement normalisées

Tu parles de la 4° forme normale ? Je n'ai encore jamais croisé un projet qui ai poussé la normalisation jusqu'à cette forme.
Et, je ne vois pas trop l'apport du NoSql sur ce point. Au contraire, dans le NoSql, au moins dans les bases orientées documents, les données sont peu normalisées, redondantes, et pas relationnelles.
C'est pour cela que j'avais associé cette notion d'hyper-relationnelle, plutôt aux bases de types graphes.

[Patriarch24]

FAUX : à l'origine des SGBDR une théorie et non pas le bricolage actuel du NoSQL. Une fédération très rapide autour d'un langage (SQL 1974 avant même les premiers SGBDR) et donc une normalisation très rapide (1986)... Ce qui en a fait le succès ! Cela existe t-il dans le noSQL ???

Les bases orientées graphe sont basées sur la théorie des graphes, les bases clé-valeurs (peu ou prou toutes les autres) sur les théories des calculs distribués : la plupart des algorithmes utilisés dans ces bases sont issus de théories diverses.
Encore une fois, la fédération autour d'un langage est possible car dans ce cas on ne traite qu'un paradigme (relationnel). Je ne vois pas en quoi mon assertion est fausse : les systèmes relationnels ne sont pas devenus du jour au lendemain performants, stables, etc, je persiste et signe. Ils ont beau être basés sur une théorie mathématique, il n'empêche qu'en quarante ans les choses ont évoluées...

D'accord mais pour quel usage ? Du blabla, mais rien de concret... Autrement dit pour faire du web documentaire (forums, blogs...), ça va bien. Pou faire des appli de gestion c'est pas du noSQL qui est utilisé !

Facebook : utilisation de Cassandra pour le système de messaging, d'une base orientée graphe pour la gestion des liens entre relations, entre autres. Google utilise BigTable et d'autres systèmes pour son moteur de recherche. D'autres utilisent Hadoop pour les traitements massifs de données.

ps : il n'y a pas que les applications de gestion qui existe. Et même celles-là peuvent utiliser du NoSQL pour fonctionner.

on divise les application

L'heure est en effet aux divisions d'applications, et non à l'intégration à l'extrême. Le but : utiliser le bon outil pour une tâche donnée (cf : WOA, micro services, architectures hexagonales etc.). Et la présentation de Martin Fowler est très intéressante aussi.

[nathieb]

Bonjour,

Je vois avec intérêt que cela déchaine les passions :

- Je dirais qu'il faut savoir nuancer son avis, j'ai été d'accord sur certains points avec SQLPRO jusqu'a l'essai, et je pense que non, il faut être pragmatique.
Le NoSQL a de l'avenir, peut être pas sous les solutions que nous connaissons, il faut simplement lui laisser du temps.
Je travaille sur un projet mi gestion mi BI, et justement dans le cadre du BI, certains atouts du NoSQL sont une vrai plus value au projet.
- L'utilisation du Map/reduce me permet facilement de mettre a disposition des calculs.
- il est facile voir trop de faire de la réplication
- cerise sur le gateau, je peux faire des réplications avec des mini NoSQL embarqué dans le navigateur

Est ce possible avec un SGBD standard, non ... et c"est dans le domaine du mobile quand retrouve sa force.
Donc est ce un enemi, non mais un allié, comme toute solution, il est perfectible.
- Pas de structure (Point fort et Point faible suivent ce qu'on veut)
- Peu de typage, on fait tout et n'importe quoi ...
....

Cette liberté à un cout d'entré (il bouscule nos fodamantaux SGBD), mais cela en fait sa force.
On ne peux le nier, l'essayer c'est aussi l'adopter, car ces solutions ont un côté magique
qui nous libère des lourdeurs d'un gros SGBD, droit, architecture, mais en place etc ...
d'ou aussi son adoption sur des projets type devops.

Il suffit de parcourir les forums français, pour observer notre retard dans le domaine, il faut justement que cela
se développe, et cela commence déjà par les sconsciences, il faut oser. c'est a l'image du cloud, on dix ans de retard
dans les mentalités et les infrastructures.

J'avoue je me suis laché ....

Olivier

[nathieb]

Les bases orientées graphe sont basées sur la théorie des graphes, les bases clé-valeurs (peu ou prou toutes les autres) sur les théories des calculs distribués : la plupart des algorithmes utilisés dans ces bases sont issus de théories diverses.
Encore une fois, la fédération autour d'un langage est possible car dans ce cas on ne traite qu'un paradigme (relationnel). Je ne vois pas en quoi mon assertion est fausse : les systèmes relationnels ne sont pas devenus du jour au lendemain performants, stables, etc, je persiste et signe. Ils ont beau être basés sur une théorie mathématique, il n'empêche qu'en quarante ans les choses ont évoluées...


Facebook : utilisation de Cassandra pour le système de messaging, d'une base orientée graphe pour la gestion des liens entre relations, entre autres. Google utilise BigTable et d'autres systèmes pour son moteur de recherche. D'autres utilisent Hadoop pour les traitements massifs de données.

ps : il n'y a pas que les applications de gestion qui existe. Et même celles-là peuvent utiliser du NoSQL pour fonctionner.


L'heure est en effet aux divisions d'applications, et non à l'intégration à l'extrême. Le but : utiliser le bon outil pour une tâche donnée (cf : WOA, micro services, architectures hexagonales etc.). Et la présentation de Martin Fowler est très intéressante aussi.

Tout a fait d'accord avec cette dernière phrase ...

Olivier

[SQLpro]

Vision simpliste.

Les bases NoSQL sont apparues parce que les bases relationnelles ACID classiques ne pouvaient pas répondre aux problématiques (montée en charge, bases hyper-relationnelles, haut volume, disponibilité).
C'est aussi pourquoi le monde NoSQL est si vaste et hétéroclite, chaque solution a été conçue pour un besoin.

Ce que vous dies est faux et participe de l'escroquerie intellectuelle qui est à la base du NoSQL. En effet, dans le fameux théorème de CAP, il est dit que les SGBDR n'était pas capable d'assurer à la fois, le transactionnel, la répartition de charge et la haute dispo... mais les tenants du NoSql ont tronqué la fin de la phrase qui est "...de manière synchrone" Or la plupart des bons SGBDR sont capable de le faire de manière asynchrone (SQL Server, Oracle et DB2).
Et aujourd'hui force est de constater que la plupart des bases NoSQL ne le font pas non plus de manière synchrone. Certes, quelques secondes pour une réplication, c'est rapide, mais c'est aussi une perte importante possible en cas de plantage !

Quand les SGBD relationnels ACID sauront gérer des petaoctets de données de facon performante, efficacement en termes de stockage, et sans un sharding manuel des données, alors le NoSQL sera bien moins intéressant.

Quand à la quantité de Po, il y a longtemps que les SGBDR en ont emmagasiné et que cela est performant. Pour info je donnais une liste de plusieurs bases de données SQL Server en Po donnant toute satisfaction : http://blog.developpez.com/sqlpro/p1...-en-petaoctets. Depuis cet article de nombeux clients ont dépassé le Po

Cela n'arrivera pas demain et les bases NoSQL ont de beaux jours devant elles car le volume de données à traiter croit exponentiellement.

Bref, du grand n'importe quoi....

En fait les bases de données NoSQL ne sont intéressante que pour des données qui ne sont pas dans l'informatique de gestion (ventes, compta, production...) mais dans l'informatique documentaire (blogs, mail...) ou en complément de bases relationnelles.
Or comme la plupart des éditeurs de SGBDR traditionnels (Oracle, MS, IBM...) sont en train d'intégrer cela à leur moteur, les cassandra et autres acteurs de la chose qui ne sont pas encore économiquement rentables sont condamnés d'avance !

A +