Des bases MongoDB libres d’accès : un opérateur français laisse 8 millions d’entrées à disposition

Après je ne dis pas que NoSQL c'est nul. Je dis juste qu'une partie utilise ça parce que ça fait cool, et une autre parce que c'est vraiment justifié. Nombre de fois j'ai entendu, NoSQL c'est l'avenir même Google l'utilise. Oui... sauf que tu n'es pas Google

Tu n'es pas le seul à penser que cette base est une mode je te rassure. Comme tu dis, le BIG DATA, c'est du marketing, c'est la mode du moment, et beaucoup d'entreprise dépensent des sommes monumentales alors qu'elles en ont pas vraiment l'utilité, mais c'est fait pour cette mode. Je l'utilise pour une seule chose, mes applications NodeJS, MongoDb s'intègre bien dans un environnement full javascript. Sinon MySQL c'est bien pour les débutants mais ça reste pour moi loin de PostgreSQL en terme de performances, donc pour la plupart de mes projets j'utilise PostgreSQL et j'en suis ravi, toujours étonné par les capacités de ce SGBD. J'utilise ORACLE aussi mais c'est plus réservé aux entreprises quand même. Je vais me faire taper sur les doigts parce que certains vont me dire que c'est pas comparable, mais pour moi quand j'utilises MongoDB j'ai l'impression d'avoir les mêmes avantages/inconvénients que PHP, pas besoin de se casser la tête avec les types, c'est rapide à faire, mais ça vaut pas un bon truc bien structuré. MongoDB c'est vraiment pour ceux qui veulent faire du stockage sans trop se casser la tête, c'est quand même trèeeeeees loin de la puissance du SQL, dire le contraire c'est ne pas connaitre SQL

Sans parler que même google en revient au sql avec ses techno new sql

Je ne vois pas le rapport entre acidité et dénormalisation ..... Quand j'évoquais l'acidité (mais j'aurais dû le préciser, c'était surtout l'aspect durabilité). Le problème c'est que même lorsqu'elle est souhaitée, elle n'est pas garantie. Je ne vais pas ressortir les articles techniques que j'ai lus et qui ne laissent aucun doute sur la pseudo durabilité de mongodb, même lorsqu'elle est voulue. Après libre à chacun de risquer ses données de production. Enfin concernant l'acidité, Mongodb s'autorise sa propre définition du concept ACID (tant qu'à bouffer à tous les rateliers de l'incompétence ....). Si on prend en compte la difficulté de mongodb à scaler au delà de 100gigas (çà a peut être changé, mais c'est assez risible pour une base se positionnant sur le créneau du big data) on se demande bien ce qui peut attirer autant de développeurs vers cette chose, qui encore une fois dispose d'alternatives beaucoup plus sérieuses dans le domaine du nosql. Tiens d'ailleurs, le sql, tout le monde y revient, et pour une raison assez simple, toutes les personnes susceptibles d'extraire et manipuler de grosses quantités de données, de par leur expérience, ont besoin du sql. Tout ce ramdam n'est pas sans rappeler le xml qui devait éradiquer les bases de données relationnelles. On en prend d'autres et on recommence ! Un des seuls véritables intérêts que je vois pour ces technos nosql c'est de données la possibilité de développer rapidement, mais à condition bien sûr de retourner vers un modèle relationnel fiable. J'ai à plusieurs reprises expériementé les joies de la gestion de la cohérence des données au niveau du code ... alors oui heureusement que les dba sont là pour remettre de l'ordre dans tout ce cirque.

Si je suis en accord avec l'intro et la conclusion, ce qui est au milieu démontre une méconnaissance totale et une fermeture à ce SGBD. Tout d'abord, schemaless ne signifie pas déstructuré, la structure est en effet déportée, à charge du client (donc de l'applicatif). Dans de très rares cas, on a besoin de collections totalement dynamiques (et ceux qui le font, savent ce qu'ils font). Ensuite le système est très permissif : ça ouvre quelques possibilités sympas mais ça a aussi un effet désastreux avec les DBA ou devs qui ne sont pas foutus de lire une doc. Je vois parler d'acidité aléatoire, marrant : la base ne supporte pas de transactions ACID. En dénormalisant correctement les données, on est sensé palier au besoin. Si tel n'est pas le cas, la base n'est pas adaptée à cette utilisation. Je vois ensuite parler de durabilité : la durabilité à un coût, chez mongo, le coût est en performance (d'où le côté permissif si pas besoin), humain (ça rejoint mon paragraphe sur les DBAs) et financier. Concernant la faible adoption de Postgres, c'est pas nouveau et c'est malheureux car c'est une excellente base qui a de très bonnes extensions (je pense par exemple à PostGIS, qui a une sacrée avance sur les implés de mongodb ou elasticsearch). Et pour conclure (j'ai l'impression d'être obligé de préciser), oui cette base est très populaire, oui c'est hype, il est certain qu'en conséquence elle n'est pas adaptée à de nombreux utilisateurs, et oui, y'aura encore des couilles si c'est configuré à la va-comme-j'te-pousse...

Cela est vrai et heureusement. Pour la bd j ai un collègue pour ça. Puis ça nous permet de trouver des excuses pour aller à la machine à café.

Les profils se sont spécialisés. On demande des gens efficaces sur des produits précis. Même le boss d'aujourd'hui est spécialisé : c'est celui qui connait son catalogue de produits et va tous les jours à la pêche du nouveau truc hype qu'il pourra sortir de son chapeau en réunion.

Intégrateurs réseaux. Serveurs messagerie erm crm ged vpn Cisco etc. Bon j ai rajouté en disant j ai rien compris. Je sais de quoi vous parlez mais je suis incapable de parler de détail comme les vôtres. En faite c'est vrai qu il y qu en bd que je suis dépassé.

Ahhh merci pour ce commentaire utile ! Ca change

Effectivement, dans ce cas de figure, c'est moins Mongdb qu'un problème de sécurité qui est en cause. Cependant, la popularité de Mongodb laisse songeur et perplexe .... Déjà, dans ce cas précis, on peine à croire que pour stocker un fichier de données clients, les développeurs aient eu besoin d'une base de données "non structurée" . Parce que franchement, un fichier client, c'est bien connu, c'est tout sauf structuré !!!! Sérieusement ..... Ensuite, d'une manière plus générale, pour ceux qui connaissent l'histoire de Mongodb, ce n'est ni plus ni moins que le résultat d'un développement à l'arrache d'une pauvre base de données documentaire avec pour objectif de surfer sur la mode du big data et du noSQL. Il de se sortir les doigts du *** et d'aller faire un tour sur les sites sérieux pour constater les faiblesses de ce moteur : Acidité aléatoire, aucune scalabilité .... et des pertes de données mémorables en production. Même en restant dans le monde open source, ne serait-ce qu'en prenant la dernière version de postgresql, qui gère nativement le format JSONB, celle-ci explose littéralement les performances de MongoDB. Et pourtant MongoDB est est récemment passé devant postgresql dans le top des bases de données utilisées. Incompréhensible ? Oh que si ! Les développeurs, dopés aux méthodes de développement itératif, y ont vu une occasion unique d'entretenir leur paresse intellectuelle et de jeter à la corbeille toute réflexion sur la structuration de leurs données. Il y aura des morts, parce que cet engouement sauvage, cette paresse intellectuelle finira par se payer, tout comme l'engouement pour le big data laissera son lot de trépanés sur le carreau. Les technos bigdata ont de véritables utilisations sérieuses mais rien ne justifie leur utilisation aussi répandue, sinon l'effet de mode, la soif de développer du business sur du vide, la paresse intellectuelle. le marketing informatique est très fort pour vendre des technos et les sacrifier sur l'hotel de la bêtise humaine.

Même si je ne suis pas informaticien, et donc je n'ai pas les compétences pour écrire ici, je ne suis pas d'accord avec avec votre débat. On peut avoir une bdd super mega de la mort qui tue, mais si vous l'ouvrez à tout le monde, bah, c'est mort, justement ! Et la, le débat c'est pas la bdd c'est comment ils ont paramètrés les accès. Comme des pieds.

Assurément un PEBCAK et trop peu de RTFM pour certains :')

S'il est possible de laisser un SGBD accessible sur une interface publique, ce n'est certainement pas une bonne idée. Le cluster peut être (et est souvent) distant, sur des serveurs ou instances adaptés, mais devrait également être accessible sur une interface privée (matérielle ou logicielle), ou à défaut, au moins être protégé par un firewall... Et enfin, évidemment, l'authentification se fait par le classique trio login/passwd/db, mais est également possible par certificat, kerberos ou encore le très windowsien LDAP...

Clair que dans le cas présent, les architectes n'ont pas été à la hauteur, ce qui me surprend c'est qu'on parle d'un opérateur télécom et que par essence ils ont la sécurité dans leur ADN, ça me paraît aberrant qu'ils aient cumulé ces erreurs de débutants

Si j'ai bien compris l'article, certains utilisateurs ont juste enlevé la restriction de l'écoute sur l'ip locale. Mais c'est pas pour ça que le serveur en question est accessible de toute la planète non plus. Y'a sûrement autre chose pour le protéger en amont. Et si une boîte cumule des neuneus qui arrivent binder sur toutes les ip et en plus les laisser accessibles, je pense qu'il faut très vite se faire de gros soucis.

Tu fais quoi comme trucs en informatique ?

Oua vois êtes chaud les gars. Je suis informaticien mais la j'ai rien compris. En passant. C'est pas parce qu on ne connait rien à la bdd qu on est pas informaticien. On est juste pas dans cette spécialisation. <i>-------<a href="https://play.google.com/store/apps/details?id=com.frandroid.app">Envoyé depuis l'application FrAndroid pour smartphone</a></i>

90% ? Il est gentil :D

Il y a toujours eu des bases documentaires moins structurées à la périphérie des SGBDR (gérées par des améliorations du file system ou par le file system lui-même), dotées d'un explorateur spécifique et servant à stocker des données jamais requêtées globalement (essentiellement en "ajout/archivage", mais pas toujours). Mais donner à ce gestionnaire une interface IP, ne pas la sécuriser, mettre la machine sur le web, et ensuite considérer que toutes les connexions viennent de la boucle locale, tu avoueras que c'est quand même 4 conneries cascadées et collégiales.

C'est tout à fait normal de laisser les BDD accessibles par l'extérieur, tous les autres SGBD laisse l'accessibilité de base. Pour un petit site, utiliser un seul serveur est normal. Lorsque l'on commence à travailler sur de gros projets, c'est un nonsens total de tout avoir sur un seul serveur, on va mettre "le site" sur un serveur avec une BDD distante sur un autre pour des raisons de performances. Ce qui m'inquiète le plus, c'est qu'il semblerait qu'il n'y a pas de couple login/password pour se connecter à une BDD mongo, sinon il n'y aurait pas cet article.

Un ami informaticien m'a dit la chose suivante : " 90% des problèmes en informatique se situe en le clavier et la chaise ".

Jette un œil ici http://www.technologies-ebusiness.com/langages/les-bases-no-sql

Quand je parle d'utilisation, je ne parle pas de charge, mais de ce que chaque soft met et s'attend à trouver dans la base de données. Dès qu'il y a partage, je ne vois pas en quoi il serait plus facile de faire évoluer une base de données non-structurée, dont il faudrait aller chercher la structure dans les différents logiciels, plutôt qu'une base structurée de façon stricte, qui centralise un schéma.

Si je ne me trompe pas on sale quand on hash pas quand on crypte. Puisque la '' sécurité '' du hash dépend du contenu initial, et lors d'un cryptage de la taille de la clé. Enfin bref c'est pas le sujet. Sinon oui, ça devrait être crypté comme tout autre données de toute façon mais bon...

Ils s'attendaient sûrement à plus de client #Troll D'après mon expérience les alentours de 8-10 millions en SQL deviennent vite pénibles si on fait de la sous requête ou du group by... Ça peut être plus ou moins justifié, on ne sait pas comment ils traitent ça..

Tout à fait, c'est l'utilisation qui structure et dans ce domaine un SGBDR montre assez vite ses limites pour du load balancing et des accès concurrents mondiaux comme pour un grand site web non ?

Tu gagnes quoi une fois que t'as compris qu'une base est plus structurée par ses utilisations que par son schéma ? Et que le fait de ne plus rien mettre dans la structure de la DB, ça revient à diluer l'info dans toutes les utilisations ?

Je ne suis pas un expert des bases NoSQL, mais ça a l'avantage d'être plus facilement évolutif en comparaison avec les bases SQL structurées et plus scalable (aspect grid). C'est probablement la raison du succès, aujourd'hui on ne sait pas toujours exactement où on va dès le début mais on commence à courir et on rectifie la trajectoire par la suite. Les capacités de traitement informatique ayant évolué, on accepte de perdre un peu en efficacité en échange de plus de flexibilité. C'est un peu le même concept que l'avènement des langages interprétés comme Java ou C# il y a 15 ans.

Faudrait arrêter de troller sur mongodb. c'est juste une pauvre base documentaire qui ne scale pas au delà de 100go....<i>-------<a href="https://play.google.com/store/apps/details?id=com.frandroid.app">Envoyé depuis l'application FrAndroid pour smartphone</a></i>

Au delà des stats, l'ingénu qui croit qu'il va gagner quoi que ce soit en utilisant un truc non-structuré stockant les data en BSON, il mérite déjà pas le label "informaticien". "Souillon du clavier" lui conviendrai mieux.

Ça pue les devs qui ont fait un caca nerveux pour bosser dur quelque-chose de sexy. De nos jours les SGBDR n'ont plus la côte.... De plus bonjour le gage de sécurité de ne binder que l'adresse de loopback<i>-------<a href="https://play.google.com/store/apps/details?id=com.frandroid.app">Envoyé depuis l'application FrAndroid pour smartphone</a></i>

le truc c'est que la news ne dit pas si les n° de cb sont cryptés...

Je n'ai pas dit le contraire non plus. J'ai simplement réagi au qualificatif de "middleware mongolito hype" ;-)

Question : Je ne suis pas expert, mais ce genre d'informations doivent êtres salées dans une base de donnée ? Donc les numéros de CB cryptés ne devraient pas leur servir à grand chose ?

J'ai pas dit que je décrivais un comportement marginal. J'ai même plutôt dit le contraire.

mais... vraiment des couillons pour faire des conneries pareils... <i>-------<a href="https://play.google.com/store/apps/details?id=com.frandroid.app">Envoyé depuis l'application FrAndroid pour smartphone</a></i>

Oui sauf que là ce sont des "pros" et non la mamie du cantal !!!!

et les numéros des CB sont en clair dans leur base ???? O_o Si c'est le cas, quel grand groupe qui aime la sécurité de ses clients ose privilégier une telle solution ???

Encore une fois la cause du problème se situe entre la chaise et le clavier !

En même temps MongoDB est le 4ème SGBD le plus utilisé dans le monde certes largement derrière Oracle, MySQL et Microsoft SQL Server mais le 4ème tout de même. Postgre SQL et DB2 sont derrière.

MongoDB pour 8M rows? Pour des données utilisateurs avec carte de crédit? je ne comprends pas ce choix. Ne me dites pas qu'ils n'ont pas une licence Oracle ou SQL Server.

"on apprend aujourd’hui que les bases de données MongoDB ne sont pas suffisamment protégées." Non. En l'occurence il s'agit d'un problème purement humain (ie: laisser des bases de données accessibles de l'extérieur #yolo).

Elasticsearch FTW !!! :D/

Quand je vois le genre de middleware hype utilisé de par le monde, je suis toujours amusé. En fait, y a plus personne qui développe rien : on fait ses emplettes dans les trucs amateurs qui, du jour au lendemain, deviennent "incontournables" et "validés par le projet X qui s'en est servi aussi". Alors on prend ... on administre n'importe comment (parce qu'on est "simple utilisateur", à aucun moment on ne comprend vraiment ce qu'on utilise).

lol

Et on peut les récupérer où ces BD ???