Discussion :

[SergioMaster]

Bonjour,

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.

Enfin une remarque que je comprends et pleine de bon sens

[landry161]

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 +

Rendez-vous donc dans 5 ou 6 ans alors?

[landry161]

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

Je suis du même avis que toi.

[nathieb]

Bonjour,

Je me sens moins seul merci.

Olivier

[SQLpro]

- Je dirais qu'il faut savoir nuancer son avis, j'ai été d'accord sur certains points avec SQLPRO jusqu'a l'essai...

Quel SGBD Relationnel avez vous essayé en comparaison avec quel SGBD No SQL ? Sur quel genre d'application ???

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.

Avez vous essayez avec un vrai SGBD décisionnel (donc du pur OLAP) ou votre solution utilisait-elle un SGBD Relationnel combiné à un outil du genre Business Object ?
Parce que souvent les comparaisons sont faussés par des mauvais choix.... Il y a un monde de différence au niveau des performances par exemple entre la version relationnelle de SQL Server (serveur OLTP) et la version OLAP du serveur SSAS....

- L'utilisation du Map/reduce me permet facilement de mettre a disposition des calculs.

Oracle à mis du temps à aller vers le big data. SQL Server l'avait fait depuis la version 2012 avec un connecteur hadoop... donc du map reduce en prolongation des moteurs OLTP et OLAP

- il est facile voir trop de faire de la réplication

Réplication ou haute dispo ? Ce n'est pas la même chose... SQL Server par exemple fait de la réplication depuis plus de 15 ans, avec 7 modes différents...

- cerise sur le gateau, je peux faire des réplications avec des mini NoSQL embarqué dans le navigateur

Ce que fait SQL Server en répliquant vers la version CE de SQL Server...

Est ce possible avec un SGBD standard, non ...

Et si !!!! Preuve de votre méconnaissance !

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.

Je ne suis pas sûr que cette soit disant souplesse dure longtemps. En effet, en quelques années, la plupart des SGBD NoSQL ont changé d'architecture obligeant à des migrations lourdes et conséquentes.... Et la complexité à explosée.... Que sera-ce dans 5 ou 6 ans ???

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

A +

[nathieb]

Bonjour,

Je ne parle ni ne juge d'une méconnaissance, je sais que ces choses existent sur les mamouths de SGBD. Cependant nier l'évidence de l'évolution du stockage est une erreur. Je travaille quotidiennement sur Oracle, effectivement, je pilote des applis de GED multimedias ou décisionnels. Je connais pour votre gouverne aussi OLAP, et le fameux BO, l'usine a gaz qui migre de version et qui rend mes collègues furieux à chaque changement de service "PACK" tous les ... ans ou deux.
OLAP, c'est bien, MDX déjà moins, le problème est la montée en compétence dans ce domaine, trop exclusif à mon goût, pour avoir une vision globale et orienté décisionnel, je crois qu'il faut être ouvert. Rester sur ses acquis c'est mourir, regardez ce qui se fait du côté téléphonie.
- Application HTML déconnectée
- Stockage dans les navigateurs
Tous les six mois je découvre de nouvelles possibilités d'application embarquée web ... hic du mal à suivre ...
Cela évolue vite, très vite, trop vite ? donc l'argumentation sur que ferez vous dans 5 ou 6 ans ne tient pas d'ailleurs passer d'un dump Oracle à une base No SQL ou le contraire est tout a fait possible, question de moyen. Rien n'est impossible. D'ailleurs on me force à changer de SGBD, pour des applis de moins de 5 ans.
Autre remarque, Google, Yahoo utilisent ces technos, même Oracle propose timidement sa solution, je ne crois pas qu'il faille prendre ces technos à la légère. Je ne dis pas non plus qu'il faille se séparer des "mammouths" ou contraire je reconnais leurs qualités, mais il faut prendre le meilleur des deux mondes.
Je suis architecte et je me dois de me questionner

Olivier

[-kiki-]

Bonjour,

je pense au contraire que la méconnaissance est au coeur du problème.
la plupart des arguments "pro NoSql" sont fondés, mais au final la plupart des devs utilisent du NoSql sans en avoir besoin :

la réplication :
"avec du NoSql je pourrais ajouter des serveurs facilement si j'ai des problèmes de charge!"...
mais en général les problèmes de charges sont dus à des problèmes de perfs, et ajouter un serveur pour palier des problèmes de perfs ce n'est pas "régler le problème", c'est "gagner du temps".

le Big-Data :
"avec du Big-Data, les SGBDR classiques ça rame!"
peut-être (j'en sait rien), mais 50 millions de lignes ce n'est pas du Big-Data!...

la vitesse d'exécution :
"les données sont en RAM! ça va beaucoup plus vite qu'un SGBDR qui lui, travaille sur disque!"...
sauf qu'un SGBDR classique a un cache de données (non, y'a pas que le cache de requête dans la vie!). même les tables MyIsam de mysql en ont plus ou moins un : le page cache de linux.
donc même avec un SGBDR classique les données sont quasiment toujours en RAM (et c'est notre taff de faire en sorte de ne pas trop lire les disques)
"oui mais on évite le coût d'interprétation du SQL"
si on en est à ce point d'optimisation, il faut aussi se pencher sur la latence réseau, le "coût" d'une sérialisation (oui, même avec mongoDB! le "bson_encode" est certes une sérialisation des plus rapides, mais ça a qd même un cout)
et souvent, dans ce cas le NoSql est utilisé plus ou moins comme du cache... autant stocker directement l'objet binaire en RAM sur le serveur où il se trouve. (ex pour php : avec APCu)

et de toute façon, quand on voit les requêtes que pondent les mêmes devs qui clament qu'il faut du NoSql... ils feraient mieux d'apprendre à requêter correctement avant de vouloir changer de SGBD... :p


alors biensûr, dans certains cas le NoSql à de l'intérêt.
mais la pluspart du temps, j'ai l'impression qu'on passe au NoSql parce qu'on ne sait pas utiliser correctement un SGBDR classique.

d'ailleurs je me pose une question :
est-ce la montée en puissance de ces grosses merdes d'ORM qui a fait "réaliser" aux devs que le SQL c'est lent? et donc les a poussés vers le NoSql?
et si on arrêtais simplement d'utiliser les ORM?

[iberserk]

100% daccord avec kiki, si on ne peut négliger l'approche nosql (je vous conseille au passage l'ouvrage de Rudi BRUCHEZ sur le sujet...) dans les faits bon nombre de développeurs/architecte compensent leur méconnaissance/ incompétence (modélisation/requètage) par ces solutions.

[hugo123]

J'avais fui cette discussion dès le départ car je savais comment ça allait tourner

Cela fait un certain temps que je bosse, et j'ai toujours vu ces débats DBA/Devs tourner de la sorte. Il y a longtemps il y a eu le débat procédures stockées Vs code applicatif (ou ORM) et la fameuse politique de "base interdite en écriture pour les devs sauf a executer mes procs stocks". Aujourd'hui c'est sql Vs nosql (ce qui en soi est un faux débat, ca se complète).

Messieurs les DBA, est ce possible que vous envisagiez un seul instant, si petit soit-il, que si d'autres solutions venu d'autres métiers que le votre sont proposés, ce ne soit pas que parce que ces personnes sont incompétentes ?

Envisagez-vous la petite hypothèse que tous les développeurs et toutes les boites ayant fait d'autres choix que ceux que vous conseillez ne l'ont pas fait par méconnaissance ?
Est ce réellement plausible que Martin Fowler, Bob Martin, Shay Bannon, Eliot Horowitz, et j'en passe des tas d'autres soient ignorants/incompétents ?

Pour ma part j'utilise les deux en fonction des besoins.
(mon dernier gros projet utilisait Oracle, Hadoop, Hbase, elasticsearch, Kafka, il y avait de très bons DBA et architectes dessus, je sais qu'il est possible de faire de supers équipes avec tout ce beau monde ).

[skuatamad]

Tout d'abord je n'ai pas critiqué les produits NoSQL que d'ailleurs je ne connais pas (mais ta 1ere remarque ne s'adressait probablement pas à moi).

Après je ne suis pas d'accord avec une remarque :

j'ai toujours vu ces débats DBA/Devs tourner de la sorte. Il y a longtemps il y a eu le débat procédures stockées Vs code applicatif (ou ORM) et la fameuse politique de "base interdite en écriture pour les devs sauf a executer mes procs stocks".

Les DBA ne développent pas de procédures stockées applicatives, ça n'a jamais été leur rôle.
C'est le rôle des développeurs, mais à mon sens de développeurs spécialisés dans LA base de données utilisée.
Certes ce modèle n'existe plus, d'où, à mon sens, l'apparition d'ORM, mais à mon sens toujours c'est plus lié à un problème de gestion de ressource / management.

Les développeurs applicatifs ont déjà fort à faire avec le langage qu'ils utilisent (voir les langages), en plus ils doivent bosser potentiellement sur plusieurs SGBDR, et pis bon un peu d'IHM en prime...
Du coup ils ont généralement tendance à considérer que les SGBDR fonctionnent tous de la même manière, et pense rarement voir très rarement concurrence d'accès.

Je ne doute pas que les gens que tu cites sont très compétents, par contre le blogueur à l'origine de la création de cet article dit des choses plus que surprenantes :
http://www.developpez.net/forums/d14...l/#post7911596

[hugo123]

Le débat code applicatif Vs proc stock est encore d'actualité. Je le rencontre encore régulièrement dans les sociétés. C'est parfois caricatural, avec des silos complètement étanches qui mènent à des situations ubuesques
Dans certaines sociétés j'ai vu la situation changer entre deux CTO, le premier venait du dev, le second qui l'a remplacé venait des DBDev (dev de base de données). Bref, de la querelle de clocher, comme tu dis, des soucis de management.

Pour ma part je trouve un peu dommage de maintenir des silos de compétence. Je trouve un peu réducteur d'avoir des devs qui ne ferait que du langage sans connaitre la base de données qu'ils utilisent ou des DBdev ne connaissant pas comment les données sont utilisées de façon applicative etc... J'ai bossé dans des équipes un peu plus polyvalentes et c'est celles qui tournaient le mieux selon moi.
Il y aurait bcp à dire sur le sujet.

a+

[-kiki-]

tu caricature le débat pour essayer de nous dé-crédibiliser?
je ne suis pas DBA, mais un dev php de base. donc ce n'est pas une querelle de clocher DBA vs DEV (car dans ta logique mon discours serait celui d'un DBA à l'encontre des DEVS?).
mais j'aime être fier de ce que je fais, et j'aime avoir de vraies discussions techniques.
donc je n'aime pas qu'on me contredise sans argumenter, et je déteste qu'on m'impose des solutions techniques ineptes.
du coup j'ai souvent envie de me tirer une balle :p je pense d'ailleurs me réorienter vers du dev client, où je redeviendrais un noob parmis les noobs.

et le problème de l'ignorance est justement au coeur de mes petits problèmes pro :
biensûr qu'il y a des gens compétents! mais le problème c'est qu'ils sont rares, et que les incompétents boivent leurs paroles sans les comprendre, et essaye d'imposer leurs idées biaisées partout où ils passent!
-> impossible de discuter avec eux car au final ils ne pigent même pas les arguments qu'on leur avance, et petit à petit ils modifient négativement notre environnement technique.
et ce n'est pas un faux débat, on sait très bien que l'idée n'est pas d'opposer le NoSql au sql!
ce que je déplore, ce n'est pas d'avoir du NoSql dans certains projets, c'est d'avoir du NoSql là où un SGBDR aurait été plus adapté (et de ne même pas avoir la possibilité d'en débattre).
mais je sais que je tire des généralités à partir de ma seule expérience...
et le NoSql n'est pas le seul sujet qui gâche mon quotidien, y'a aussi les ORM par exemple :p


Désolé d'avoir un peu raconté ma vie (et d'avoir été si prétentieux, et d'avoir trollé...^^), mais comme ça tu comprend peut-être mieux mon point de vue.


ps: tu fuyais la discussion pour éviter ce genre de débat, mais tu y plonge dès qu'on ouvre la porte :p

[hugo123]

tu caricature le débat pour essayer de nous dé-crédibiliser?

Promis non. Disons que je ne souhaite pas entrer en conflit sur chaque argument car j'ai peur que ce soit un débat très long, parfois trop technique donc qui risque de perdre le sujet initial (et très consommateur de temps également ^^). Je préfère ce type de discussion lors d'une conférence technique/user group, c'est plus vivant ou lors d'un atelier, ca permet de voir les bonnes pratiques par un expert.
J'essaie, je n'y arrive pas toujours, d'être pragmatique et c'est la seule chose que j'essaie d'apporter, un peu de recul. Mais promis, il y a de très bons points au dessus et mon but c'est pas de les décridibiliser.

Désolé d'avoir un peu raconté ma vie (et d'avoir été si prétentieux, et d'avoir trollé...^^), mais comme ça tu comprend peut-être mieux mon point de vue.

Aucun souci, je trolle aussi ^^
Et c'est normal, nous ne sommes que le fruit de nos expériences, c'est surtout vrai en info.
J'ai vu des projets se vautrer avec une base technique ou un type d'organisation, forcément j'ai de mauvais a priori quand on me les repropose. Même si parfois ca peut marcher si la mise en oeuvre est meilleure.

ps: tu fuyais la discussion pour éviter ce genre de débat, mais tu y plonge dès qu'on ouvre la porte :p

J'ai quand même attendu la seconde page. Mais lire certaines phrases m'a trop fait tiquer. Je suis faible...

[Youkhel]

je sais pas si je suis dans le bon endroit pour poser cette question :/ je m'excuse d'avance, veuillez me rediriger si c'est le cas...
je cherche à faire une analyse lexicale du langage "Hbase", je me demande si quelqu'un peut m'aider à trouver la grammaire de ce langage, ou au moins des programme utilisant ce dernier!! merci beaucoup

[hugo123]

Comme tu l'as pressenti, effectivement ce n'est pas le bon endroit ^^
Il faudrait que tu ouvres un autre topic/post à part de celui-ci pour cette question.
(je te donne qd même un élément de réponse, HBase n'est pas un langage mais une base de données orientée colonnes)

[Youkhel]

merci beaucoup

[pmithrandir]

Après de nombreux mois, je suis arrivé a un usage que je trouve intéressant.

Je suis assez fan du SQL, et j'ai plutôt tendance a forcer les équipes avec qui je travaille a arrêter de vouloir aller sur du NO-SQL pour de mauvaises raisons. (et oui, 1 milliards de ligne, c'est pas grand chose)

En particulier, je n'aime pas le fait qu'on a pas vraiment de garantie d'intégrité comparable aux SGBD avec le NOSQL.

En revanche, j'ai plusieurs cas ou je peux le trouver intéressant :
- quand l'architecture cible est majoritairement cloud, et que celle ci ne propose pas de VM avec plus de 8 giga de RAM et 4 ou 8 VCPU (voir beaucoup de VM de 2VCPU / 2GB RAM). Pour un SGBD, on peut atteindre ca assez vite.
- Quand on doit faire simplement de la haute disponibilité multi-site sans y passer des journées de spécialistes pour configurer le machin. (j ai eu des logiciels a faire ou on arrivant a des terra octet de données, sur des systèmes créé en 20 jours homme... ajouter 5 journée de config serveur... bof bof du coté chef de projet...)
- Quand on veut de-normaliser.

Ce dernier cas est celui qui me convainc le plus. Je suis en train de travailler dessus sur mon site d'idées. (qui n'en a pas besoin pour des questions de performances).

J'ai une BDD tout ce qu'il y a de plus relationnel, derrière un ORM. J'ai essayé de garder ca le + possible normalisé, mais progressivement, j'arrive a des problèmes de performances assez vite quand j'utilise des truc un peu avancés. (une date qui peut prendre la valeur de plusieurs champs date selon le cas, et que l'on recalcule a chaque requête, au lieu de le faire a chaque écriture)

J'essaye donc une autre approche :
- Je garde mon schéma de donnée normalisé
- Je créé un schéma de donnée dans Elastic Search en dupliquant mes données de la BDD. C'est un espace poubelle en ce qui concerne la qualité des données, juste une façon de calculer des colonnes à l'écriture dans le système, et non à chaque lecture. Une manière aussi d'externaliser certaines requêtes un peu lourdes sur un système qui va pouvoir être distribuée nativement sur plusieurs machines. (et ou il importe peu que les données soient un peu en retard).

Au passage, je vais éviter de placer plein d'index dans ma base dont on ne saura plus pourquoi ils ont été mis la dans 1 an.

A voir sur le long terme, mais dans la mouvance 1 besoin => 1 outil, je pense que c'est pas mal.

[SQLpro]

Dès le départ cette discussion n'est pas bonne. En effet, la question posée est stupide...
La question n'est pas d'être adepte ou pas. Nous ne sommes pas dans l'univers de la mode ou porter un jean taille base qui laisse entrevoir la raie des fesses serait mieux que de se vêtir d'un pantalon en velours côtelé avec bretelle...
Bref la question intelligente eut été :
Pour quel usage ?

Là il y a un réel intérêt qui lui est le Big Data !

Le reste, la façon de le stocker importe peu... D'ailleurs la meilleure preuve en est que les grands éditeurs de SGBDR supportent pour la plupart les technologies Map/Reduce (et là il y a un réel intérêt) et commencent même à produire des outils (langage) pour aller de la base relationnelle au Big Data. Exemple Sqoop/pig via HDInsight de MS...

Sur le sujet du Big Data et son réel intérêt, je ne peut que vous inviter à lire cet ouvrage pour en comprendre mieux les enjeux du point de vu de l'utilisateur (et non de celui du bricoleur, fut-il un informaticien adorateur ou détesteur du fumeux NoSQL !)

En sus, allez à cette conférence : http://www.egeablog.net/index.php?po...e-23-mars-2015

A +

[landry161]

à 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 ???Vous parliez de technologie mature ??? ;-)

Ce bricolage comme tu le dis est quand même utilisé par des géants comme Google,Facebook,Amazon. Donc vas-y doucement.
De toute les manières les bases de données NoSQL ne sont pas là pour combattre les base de données relationnelles.

[landry161]

Pour ma part j'utilise les deux en fonction des besoins.

Je pense que c'est ce qu'il faut retenir de ce débat