IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Affichage des résultats du sondage: Avez-vous migré à MongoDB ?

Votants
13. Vous ne pouvez pas participer à ce sondage.
  • J'ai migré d'Oracle à MongoDB

    2 15,38%
  • J'ai migré d'un autre SGBD à MongoDB

    3 23,08%
  • Je n'ai pas migré à MongoDB

    5 38,46%
  • Pas d'avis

    3 23,08%
Décisions SGBD Discussion :

Le PDG de MongoDB assure que son entreprise attire les développeurs du giron d'Oracle


Sujet :

Décisions SGBD

  1. #1
    Expert éminent sénior
    Avatar de Coriolan
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Mai 2016
    Messages
    701
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Sarthe (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Mai 2016
    Messages : 701
    Points : 51 811
    Points
    51 811
    Par défaut Le PDG de MongoDB assure que son entreprise attire les développeurs du giron d'Oracle
    Le PDG de MongoDB assure que son entreprise attire les développeurs du giron d'Oracle
    Avez-vous migré à MongoDB ?

    Les entreprises sont devenues de plus en plus persuadées de migrer vers les systèmes de gestion de bases de données non relationnelles, c’est ce qui explique la montée en puissance du NoSQL ces dernières années. Cette tendance a été confirmée par Dev Ittycheria, le PDG de MongoDB, durant un évènement de son entreprise à Londres la semaine dernière. Ittycheria a prétendu que MongoDB est en train de prendre le dessus sur les bases de données d’Oracle, une conséquence directe de la maturité de la technologie NoSQL selon lui.

    Nom : mongodb-vs-oracle.jpg
Affichages : 5626
Taille : 116,8 Ko

    Pour les non connaisseurs, MongoDB est le leader du NoSQL et la solution open source la plus populaire. Cette base de données orientée-document tire sa popularité de sa facilité et sa capacité à supporter la montée en charge des applications les plus exigeantes. Il y’a encore quelques années, personne n’aurait songé que MongoDB allait s’imposer face à Oracle aussi rapidement, mais grâce aux investissements entrepris par l’entreprise pour rendre le produit attrayant pour les entreprises, notamment avec les possibilités de gestions offertes, une meilleure performance, et des intégrations améliorées. MongoDB s’est vite imposée face à la concurrence.

    « Les choses sont en train de changer. 30 % de nos clients ont été attirés de la concurrence. Il y a deux ans, c’était seulement 5 %. Ils sont en train de délaisser Oracle et les autres, mais principalement Oracle. Il y a cette grande banque, que vous pouvez reconnaitre instantanément en voyant son logo ; et bien, ils avaient cette plateforme de trading sophistiquée. Le problème est qu’après la crise financière, les règles ont changé et ils avaient à traquer un large volume de données pour des besoins d’audit, c’est là qu’ils se sont rendu compte des limites des bases de données relationnelles. Ils ont migré leur plateforme vers MongoDB ; comme ils ne voulaient pas prendre trop de risque, ils ont commencé les tests graduellement, on parle d’un business qui vaut un milliard de dollars, ils ne prenaient pas ça à la légère, mais en fin de compte ils ont tout migré. S’il y a un besoin de changer, les gens vont changer ; si vous avez une application qui tourne sur une base de données relationnelle et personne ne se plaint, alors il n’y aura pas de changement. Mais si vous avez des raisons quelconques, de performance, légales ou à la demande des développeurs, alors ils changeront. »

    Il y a dix ans, MongoDB a été lancé justement pour faciliter la vie aux développeurs, ce but ultime a été responsable en grande partie du succès de l’entreprise et a poussé les développeurs à adopter la technologie NoSQL. Même aujourd’hui, Mongo affirme toujours être là pour le seul bonheur du développeur au quotidien. C’est d’ailleurs cet aspect qu’Oracle a négligé selon Ittycheria. Il pense que les développeurs commencent à percevoir MongoDB avec la même estime qu’ils ont eue pour Oracle, avant son déclin bien évidemment.

    Ittycheria a dit qu’il veut changer la perception qui dit que le marché du NoSQL est très compétitif et que quelques agents se rivalisent pour prendre le dessus sur Oracle. Il prétend que cela a été peut-être le cas il y a quelques deux ou trois ans, mais aujourd’hui, MongoDB s’est vraiment illustrée. Le chiffre d’affaires de l’entreprise se chiffre en centaines de millions de dollars et a des contrats de dizaines de millions de dollars avec de grandes firmes qui sont en train d’adopter la technologie en tant que standard.

    En deux ans, MongoDB a doublé son chiffre d’affaires et ses effectifs. Ittycheria qui se considère lui-même comme un gestionnaire de ressources humaines plus qu’un mangeur a assuré que son souci est de développer la chaine de distribution de l’entreprise. MongoDB a également dévoilé des nouveautés durant ces derniers mois destinées à répondre aux besoins des entreprises. Au début de ce mois, MongoDB 3.4 a été publiée, elle inclut des possibilités de placement de données amélioré, des possibilités “multi-modèles” permettant d’accéder aux données au-delà de JSON, et un nouveau connecteur BI. Cependant, en juin dernier, durant l’évènement principal de l’entreprise à New York, MongoDB a lancé Atlas - son offre complète de ‘database-as-a-service’. Selon Ittycheria, l’engouement a été phénoménal pour le nouveau service. L’entreprise s’attend qu’il aille occuper une proportion importante dans l’entreprise dans les mois à venir.

    MongoDb est certainement le leader des bases de données NoSQL, mais de là dire qu’elle a écrasé toutes les autres solutions NoSQL (et Oracle aussi) est un peu exagéré. La solution NoSQL Cloud propriétaire DynamoDb est aussi bien classée. Utilisable essentiellement via AWS, cette solution est exploitée par les entreprises pour un large éventail de tâches, comme les campagnes de publicité, les applications de médias sociaux et la collecte et l’analyse de données… Bien que Microsoft ait eu un certain retard sur ce marché, sa solution Azure DocumentDB a connu une forte croissance depuis son lancement.

    Bref, le marché est encore jeune et en plein boom, et il est difficile de donner un verdict précis. Il faut donc observer de près son évolution durant les deux prochaines années.

    Source : Diginomica

    Et vous ?

    Qu'en pensez-vous ?

    Voir aussi :

    Une nouvelle étude montre la montée en puissance du NoSQL, avec de plus en plus d'entreprises qui se tournent vers le cloud public

  2. #2
    Membre expert Avatar de jopopmk
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Mars 2011
    Messages
    1 856
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Mars 2011
    Messages : 1 856
    Points : 3 570
    Points
    3 570
    Par défaut
    Salut,

    perso je me vois mal passer du relationnel à du orienté document "just4fun".
    Que les gens qui ont une archi qui peut être portée par ces deux types de SGBD optent pour MongoDB, pourquoi pas.

    Après, pour l'abandon d'Oracle en particulier, il faut voir un petit peu leur politique tarifaire ...
    Mais pour le coup il me semblerait plus logique de regarder du côté de PostgreSQL.

  3. #3
    Membre averti
    Profil pro
    Inscrit en
    Mars 2009
    Messages
    97
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mars 2009
    Messages : 97
    Points : 374
    Points
    374
    Par défaut
    Mouai, personnellement je ne vois pas l’intérêt de passer à du 100% NoSQL, d'autant plus si derrière c'est pour l'utiliser avec un ORM ou l'exploiter comme une base relationnelle. Les deux modes sont complémentaires, même si dans un cas extreme le serveur SQL "standard" est uniquement utilisé comme serveur d'archivage.

    Dans notre entreprise, nous utilisons PostgreSQL et Redis (principalement pour les données de type "cache" ou les données qui doivent avoir un TTL limité)

  4. #4
    Membre actif Avatar de Narann
    Inscrit en
    Juin 2007
    Messages
    140
    Détails du profil
    Informations forums :
    Inscription : Juin 2007
    Messages : 140
    Points : 211
    Points
    211
    Par défaut
    Je suis passe de MySQL a MongoDB (via pymongo) et je ne regrette pas. C'est une grosse surprise car j’étais extrêmement dubitatif mais au final c'est tellement flexible que je ne serais pas prêt a revenir en arrière.

    Il y a un certain nombre de choses a savoir (souvent bien documente) mais une fois que tu capte le fonctionnement c'est très facile de prendre des décisions.

    Il faut garder a l'esprit que ça ne veut pas dire que MongoDB ne nécessite pas de réflexion sur comment structurer ses données.

    Bref, je ne suis pas surpris de la voir continuer a monter.

  5. #5
    Modérateur
    Avatar de Gugelhupf
    Homme Profil pro
    Analyste Programmeur
    Inscrit en
    Décembre 2011
    Messages
    1 325
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Analyste Programmeur

    Informations forums :
    Inscription : Décembre 2011
    Messages : 1 325
    Points : 3 769
    Points
    3 769
    Billets dans le blog
    12
    Par défaut
    Les bases relationnelles gèrent nativement les transactions, pas MongoDB. Le jour où il sera possible de persister des documents dans plus d'une collection de manière atomique, pourquoi pas.

  6. #6
    Membre éprouvé
    Homme Profil pro
    Architecte de système d'information
    Inscrit en
    Août 2014
    Messages
    476
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 55
    Localisation : France, Ain (Rhône Alpes)

    Informations professionnelles :
    Activité : Architecte de système d'information

    Informations forums :
    Inscription : Août 2014
    Messages : 476
    Points : 1 044
    Points
    1 044
    Par défaut
    arf !

    pour avoir experimenté mongodb (on fait Oracle depuis Oracle 7) :

    a/ syntaxe barbare et non standard (pour ceux qui se plaignaient avant que SQL etait "compliqué" ils pleurent maintenant)
    b/ une BDD Oracle avec laquelle tu enleves toutes les contraintes (referentielles et autres) tu arrives au meme niveau de performances.
    Le postulat de base etant : on jette tout ce qui coute a une BDD relationnelles (contraintes, transactionnel etc) effectivement il ne reste plus grand chose.
    L'effet de bord non negligeable etant que ce que faisait la BDD tres bien (intégrité referentielle), c'est maintenant reporté dans le code applicatif (Csharp) - bref on refait dans couche metier ce qui etait fait tres bien dans la BDD.
    A niveau de contraintes egales, une BDD Mongodb n'a aucun interet (si si, on a essayé sur des BDD Oracle de plusieurs TO et millions de lignes en dupliquant les données a outrance).
    c/ administration d'une BDD mongodb en PROD = galere (tres peu documenté)
    d/ ca plait aux developpeurs parce qu'il peuvent faire du dev avec syntaxe json-like a la mode c'est ce qui plait pour beaucoup

    Donc au final c'est bon pour faire joujou (genre avec elasticsearch pour afficher des graphiques a partir de logs - lol !) ou a moins d'avoir un service info qui ne fait que ca a plein temps.
    En tout cas sur nos applis en PROD on a laissé tombé car generalement pas d'administrateur BDD; alors mongodb n'en parlons pas !

    Ce sont souvent les nouveaux developpeurs qui ne cherchent pas a comprendre comment fonctionne une BDD Relationnel (et donc codent n'importe comment) pour mettre en avant des BDD nosql, sur le papier c'est souvent : "on a la performance sans rien faire" ). Bref plutot un mode "ca va resoudre tous nos pbs sans qu'on ait a comprendre pourquoi mes requetes BDD sont lentes etc.".
    On le vit au quotidien dans ma boite de 150 dev. Plus interessé de faire du csharp et reinventer la roue carrée que de comprendre le pourquoi leur requete SQL sont lentes (moins sexy/interessant - il n'y a pas l'intellisense).

  7. #7
    Membre régulier
    Homme Profil pro
    Chef de projet en SSII
    Inscrit en
    Juillet 2015
    Messages
    62
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Chef de projet en SSII

    Informations forums :
    Inscription : Juillet 2015
    Messages : 62
    Points : 82
    Points
    82
    Par défaut
    Pour avoir fait pas mal de SQL (mysql / sqlserver) et mantenant du nosql, il y'a quand même des remarques que je trouve légèrement dénuée de recul

    syntaxe barbare et non standard
    La syntaxe est du JSON et est standardisée : http://www.json.org/

    A niveau de contraintes egales, une BDD Mongodb n'a aucun interet
    L’intérêt est justement de ne pas avoir les mêmes contraintes ...

    ca plait aux developpeurs parce qu'il peuvent faire du dev avec syntaxe json-like a la mode c'est ce qui plait pour beaucoup // Ce sont souvent les nouveaux developpeurs qui ne cherchent pas a comprendre comment fonctionne une BDD Relationnel
    Si tu veux on peut inverser car j'ai l'impression qu'il y'à pas mal de d'ancien dev qui ne cherchent pas à comprendre le nosql et son fonctionnement.
    Il y a des boites qui sont prêtes à investir plusieurs millions dedans et c'est pas pour le plaisir ou un quelconque effet de mode mais car elles répondent à un vrais besoin

    Après je te l'accorde un majorité des jeunes développeurs se foutent complètement de la partie DB (sql ou no-sql) comme des problèmes de perfs, de formation de structure de base, des requêtes.
    C'est pourquoi ils voient dans les bases no-sql une excuse pour ne pas se confronter à ces contraintes.
    Mais ça ce n'est pas la faute des bases de données et de leur implémentations

    administration d'une BDD mongodb en PROD = galere (tres peu documenté)
    Heuuuuuu ... https://university.mongodb.com/
    J'ai suivi le cours sur le dev java et des collègues celui pour les DBA et je peux te dire qu'en complément de la doc on arrive à faire tout ce que l'on veut peu importe l'environnement.


    Les bases relationnelles gèrent nativement les transactions, pas MongoDB. Le jour où il sera possible de persister des documents dans plus d'une collection de manière atomique, pourquoi pas.
    Ce jour là mongodb ne servira plus à rien car autant rester sur des bases SQL normale.
    Par contre ce n'est pas parce que mongodb ne te le permet pas que tu ne peux pas modéliser ta base pour avoir cette cohérence (un index unique bien placé verrouille pas mal)


    Au final je rajouterai que cracher sur une base de donnée no sql parce quelle ne fait pas ce que fait une base sql est aussi pertinent que de cracher sur les contraintes des bases sql.
    Egalement que les bases SQL et no-SQL ne s'utilisent pas comme des stations d'épuration, si tu fais de la mer*e, il en sortira de la mer*e

  8. #8
    Membre éprouvé
    Homme Profil pro
    Architecte de système d'information
    Inscrit en
    Août 2014
    Messages
    476
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 55
    Localisation : France, Ain (Rhône Alpes)

    Informations professionnelles :
    Activité : Architecte de système d'information

    Informations forums :
    Inscription : Août 2014
    Messages : 476
    Points : 1 044
    Points
    1 044
    Par défaut
    non non pas dénuée de recul, il ne faut pas lire entre les lignes et interpreter ce qui t'arrange.

    Je ne parle pas de Json (bien sur) mais de ca :

    Nom : tumblr_kxovt0VLZy1qappj8.png
Affichages : 2541
Taille : 23,7 Ko

    c'est sur c'est une syntaxe tres "standard" (enfin chez mongodb exclusivement) et super simple a lire (a coté SQL est une barbarie ... lol).

    "l'interet est justement de ne pas avoir les memes contraintes" ... ben il suffit de les desactiver sur des BDD relationnelles traditionnelles (et concretement les reporter dans la couche metier comme c'est fait generalement sur ces plateformes - bref refaire differemment (avec les bugs) ce que faisait tres bien la BDD).
    Si c'est une BDD pour stocker des gros volumes sans contraintes (stockage, intégrités referentielles etc.) alors tout existe dans les BDD Relationnelles (pour peu qu'on s'y interesse un peu).

    Personne ne "crache" (de nos jours faire une analyse objective (retour d'experience) revient a cracher sur quelque chose ? drole d'approche ...) sur les bases nosql, personnellement mon experience a fait qu'en utilisant une BDD relationnelle classique et en enlevant toutes les contraintes genantes on arrive a la meme chose (avec moins d'inconnu); donc c'est plus l'aspect "investir du temps en formation/maitrise" sur des bdd (toutes differentes, elles n'ont que le nom en commun et quelques grand principes) qui evoluent en permanence, pour lequel je ne suis pas certain que ce soit rentable pour une boite (les syntaxes ne sont pas normalisées (et je ne parle pas de json)) sachant qu'aucune ne sort du lot (mongodb, hadoop, amazon etc.).

    Je parle en connaissance de cause et pour avoir pratiqué (1 an sur un projet pilote), pas pour "baver" (perso ca ne me rapporte rien de dire que c'est bien ou pas bien - juste factuel, le constat de nos tentatives qui ne se sont pas revelées pertinentes au final).

    Hadoop ayant une syntaxe plus proche du sql j'aurai tendance plutot a m'orienter vers celle ci si (ils ont compris que reinventer des syntaxes ca n'est pas la solution pour attirer les utilisateurs des BDD relationnelles classiques - en ca ils sont plus malins que chez mongodb).
    A ce jour on est resté sur une BDD relationnelle traditionnelle parce que coté performance on arrive a la meme chose (niveau contraintes egales) et que n'importe qui connaissant les BDD relationnelles classiques sait faire de la maintenance logiciel sans aucun probleme ni besoin d'etre expert MongodB.

  9. #9
    Membre régulier
    Homme Profil pro
    Chef de projet en SSII
    Inscrit en
    Juillet 2015
    Messages
    62
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Chef de projet en SSII

    Informations forums :
    Inscription : Juillet 2015
    Messages : 62
    Points : 82
    Points
    82
    Par défaut
    @kilroyFR

    Autant pour moi, je pensais que tu parlais du JSON et non du SQL

    Ce n'est contre toi @kilroyFR même si j'ai récupéré une bonne partie de tes citations, après j'ai surement été un peu "musclé" dans mes propos mais je suis exaspéré de lire des messages ou grossièrement le fond est "Le no-sql c'est pour faire joujou et pour des personnes pas assez intelligentes pour modéliser une base de données" ou encore des "le no-sql si tu l'utilise comme du sql ba ca sert à rien".

    Aujourd'hui il existe de véritables besoins, de preuves de succès de ces moteurs et ne pas les prendre en compte au jour d'aujourd'hui quand on design un paysage applicatif c'est ce passer d'outils complémentaires au SQL

  10. #10
    Membre actif Avatar de Narann
    Inscrit en
    Juin 2007
    Messages
    140
    Détails du profil
    Informations forums :
    Inscription : Juin 2007
    Messages : 140
    Points : 211
    Points
    211
    Par défaut
    Citation Envoyé par L4goon Voir le message
    je suis exaspéré de lire des messages ou grossièrement le fond est "Le no-sql c'est pour faire joujou et pour des personnes pas assez intelligentes pour modéliser une base de données"
    J'en profite pour préciser qu'en MongoDB (et sûrement les autres), si tu ne structures pas tes donnes (en fonction de comment tu les utilises, c'est pour ça que tu choisis du no-sql au passage), tes performances s'effondrent.

    A mes yeux, les différentes DB no-sql sont plus spécifiques compare a du SQL classique, plus generique.

  11. #11
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 922
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 922
    Points : 51 717
    Points
    51 717
    Billets dans le blog
    6
    Par défaut
    Citation Envoyé par L4goon Voir le message
    Aujourd'hui il existe de véritables besoins, de preuves de succès de ces moteurs et ne pas les prendre en compte au jour d'aujourd'hui quand on design un paysage applicatif c'est ce passer d'outils complémentaires au SQL
    Tout à fait, mais ce que je constate c'est que, majoritairement, les expériences NoSQL sont souvent faites là ou une conception traditionnelle en SGBD relationnel serait nettement plus rationnel et plus performant....

    Dernier exemple en date une grande compagnie d'électricité dont l'acronyme commence par un E et se termine avec un F voulais faire du NoSQL pour analyser des données de production venant d'une base Oracle...
    Autrement dit, passer de données structurées à des données non structurées (donc "downgrade") pour effectuer une analyse qui aurait donné des résultats sans doute médiocre... alors que la BI sur des bases relationnelle c'est fait pour ça !

    A +

  12. #12
    bm
    bm est déconnecté
    Membre confirmé

    Homme Profil pro
    Freelance
    Inscrit en
    Octobre 2002
    Messages
    874
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Drôme (Rhône Alpes)

    Informations professionnelles :
    Activité : Freelance
    Secteur : Tourisme - Loisirs

    Informations forums :
    Inscription : Octobre 2002
    Messages : 874
    Points : 556
    Points
    556
    Billets dans le blog
    6
    Par défaut
    Débat intéressant:

    Pour une production et quand tous les paramètres sont connus SQL
    restera prioritaire.

    Privilégier le SQL dans les études supérieures, est ce obligatoire ?
    Pour des petits projets non encore productifs , MongoDB va vite à l'essentiel.
    Imposer cette logique de structure SQL à toute une génération, c'est faire peur
    et rien que cela.

    Le forum de developpez.com sur le Nosql ne permet que peu d'échange.
    L'amateurisme sur le forum montre aussi que la gestion de projet est
    verrouillé à bien des niveaux, et qu'il faut rester caché, et développez
    dans son garage..

    http://www.developpez.net/forums/d16...godb-conseils/


Discussions similaires

  1. Réponses: 6
    Dernier message: 23/07/2015, 21h41
  2. Réponses: 32
    Dernier message: 28/10/2010, 13h38
  3. Créer son entreprise ? Où aller? Que faire?
    Par Janitrix dans le forum Société
    Réponses: 1
    Dernier message: 26/04/2006, 23h46
  4. [Eclipse 3.0.1] Image qui n'affiche que son path
    Par thehpman dans le forum Eclipse Java
    Réponses: 2
    Dernier message: 16/03/2005, 12h28

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo