Discussion :

[Gordon Fowler]

Oracle veut « démystifier la mode NoSQL »
Et pose la question des ressources nécessaires pour tirer partie de ces bases de données


Dans un document daté de mai, Oracle a mis en place un argumentaire pour contrer la progression (supposée ou réelle) des bases de données NoSQL.

Ce petit livre blanc de 15 pages, baptisé « Debunking the NoSQL Hype » (« Démystifier la mode NoSQL ») aurait pu rester relativement confidentiel. Mais sa publication sur le Web lui a donné une publicité inattendue.

Dans ces 15 pages on retrouve, comme d'habitude dans ce type d'exercice, les arguments de plus ou moins mauvaises fois et les dénigrements inhérents à tout argumentaire commercial. En débattre n'a donc pas grand intérêt.

En revanche, il a le mérite de poser clairement la question des ressources nécessaires pour déployer et utiliser une base NoSQL. En comparaison bien sûr avec un SGBD Oracle supposé plus économe en temps et en compétences pour l'entreprise.

Un des passages intéressants (indépendamment de son côté provocateur et polémique) est certainement celui-ci (p 12) : « Les bases de données NoSQL ont été soutenues par les grandes sociétés internet. Un tel parrainage a donné de la crédibilité et une image «cool» à ces bases. Les grandes sociétés Internet ont été motivées par le fait d'avoir une base de données libre, qui soit entièrement sous leur contrôle. Ces entreprises ont embauché les meilleurs développeurs pour implémenter ces bases de données évolutives (NDT : scalable) et les maintenir ».

Et Oracle de demander à ses clients et prospects : « Votre entreprise est-elle prête à faire un tel investissement dans un domaine qui n'est pas son cœur de métier ? Voulez-vous vraiment contribuer à un effort open-source? Voulez-vous vraiment miser votre projet sur une technologie avant-gardiste (NDT : bleeding edge) ? Voulez-vous vraiment bâtir une équipe de superstars, nécessaire pour faire de la vision de NoSQL une réalité ? ».

Et de conclure : « Vous n'êtes pas Google ».

Un tel argumentaire, dont chacun pensera ce qu'il veut sur la forme, laisse en tout cas imaginer que Oracle voit dans les bases NoSQL une menace de plus en plus pressante.

Est-ce le cas ? NoSQL devient-il « mainstream » et plus « avant-gardiste » ? Et si ce n'est pas le cas, pourquoi sortir un tel Livre Blanc ?

La deuxième question que pose Oracle, et qui mérite de l'être (une fois de plus indépendamment du style polémique de ces quelques pages), est celle des ressources que demande NoSQL.

Une question qui est d'autant plus intéressante qu'elle est posée calmement et sans parti pris.

Et que nous vous posons donc pour aider développeurs et décideurs à y voir plus clair sur ces technologies centrales, aussi bien pour le Web que pour les développements applicatifs ou les entreprises en général : les bases NoSQL demandent-elles plus, moins ou les mêmes ressources que les SGBD de Oracle, de Microsoft ou de SAP/Sybase ?

Source : « Démystifier la mode NoSQL » (PDF)

[grunk]

Et de conclure : « Vous n'êtes pas Google ».

Pour le coup il n'ont pas tord sur ce point. Beaucoup de décideur base leur choix sur le fait que tel ou tel groupe utilise une techno pour faire pareil sans pour autant savoir l'équipe/matériel qu'il y'a derrière cette technos.

On a tous déjà eu droit à un truc du genre :

Ha oui mais chez Google/Microsoft/Facebook y savent le faire ça

[jmnicolas]

Tu n'es pas Google, mais vu que l'outil est déjà développé tu n'as pas besoin d'être Google : tu es un simple utilisateur.

Je ne m'étendrai pas trop sur NoSql vu que je connais pas du tout (nos besoins sont modestes, et satisfaits par Postgresql), mais la comparaison d'Oracle est fumeuse.

A ce compte là il faut être Oracle pour utiliser Oracle ?

[martopioche]

Voulez-vous vraiment contribuer à un effort open-source?

Heu... Si Oracle pose de cette manière la question, j'en conclue que pour Oracle c'est mal que de contribuer à un effort OpenSource. Bon... Java et MySQL sont morts...

[kain_tn]

Pfff. Décidément je n'aime vraiment pas la mentalité d'Oracle.

Utiliser des bases NoSQL partout de façon systématique et sans réfléchir est aussi nocif que d'utiliser des BDD relationnelles à toutes les sauces.

Ce sont donc des outils complémentaires et non concurrents, pour la simple et bonne raison qu'ils ont leurs points forts et leurs points faibles. À chacun sa spécialité.

Pour ce qui est des coûts, honnêtement faire tourner du Oracle ce n'est pas du tout donné. Je dirai même qu' [mode troll] à moins d'avoir plein d'argent et une usine à gaz à faire tourner (et donc un système mal conçu) ça ne sert à rien de mettre en place une BDD Oracle en comparaison avec ce que l'on peut trouver sur le marché... (SQL Server, PostgreSQL 9.1, ...) [/mode troll]

Pour ce qui est des compétences, les BDD Oracle ont des comportements bizarre des fois ce qui est tout sauf trivial et donc il faut également avoir des gens formés et compétents (ce qui en soi est assez logique) donc bon leur argument de la super équipe super formée est pas terrible...

Je n'aime particulièrement pas le passage sur l'Open Source. Ça montre encore une fois tout le dédain que cette boite a envers le travail libre (cf. affaires Hudson/Jenkins, OpenOffice/LibreOffice, Java et la fondation Apache, ...).

Enfin il n'y a pas besoin d'être Google ou Facebook pour utiliser des outils à la mode si ils sont performants. C'est une simple question de bon sens. Pour avoir utilisé Neo4J, Redis et Cassandra/Hadoop au boulot, je dois dire que bien utilisés ils simplifient énormément les choses et sont capables d'encaisser des charges que les BDD classiques ne pourraient encaisser qu'à grands frais (infrastructures, etc) et je pense que c'est ce point précis qui effraye Oracle.


Pour ceux qui connaissent mal ou peu les BDD NoSQL, il y a ce lien qui résume très brièvement les différentes bases du marché et leur domaine d'utilisation

[Freem]

Certains arguments massue sont difficilement contrables, comme le fait que 30 ans a améliorer une BDD, fatalement, ça donne de l'avance sur la concurrence.
D'un autre côté, les mastodontes ont toujours plus de mal à innover que les petites boîtes, ils sont moins agiles. Et je ne considère pas google comme étant un mastodonte des BDD (gros utilisateur, oui, mais pas de produit phare dans ce domaine, pas d'expérience ni de code existant non plus, sauf ce qu'ils peuvent acheter)

Un autre argument bidon est le dénigrement de l'open source, bien qu'en même temps ils soulignent un point intéressant, lié à l'absence de standard noSQL: la fragmentation des projets et des efforts.
Mais ils omettent de préciser qu'avant le standard sql, il y avait aussi le problème avec les SGBDR. Ils omettent aussi de préciser que le langage que les principaux SGBDR implémentent (PL-SQL, TSQL) n'est pas non plus standard.
Toujours est-il qu'il y a manifestement plein de base NoSQL, et il semblerait (je prend ces propos avec des pincettes, tout de même) qu'il arrive même que la rétro-compatibilité soit brisée, lors des évolutions. Donc l'argument de "l'enfermement" de l'entreprise par sa base n'est totalement erroné.

Bon, je n'ai pas encore lu les 15 pages, et dans ce que j'ai lu, je ne comprend pas tout (je ne connaît pas très bien les spécificités des BDR) mais je me posait la question depuis pas mal de temps de ce que c'est exactement que le noSQL.

Bien que je garde à l'esprit que ce papier est partiel et partial, ce document est plutôt enrichissant, et me permettra d'avoir enfin un avis sur ce que c'est exactement que cette bête.
Maintenant, je garde a l'esprit qu'Oracle ne se privera pas de grossir les défauts de ce qui semble être une tendance montante, pour éviter de perdre sa supériorité.

PS: je n'ai pas spécialement d'amour pour Oracle, et j'aime pas du tout leur façon de dénigrer l'open source. Mais je crois qu'il est uniquement utilisé parce que pour nombre de gens, encore, open-souce = gratuit = mauvaise qualité. Donc, ils utilisent ce parallèle pourri pour dénigrer le NoSQL.

[kain_tn]

...

Dans l'ensemble je suis plutôt d'accord avec toi sauf en ce qui concerne les 30 ans d'amélioration du SGBD... En fait, les évolutions et les fonctionnalités avancées de leur SGBD m'ont toujours donné l'impression d'être des arguments marketing; je veux dire que quand tu l'utilise tous les jours (11g), certains tares te donnent franchement l'impression que le cœur du SGBD n'a pas ou presque jamais évolué... Et c'est dommage parce que mis à part les coûts c'est là que ce SGBD pêche selon moi.

[BakaOnigiri]

Pour ma part, je ne pense pas que Oracle voulait dire "l'open source c'est le mal", en tout cas pas dans ce livre blanc.

J'interprète surtout çà comme : "comptez vous vraiment vous passer d'un support pro sur un produit aussi important qu'une BDD".

Attention, je ne veux pas dire qu'il n'existe pas de support pro pour de l'open source (ex: omniORB), mais le sujet est peut être encore trop récent pour avoir un vrai support qui répondrais à des besoins très spécifique qu'aurait une entreprise qui aurait besoin d'une BDD

Pour le reste, je ne m'y connais pas assez.

[Benjamin Delespierre]

J'y vois surtout une tentative d'oracle d'asseoir sa poistion dominante sur le marché des SGBD depuis le rachat de MySQL. Si les RDBMS disparaissent au profit des NoSQL comme Cassandra, MongoDB ou encore Redis, c'est une bonne partie du chiffre qui disparait.

Sur le fond, nous assistons à un changement majeur sur l'usage que nous faisons de nos données. Il s'agit désormais d'obtenir une forte disponibilité, des performances qui crèvent les nuages et de pouvoir décentraliser le tout. Les RDBMS sauront-ils s'y adapter ou le modèle relationnel commence t'il à être dépassé ?

[kimimo]

Au risque de prendre un peu le contre-pied, pour moi ce débat n'a pas vraiment lieu d'être.
D'ailleurs, NoSQL ne veut pas dire no-SQL (pas de SQL) mais Not Only SQL !!! Il se présente donc lui même comme un complément et non comme un remplaçant.

Sur la pratique, j'ai pu tester le NoSQL sur le cloud de Google (Google App Engine) et j'ai été très déçu...
Ces systèmes permettent des performances, il est vrai, très intéressantes, surtout si l'on a besoin de stocker des volumes de données très importants. Mais cela se fait au détriment de beaucoup d'autre choses...

Tout d'abord, il n'y a pas de tables mais juste un stockage d'objets. Vous pouvez donc oublier toutes les joies du relationnel (jointures principalement mais aussi contraintes d'intégrité (foreign key) et le compositions de requêtes). Du coup, on est obligé de tout stocker comme un bourrin dans un même objet et répliquer tout un tas d'info de partout. La philosophie étant : "j'ai un espace de stockage infini mais je peux pas l'organiser donc je me tout partout" !
En réalité le système se comporte plus comme un gros système de stockage efficace ("stock cet objet", "donne moi celui-là", ...) que comme une vraie base de donnée.

Je ne suis pas un spécialiste et surtout le NoSQL est juste à ses débuts mais pour moi, il viendra plus en complément d'un SGBDR lorsque les volumes seront trop importants...
Il n'est pas non plus impensable de voir émerger (mais pas tout de suite) des systèmes basés sur les deux approches pour en tirer le meilleur à chaque fois.

[Guireg]

Oracle est à fond dans le NoSQL... Ils viennent juste de releaser leurs bases NoSQL basé, à priori, sur Berkley DB.

[Lujeni]

Je me permet de poster car j'utilise MongoDB dans un environnement de production avec MS SQLServer. Comme il a été dis , le NoSQL et les BDD classiques sont la pour se completer.

Tout d'abord, il n'y a pas de tables mais juste un stockage d'objets. Vous pouvez donc oublier toutes les joies du relationnel (jointures principalement mais aussi contraintes d'intégrité (foreign key) et le compositions de requêtes). Du coup, on est obligé de tout stocker comme un bourrin dans un même objet et répliquer tout un tas d'info de partout. La philosophie étant : "j'ai un espace de stockage infini mais je peux pas l'organiser donc je me tout partout" !
En réalité le système se comporte plus comme un gros système de stockage efficace ("stock cet objet", "donne moi celui-là", ...) que comme une vraie base de donnée.

Desole mais si tu dis ca c'est que tu as très mal compris le NoSQL, au contraire de ce que tu dis le fait est de ne pas avoir de modèle permet une bien plus grande flexibilité et evolution. Ce qui est un point fort. Ensuite pour l'espace de stockage, la aussi c'est faux. En effet beaucoup de gens utilise MongoDB en Front end pour travailler directement avec un site web par exemple et on un programme pour stocker les datas ensuite dans une BDD classique. Ensuite tu peux avoir des volumes enormes avec le NoSQl comme avec le SQL. Certaines bases MongoDB depassent le milliard de document en gardant d'excellente performance .

Pour revenir au sujet, oracle a raison de poser ces questions car cet effet de mode peut etre très nefaste. Le choix d'une base NoSQL depend enormement du BESOIN et non pas que des performances / mode.

Enfin, pour moi se former sur du NoSQL ou du SQL reviens au meme.Cela demande du travail, de l'experience et connaissance poussée de son outil pour garantir les meilleures performances. Cependant, il est plus dur de passer du SQL a du NoSQL quand on a toute la logique du SQL en tete.

[kimimo]

Desole mais si tu dis ca c'est que tu as très mal compris le NoSQL, au contraire de ce que tu dis le fait est de ne pas avoir de modèle permet une bien plus grande flexibilité et evolution. Ce qui est un point fort. Ensuite pour l'espace de stockage, la aussi c'est faux. En effet beaucoup de gens utilise MongoDB en Front end pour travailler directement avec un site web par exemple et on un programme pour stocker les datas ensuite dans une BDD classique. Ensuite tu peux avoir des volumes enormes avec le NoSQl comme avec le SQL. Certaines bases MongoDB depassent le milliard de document en gardant d'excellente performance .

Ne pas avoir de modèle permet en effet de pouvoir facilement faire évoluer sa base. En revanche, (en tous cas je parle sur ce que j'ai connu : Google App Engine) c'est pas demain que tu feras une requête te ramenant l'ensemble des salariés ayant un salaire supérieur à la moyenne... Pour ça, tu devras d'abord calculer la moyenne puis ramener les salariés ayant un salaire supérieur à cette valeur.

Effectivement, le GROS plus du NoSQL est de garder un temps d'accès constant avec un gros volume (le milliard de document) alors qu'avec une BBDR les performances se dégradent rapidement...
L'usage dont tu parles est de stocker et récupérer des documents, rien de très compliqué donc. Mais dès que l'on cherche à faire des requêtes sophistiquées, le NoSQL est vraiment à la ramasse...

[shenron666]

le modèle relationnel commence t'il à être dépassé ?

je pense aussi que le côté relationnel ne sert à rien dans de très nombreux cas d'applications où on se sert d'une base de données relationelle juste pour stocker des informations alors qu'en NoSQL on obtiendrait de meilleures performances, une meilleures maintenabilité, meilleure évolutivité et une meilleure optimisation du stockage

[Bktero]

Bonjour,

Je découvre le NoSQL avec ce post. J'en lis des choses qui m'intéressent

Si je comprends bien, le NoSQL s'oriente plus vers une collection de données, mais pas forcément liée entre elles (en tout cas moins) que les BDDR classiques ? Le NoSQL me serait utile si je veux stocker de l'information sans que mes données soient forcément liées entre elles.

Exemple : je veux faire une base contenant tous les logs de mon application, pour connaitre par exemple le nombre d’occurrences d'une erreur particulière, les dates d'exécution d'un traitement particulier, etc.... Le NoSQL serait plus adapté que du SQL ?

De ce que je comprend, le NoSQL serait comme une fonction géante de recherche dans des fichiers textes

[nicorama]

Vu la tendance des architectes à prendre leurs développeurs pour des glands , de tels arguments devraient faire mouche

[Népomucène]

Bonjour,

Je découvre le NoSQL avec ce post. ...
De ce que je comprend, le NoSQL serait comme une fonction géante de recherche dans des fichiers textes

Regarde ici :
Rapide aperçu des types de bases de noSQL

[Lujeni]

Exemple : je veux faire une base contenant tous les logs de mon application, pour connaitre par exemple le nombre d’occurrences d'une erreur particulière, les dates d'exécution d'un traitement particulier, etc.... Le NoSQL serait plus adapté que du SQL ?

Le NoSQL à aucun modèle relationnel. On parle de design, c'est à dire à quoi va ressemble ton document type. Il est très important de réfléchir au design de ton document car il influence énormément tes performances.

J'utilise le NoSQL pour stocker et traiter tous mes logs en temps réels. Le NoSQL est très puissant quand il s'agit d'effectuer enormement de requetes. Tu peux attendre les 8000inserts&upserts / seconde sans lock & fault ta base.

La question que tu dois te poser si tu hésites entre le SQL et le NoSQL est en fonction de ton besoin. Si tu à juste quelques logs ( en terme d'insertion ) à stocker et effectuer quelques requetes de temps à autres pour tes stats le NoSQL n'est pas justifié. Par contre si tu as enormement d'insertions de logs et faire limite du temps réel, la oui le NoSQL peux t'aider =)

[shenron666]

Si tu à juste quelques logs ( en terme d'insertion ) à stocker et effectuer quelques requetes de temps à autres pour tes stats le NoSQL n'est pas justifié.

je ne suis pas d'accord, si tu n'as pas ou peu de relation à établir entre tes données alors utilises le nosql

tout le monde rabâche le sql à tout va là où le relationnel est inutile et, si le besoin de modifier le modèle se présente, c'est la mouise et on perd beaucoup de temps

[Bktero]

Merci pour le lien

Avec ce que je viens de lire, je comprends un peu mieux les craintes d'Oracle. Le risque est quand même que beaucoup de gens utilisent du NoSQL pour tout ce qui n'a pas besoin de relationnel. Je pense qu'il doit y avoir un sacré paquet de projets où c'est le cas, sur au moins une partie de l'application. Au prix des licences, ça pourrait faire une sacrée différence dans la caisse.

Je trouve que l'argument de performances peut se comprendre (si on arrive à clairement le démontrer), autant l'argument "vous n'êtes pas Google" ne tient pas. C'est un peu dire "vous êtes tous des blaireaux, utilisez nos produits plutôt que NoSQL". En plus de prendre des gens pour des imbéciles, leurs (potentiels) client de surcroit, ça prétend qu'être DBA et mettre en place un système de BDD complexe est faisable par n'importe quel noob.... Juste un mot : lol