Le PDG de MongoDB assure que son entreprise attire les développeurs du giron d'Oracle
Avez-vous migré à MongoDB ?

Le , par Coriolan, Chroniqueur Actualités
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.


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


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de jopopmk jopopmk - Membre expert https://www.developpez.com
le 23/11/2016 à 7:32
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.
Avatar de robertledoux robertledoux - Membre régulier https://www.developpez.com
le 23/11/2016 à 7:48
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é)
Avatar de Narann Narann - Membre habitué https://www.developpez.com
le 23/11/2016 à 9:36
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.
Avatar de Gugelhupf Gugelhupf - Modérateur https://www.developpez.com
le 23/11/2016 à 9:45
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.
Avatar de kilroyFR kilroyFR - Membre actif https://www.developpez.com
le 23/11/2016 à 13:05
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).
Avatar de L4goon L4goon - Nouveau membre du Club https://www.developpez.com
le 24/11/2016 à 14:11
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
Avatar de kilroyFR kilroyFR - Membre actif https://www.developpez.com
le 24/11/2016 à 14:36
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 :



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.
Avatar de L4goon L4goon - Nouveau membre du Club https://www.developpez.com
le 25/11/2016 à 14:33
@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
Avatar de Narann Narann - Membre habitué https://www.developpez.com
le 25/11/2016 à 14:57
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.
Avatar de SQLpro SQLpro - Rédacteur https://www.developpez.com
le 25/11/2016 à 14:57
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 +
Offres d'emploi IT
Responsable de lot / architecte fpga H/F
Safran - Ile de France - Éragny (95610)
Ingénieur produit (Landing gear) H/F
Safran - Ile de France - MASSY Hussenot
Responsable de lot vérification et qualification (IVVQ) H/F
Safran - Alsace - MASSY Hussenot

Voir plus d'offres Voir la carte des offres IT
Contacter le responsable de la rubrique Accueil