GPL
Je pense que l'on connait tous ici la licence GPL qui protège les droits du code source du noyau Linux ainsi que de nombreux autres logiciels libres.
La licence impose à tous les ouvrages protégés par celle-ci de distribuer aux utilisateurs le code source à l'origine du produit fini. La licence est aussi dite virale du fait que tout ouvrage basé sur une modification d'un autre distribué sous licence GPL doit aussi être distribué sous les termes de la licence GPL.
Dit autrement, les possesseurs d'une copie d'un logiciel distribué sous GPL peuvent accéder aux médiums ayant conduit à la construction du dit logiciel mais aussi que toutes modifications d'un logiciel distribué sous GPL doit aussi être redistribué sous licence GPL à ses possesseurs. De ce fait il est assuré que le savoir est partagé.
Oui, mais qu'est-ce que la distribution ? Le terme est ainsi définit par la licence GPL :
To “convey” a work means any kind of propagation that enables other parties to make or receive copies. Mere interaction with a user through a computer network, with no transfer of a copy, is not conveying.
Si on veut traduire cela pourrait donner :
« Distribuer » un ouvrage signifie toute diffusion permettant d'autres parties de faire ou recevoir des copies. Une simple interaction à travers un réseau informatique, sans transfert d'une copie, n'est pas une distribution.
Ah ah ! Je peux donc modifier un logiciel distribué sous GPL, en faire un service réseau et mes utilisateurs interagissant avec ce dernier uniquement par le réseau, nul besoin de transmettre mes modifications.
AGPL
C'est ici qu'arrive la licence AGPL. Elle vient mettre un peu d'ordre dans tout cela :
If you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version.
Si vous modifiez le Programme, il est important que votre version modifiée offre aux utilisateur interagissant avec celle-ci à distance à travers un réseau informatique (si votre version supporte une telle interaction) l'opportunité de recevoir la Source Correspondant à votre version.
You lose, game over. La modification d'un logiciel distribué sous licence AGPL doit aussi est redistribuée sous cette même licence et ce même dans le cas d'une simple interaction par le réseau.
MongoDB
C'est d'ailleurs sous cette licence qu'était distribué MongoDB. Afin que toutes les modifications apportées au projet soient redistribuées à la communauté.
Mais il y a toujours des petits malins à tester les limites. Et puisqu'ils ne veulent pas donner le code source, pourquoi pas le service tout entier ?
SSPL
MongoDB Inc. annonce donc la Server Side Public License. Celle-ci à pour base la license AGPL mais requiert cette fois-ci que toute l'infrastructure permettant de faire tourner un service utilisant MongoDB (ou tout autre logiciel sous cette licence), soit redistribué sous licence SSPL :
“Service Source Code” means the Corresponding Source for the Program or the modified version, and the Corresponding Source for all programs that you use to make the Program or modified version available as a service, including, without limitation, management software, user interfaces, application program interfaces, automation software, monitoring software, backup software, storage software and hosting software, all such that a user could run an instance of the service using the Service Source Code you make available.
« Code Source du Service » signifie, la Source Correspondant au Programme ou sa version modifiée, et la Source Correspondant à tous les programmes que vous utilisez afin de rendre le Programme ou sa version modifiée disponible en tant que service, incluant, mais non limités, logiciels de gestions, interfaces utilisateurs, interface de programmation, logiciels d'automatisation, logiciels de surveillance, logiciels de sauvegarde, logiciels de stockage, logiciels d'hébergement, tout ce qui permettra à l'utilisateur d’opérer une instance du service en usant du Code Source du Service que vous mettez à disposition.
Mais cela ne s'arrête pas là, la redistribution de tout ces éléments doit être faite sous licence SSPL ! Cela ne sera pas sans causer quelques soucis de droit d'auteur étant donné qu'il ne sera pas permis de distribuer sous une autre licence tous les logiciels utilisés pour fournir un service.
En tout cas, cela semble être une belle tentative de la part de MongoDB à faire basculer une bonne partie des utilisateurs vers la version payante du logiciel. Ou peut-être, vers un autre choix de logiciel ?
# Comment ça marche ?
Posté par paulez (site web personnel) . Évalué à 9.
Si je fournis MongoDB "Comme un Service" avec une simple interface web hébergée par un serveur Apache tournant sous Linux, je ne vais pas pouvoir distribuer les sources d'Apache et Linux sous licence SSPL ?
[^] # Re: Comment ça marche ?
Posté par Colin Pitrat (site web personnel) . Évalué à 8.
Les implications légales ne sont pas très claires, il est possible que cette licence ne soit pas valable, d'un point de vue légal, dans la majeure partie des pays du globe. Le but est sûrement, comme dit dans l'article, de faire peur aux utilisateurs de la version gratuite qui "font de l'argent" avec, afin de les faire basculer vers la version payante.
Le résultat risque d'être un fork depuis la dernière version GPL. Où une migration vers d'autres solutions. J'aimerais vraiment voir l'analyse de risque qu'ils ont fait avant de prendre cette décision… C'est pas comme si il n'y avait pas de précédent (MySQL, XFree86, grsecurity …)
[^] # Re: Comment ça marche ?
Posté par jihele . Évalué à 6.
Ce que je comprends de cette phrase c'est que si je développe une appli web à base de MongoDB, je dois la publier sous licence SSPL.
Ça me parait assez gros. On développe une appli web propriétaire pour laquelle on a investi beaucoup de temps dans le développement de couches libres, notamment ODM Mongo Python, et je trouvais le deal assez correct.
Ce modèle me paraît pas mal. On est nombreux à codévelopper des libs Python pour faire de l'API REST et je pense que la plupart des contributeurs développent une appli proprio, mais on essaye de partager le plus possible les bases pour ne conserver que le métier dans le code spécifique à l'appli.
Je ne pense pas qu'on puisse revenir sur le caractère proprio d'une appli comme ça, c'est tout son modèle économique qui est impacté, donc de trois choses l'une
[^] # Re: Comment ça marche ?
Posté par jihele . Évalué à 5.
Je vois des interprétations contradictoires
https://devclass.com/2018/10/17/mongodb-new-license-cloud-service-providers/
Ça n'impacterait que les logiciels liés à l'exploitation de la DB…
mais pas le code métier.
https://techcrunch.com/2018/10/16/mongodb-switches-up-its-open-source-license/
Ici aussi, je comprends que c'est destiné aux boîtes qui fournissent du Mongo DB en cloud, pas des applis basées sur Mongo DB.
[^] # Re: Comment ça marche ?
Posté par Pol' uX (site web personnel) . Évalué à 5.
À mon humble avis, MongoDB fait une erreur majeure de ne pas décrire le sens de « as a service » dans les définitions.
Ceci dit c'est compatible avec l'idée de mettre suffisamment d'incertitude pour pousser à l'adoption d'une licence payante donnant les garanties de liberté nécessaires.
Adhérer à l'April, ça vous tente ?
# Forcer la main, ou juste respecter les (anciennes) règles?
Posté par Jean Gabes (site web personnel) . Évalué à 4.
Je ne suis pas totalement d'accord avec cette vision des choses:
En effet, si tu prends le soucis d'un autre angle, ils demandent simplement la même chose que la GPL, mais au niveau du service, un peu comme on prends au niveau du processus pour la GPL.
Donc forcer oui, mais à respecter les règles du logiciel libre sur le long terme, plus que juste open source, car c'est trop simple de bypasser l'AGPL dans les faits.
Est-ce qu'au passage ceci va faire que certains qui ne veulent pas fournir leur code vont devoir payer, oui. Est-ce si mal que ça? (si on se place du côté logiciel libre).
Bon après d'une manière plus réaliste, je pense comme toi qu'en effet c'est un bon effet marketing & juridique => monétisation en hausse de leur offre. Et si c'est vraiment forcer à ouvrir toute la stack d'un service, ça va migrer sérieusement dans le futur, ou bien ne pas mettre à jour.
[^] # Re: Forcer la main, ou juste respecter les (anciennes) règles?
Posté par Zenitram (site web personnel) . Évalué à 7.
C'est de l'affichage.
Soyons clair : soit MangoDB croit dans le libre et ne filent aucune version de MangoDB en autre chose que SSPL pour que le libre "gagne", soit le libre est juste une méthode pas chère de faire de la pub pour la version payante.
Il n'y a pas d' "angle" dans cette histoire.
Et comme ils vendent une version "commerciale" (cf FAQ deuxième question), voilà tu peux savori ce qu'ils pensent du libre.
Oui, voila.
Ou comment prendre les libristes pour des marketeux gratuits (et le pire c'est que ça marche, pas la première fois que les gens "vendent" du dual-licensing GPL/commercial comme avec des gens aimant le libre et voulant le promouvoir, la bonne blague)
[^] # Re: Forcer la main, ou juste respecter les (anciennes) règles?
Posté par Jean Gabes (site web personnel) . Évalué à 5.
Mais c'est bien ça qui est triste, c'est que ça marche et qu'une fois encore le marketing a bien plus de poids que les faits objectifs.
Là où je pense qu'ils prennent des risques, c'est vraiment sur le fait de devoir mettre toute la stack dans leur propre licence, car dans les faits même ceux qui veulent ça sera infaisable (sauf si tu as tout en MIT/BSD, mais bon tu as bien du LGPL dans le tas, voir du GPL sur des processus à côté).
Donc c'est tellement infaisable que là même le marketing va avoir du mal à cacher le côté totalement faux de l'histoire quand les premiers qui vont "essayer" vont démontrer que c'est infaisable.
Je me doute bien qu'ils ont déjà prévu ça, juste que d'habitude ils mettent déjà les graines de leur future argumentaire dans l'annonce précédente, mais là j'arrive pas à voir l'astuce.
A moins que ce soit un genre de "pied dans la porte": on mets THE grosse limitation dans cette version, ça couine car c'est pas faisable à cause des autres projets GPL qui ne veulent/peuvent pas changer leur licence alors que eux les gentils mongo ils l'ont fait, et donc licence version 2 qui est un peu moins restrictive juste sur ce point là, et hop ils sont les gentils de l'histoire même si on regarde le fil complet c'est totalement l'inverse.
On verra bien, si c'est ça ca va vite arriver.
[^] # Re: Forcer la main, ou juste respecter les (anciennes) règles?
Posté par nico4nicolas . Évalué à 3. Dernière modification le 24 octobre 2018 à 15:54.
La vie selon Zenitram est vraiment simple. Sinon, l'argument est un faux dilemme vieux comme le monde biblique.
[^] # Re: Forcer la main, ou juste respecter les (anciennes) règles?
Posté par Anonyme . Évalué à 3.
Oui, mais là on parle de M o ngoDB.
# Sémantique toxique
Posté par Pol' uX (site web personnel) . Évalué à 5. Dernière modification le 23 octobre 2018 à 14:27.
C'est curieux, tu décris un processus d'hérédité et tu le nommes avec un mot à connotation catastrophiste et dangereuse.
Le fait que des chiens ne donnent pas naissance à des chats, c'est de l'hérédité, pas de la viralité. :)
Adhérer à l'April, ça vous tente ?
[^] # Re: Sémantique toxique
Posté par arnaudus . Évalué à 7.
Je ne suis pas sûr que le terme de "viralité" appliqué à la GPL se réfère spécifiquement à l'hérédité telle que tu la définis.
Tu n'es probablement pas sans savoir que la FSF fait une interpétation assez particulière et assez discutable du concept de "derivative work". Tout le monde est d'accord pour dire que si tu prends un bout de code et que tu le modifies, ton travail est dérivé. De la même manière qu'une traduction de roman, par exemple. La partie "virale" discutable de la GPL repose sur l'affirmation qu'une inclusion ou un lien statique ou dynamique sont également suffisants pour définir un travail dérivé. Le problème me semble assez évident ; pour le commun des mortels, faire
#include "truc.h"et lier la bibliothèque ltruc à la compilation est difficilement traduisible par le concept "mon logiciel est un travail dérivé de la bibliothèque truc". On utilise les fonctions de la bibliothèque, on est dépendant de cette bibliothèque, mais techniquement, notre travail n'est pas une modification de cette bibliothèque, de la même manière qu'une traduction est une modification du roman initial. La situation comparable serait l'écriture d'un,roman qui fait référence à quelques lieux, personnages, ou anecdotes d'autres romans. C'est le genre de situations qui méritent d'être jugées, parce que lancer des grandes conclusions a priori sans regarder en détail la quantité et la nature des emprunts semble assez prématuré.De la même manière, prétendre qu'un logiciel entier est un travail dérivé d'une petite bibliothèque dont deux fonctions et demi sont utilisées dans un bout de code facultatif, ça semble assez prétentieux. C'est l'interprétation "virale" de la FSF, mais ça n'est qu'une interprétation, parce que ça n'est pas du tout évident à la lecture de la GPL (et d'ailleurs, on trouve sur le Ternet plein de billets écrits par des juristes qui remettent en cause cette interprétation).
[^] # Re: Sémantique toxique
Posté par Pol' uX (site web personnel) . Évalué à 5.
Personnellement je pense que, derrière ce terme de « viralité », il y a quelque part une petite envie de revanche, ou a minima de règlement de compte.
D'ailleurs, tu n'es probablement pas sans savoir que ton analogie est douteuse, car si tu ne considères que « faire
#include "truc.h"», tu as raison de considérer que « notre travail n'est pas une modification de cette bibliothèque ».Scoop : tu peux même publier ton source contenant ton include, sans aucune préoccupation vis à vis de la licence du projet truc (GPL ou non), et sans aucune inquiétude de quelque sorte.
Mais revenons à la GPL. On peut étudier la justesse de l'équité de la relation que tente d'établir la GPL entre un « auteur fournisseur » et un « auteur usager » d'un code. Et dans ce cas ce n'est certainement pas la quantité d'effort fournie par l'auteur usager qui nous indique si le programme engendré sera « plutôt » une œuvre dérivée ou « plutôt » une œuvre originale. Et donc retenir cet aspect pour juger de si cette relation est équitable ou non me semble fallacieux.
Je ne connais pas de métrique parfaite pour ça (et je suppose que ça n'existe pas) mais je pense qu'il faut partir de l'effort de substitution.
Si pour mener son projet à bien l'auteur usager devait réécrire le projet truc depuis zéro, on peut imaginer à la louche trois situations :
Concernant la situation qu'on pourrait qualifier de « viralité », il faut avoir à l'esprit que l'auteur fournisseur a fait une offre publique de licence, engageant la réciprocité, indépendamment de savoir qui en ferait quoi. L'auteur usager à accepté l'offre et en a profité mais est libre de ne pas le faire. Si l'auteur usager se sent lésé par ce contrat dans cette situation, il lui est de fait facile de le rompre ; puisque la part considérée du logiciel fournie est minimale ; et que sa substitution peut se faire sans grand effort.
Ainsi, jamais la GPL ne force la main de personne d'une façon qualifiable de virale, parasite, pandémique ou autre. Et qualifier la GPL de « virale » parce que des personnes de mauvaises fois peuvent se sentir lésés d'une offre qu'ils n'ont aucune obligation d'accepter … ça sent un peu l'arnaque intellectuelle.
PS: Perso je développe en python/django. L'ordre de grandeur de mon apport sur des projets réels, c'est 1 pour 50 entre juste mon repos et juste mon virtualenv contenant le framework et quelques apps. Je fais l'impasse sur le code de cpython et les nombreuses bibliothèques système activée par ailleurs… En vrai, je pense que nous sommes des nains consommateurs de logiciels juchés sur les épaules des géantes communautés.
Adhérer à l'April, ça vous tente ?
[^] # Re: Sémantique toxique
Posté par barmic . Évalué à 4.
Ce noyage de poisson… Tu reporte juste la question à celui qui ça utiliser ton travaille. C'est pas avec ce genre de réflexion que la gpl ou le projet gnu ou la fsf vont se grandir.
Il n'est pas question d'hérédité avec la gpl puisqu'elle impose sa licence au code lié. La LGPL a une hérédité par contre. Après si vitalité ne plaît pas choisissez un terme qui vous plaît plus, juste qu'il corresponde à la réalité.
[^] # Re: Sémantique toxique
Posté par arnaudus . Évalué à 3. Dernière modification le 24 octobre 2018 à 11:09.
La GPL impose aussi sa licence au code dérivé, donc là, on peut en effet parler d'hérédité. Contrairement à d'autres licences, qui n'imposent pas la licence du code dérivé.
Mais ça n'est juste pas ce dont on parlait ici. La GPL impose une licence au code réellement dérivé (et ça, c'est le principe du copyleft), et elle tente aussi d'imposer (tout du moins c'est l'interprétation de la FSF, parce que le texte de la GPL n'est pas du tout convainquant là-dessus) sa licence au code lié, en prétendant que la liaison fait du logiciel une œuvre dérivée des bibliothèques.
L'histoire des ambiguités de la FSF est probablement intéressante, mais je n'ai pas vraiment le temps ni l'envie d'aller mettre les mains dans le cambouis. Plusieurs projets sous GPL ont ressenti très tôt le besoin de clarifier la situation, en mettant leur code sous licence GPL-non-virale (typiquement, le kernel Linux, la libc proposée par gcc, la STL C++ de g++, etc). La publication de la LGPL a permi de clarifier les choses pour les bibliothèques sous LGPL, mais paradoxalement, ça n'a pas réellement clarifié les choses pour les bibliothèques sous GPL, puisque ça pourrait donner l'impression que la viralité prétendue de la GPL est établie, ce qui n'est pas le cas.
Après, personne ne prétend que l'interprétation de la FSF est totallement illégitime, puisque si je ne m'abuse, le modèle commercial de plusieurs entreprises a été ou est toujours basé dessus (la lib est disponible sous GPL et sous licence proprio payante, si tu fais du GPL tu peux utiliser la version GPL gratuitement, si tu fais du proprio il faut raquer). Mais disons que dans ce cas, c'est plutôt la menace de procès qui est dissuasive (payer la licence proprio est probablement moins cher que de s'engager dans un bras de fer judiciaire sur un des points les plus compliqués de la licence GPL); ça ne prouve pas réellement que la FSF est dans son droit là-dessus
[^] # Re: Sémantique toxique
Posté par arnaudus . Évalué à 4.
Ah bah oui, bien sûr, il n'y a aucune raison de s'inquiéter de ne jamais pouvoir dstribuer une version binaire d'un logiciel, ou de faire en sorte que son logiciel ne puisse jamais être inclus dans une distribution. Et en plus, c que tu dis est faux, puisque ça dépend du contenu du .h. S'il ne contient que des déclarations, des struct, et des choses comme ça, alors c'est probablement vrai. S'il contient du code (des templates, des trucs inline, etc), alors ça n'est probablement plus vrai. Tu ne peux donc pas faire une généralité à partir de ça.
Euh, désolé, mais la justesse et l'équité, on s'en fout complètement, non? Respecter ou non les clauses de la GPL n'a rien à voir avec des questions de justesse ou d'équité ; si quelqu'un respecte les termes de la GPL sans respecter aucune équité, il ne risque rien ; si quelqu'un respecte les principes généraux du logiciel libre sans respecter les clauses de la GPL, il risque quelque chose.
Si certaines clauses sont illégales, abusives, ou si elles sont ambigües et comprises différemment par l'utilisateur du logiciel que par l'auteur, alors non, ça ne marche pas du tout.
Poutre, paille, tout ça. Tu réponds des généralités à un problème concret, celui d'une extension du concept d'«œuvre dérivée» qu'on peut légitimement considérer comme abusive, de manière à créer une possibilité de «viralité» qui n'est pas prévue (à ma connaissance) dans les différents droits afférents à la propriété intellectuelle.
La liaison (statique ou dynamique, ça n'a pas beaucoup d'importance) d'une bibliothèque fait partie de son fonctionnement normal (et on peut même aller plus loin, c'est même sa seule modalité de fonctionnement). Par ailleurs, en Europe, l'interopérabilité est protégée (on n'a pas à signer de quelconque contrat, licence, ou quoi que ce soit pour écrire un driver, par exemple, et larétro-ingénierie est autorisée à des fins d'interopérabilité). Bref, il existe plein de raisons pour penser que l'idée d'une liaison équivalente à une œuvre dérivée est douteuse, et que cette «viralité», défendue mordicus par la FSF, et qui n'est clairement pas présente dans le code de la GPL, reste une interprétation. Sans jurisprudence bien établie, c'est quand même assez flou, cette histoire.
C'est évidemment vrai, mais je ne vois pas le rapport. Sans compilateur, on ne pourrait rien faire, et pourtant, le compilateur n'impose aucune restriction sur les licences des logiciels. Idem pour l'OS ou pour à peu près n'importe quel logiciel.
[^] # Re: Sémantique toxique
Posté par freem . Évalué à 3.
Alors, juste pour faire mon pointilleux, la glibc6 sur une debian est un exécutable:
Bon, de la à dire que ça sert à quelque chose, il y a un pas que je n'oserais franchir hein :)
Plus sérieusement, on peut aussi considérer que de nombreux outils sont en fait des bibliothèques, c'est juste que le "lien" se fait via socket plutôt que par dlopen(): on peut penser notamment à mpd ou, de ce que j'ai cru comprendre, BSD AUTH, checkpwd, …
Au final, je trouve ça étrange à minima que différencier les droits accordés en fonction du moyen technique utilisé pour établir une relation de dépendance totale ou partielle.
D'ailleurs, en parlant de dlopen(), ça marcherait comment avec une lib sous GPL? Après tout, ce n'est pas pris dans l'édition des liens du coup, non?
[^] # Re: Sémantique toxique
Posté par arnaudus . Évalué à 3.
En plus, c'est contournable dans la plupart des cas. La FAQ GPL de la FSF est particulièrement tortueuse (la plupart du temps, la réponse commence par "it depends"), mais l'idée, c'est que la liaison (dynamique ou statique, aucune raison de faire la différence) est "contaminante", mais ce n'est pas le cas quand on "utilise" un programme. Du coup, on peut avoir l'idée de créer un petit main() de rien du tout sous GPL qui lit quelque chose sur sur l'entrée standard, utilise une bibliothèque GPL, et sort le résultat sur la sortie standard; il est alors possible d'interfacer le programme --- évidemment, il y a un problème de perfs, mais il n'y a pas de raison que ça soit rédibitoire, par exemple pour un truc qui résoud des problèmes compliqués (échecs, gros système d'équation, etc). Bref, ces histoires techniques (qui apparaissent dans la FAQ mais pas dans le texte de la licence lui-même) rendent tout un peu incertain, avec en arrière-plan l'idée que "si vous n'êtes pas sûrs, mettez tout sous GPL".
Si l'exécutable appelle la libc de manière dynamique et va chercher des infos dans différents modules, ça peut être un diagnostic pour vérifier que l'ensemble est bien installé? Autrement, je ne vois pas…
[^] # Re: Sémantique toxique
Posté par freem . Évalué à 3.
Pas si sûr, ça…
Je veux dire, tout dépends du perfs qu'on vise: une lib partagée, ça peut vite bouffer plus de mémoire et de temps au démarrage qu'un IPC. Et puis, si la lib partagée plante, c'est l'appli qui plante, alors qu'avec un IPC type socket unix, ben, on est pas obligé de mourir si le conjoint se suicide à coup de division par 0…
La ou l'on pourrait avoir un boost de performance entre un IPC et une lib GPL (dont on a le source, donc!), c'est si la lib exporte beaucoup de symboles non utilisés par un programme, et que ce programme est le seul à l'utiliser (ça arrive pas si rarement que ça, d'avoir une lib partagée qui ne l'est pas vraiment…).
Dans ce cas, faire un exécutable qui se lie statiquement au code et communique via socket va réduire l'overhead, contourner la licence, et régler le problème d'instabilité voire même de potentielles escalades de droits (et j'ai parlé que de sockets, qu'on peut en plus trimbaler d'une machine physique à une autre, pas de trucs plus poussés ou l'impact de perf est plus réduit).
Bref, considérer le "shared library" comme la panacée, je trouve ça exagéré. Pour moi, il y a un juste milieu entre le multi-processus, les lib partagées, et les libs statiques, qui change en fonction des besoins en blindage, performance et souplesse.
# Le mieux est d’utiliser une autre DB
Posté par Crp (site web personnel) . Évalué à 3.
J’ai rencontré deux problèmes basique avec MongoDB :
- Lorsqu’on trie les résultats et qu’une valeur est nulle, elle apparaitra toujours en tête quel que soit l’ordre du trie (ascendant ou descendant) et il n’y a pas d’option pour corriger cela simplement.
- J’ai une petite DB avec environ 5000 entrées, trier les résultats en fonction d’une clé qui ne peut être qu’un entier me stature la mémoire ! J’ai dû passer de 32MB, par défaut, à 512MB pour que ça fonctionne. Ce n’est pas un gros drame puisque mon serveur a quelques Go de disponible, mais c’est étonnant que MongoDB ait besoin de plus de 32Mo pour trier 5000 entiers !
[^] # Re: Le mieux est d’utiliser une autre DB
Posté par grim7reaper . Évalué à 5.
Est-ce que MongoDB c’est pas overkill pour 5 000 entrées ?
Ça me rapelle https://adamdrake.com/command-line-tools-can-be-235x-faster-than-your-hadoop-cluster.html
Quand un truc est prévu pour gérer de gros volumes, si tu travailles sur des trucs minuscules et bien l’overhead risque d’être extrêmement visible.
[^] # Re: Le mieux est d’utiliser une autre DB
Posté par barmic . Évalué à 3.
Il n'y a que sqlite et derby qui sont prévus pour 5000 entrées. Mongo ne possède pas un gros overead en principe. Mais surtout il est pas vraiment fait pour de gros volume. Ça n'est vraiment pas une base taillée pour le big data (ça ne monte pas vraiment en charge en fait).
[^] # Re: Le mieux est d’utiliser une autre DB
Posté par devnewton 🍺 (site web personnel) . Évalué à 2. Dernière modification le 24 octobre 2018 à 08:36.
Pourquoi?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Le mieux est d’utiliser une autre DB
Posté par barmic . Évalué à 6.
Je ne sais pas si ça vient du modèle de NoSQL, mais quand on parle de big data on pense plus facilement à cassandra ou hbase qui sont une magnitude au dessus amha.
[^] # Re: Le mieux est d’utiliser une autre DB
Posté par groumly . Évalué à 5.
En gros, les perfs s’ecroulent des que tu as plus de données que tu as de ram dispo.
En parallèle, si ton data set tient en ram, soit c’est pas du big data, soit t’es un milliardaire excentrique qui peut se permettre plusieurs teras de ram juste pour ton cluster mongo.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Le mieux est d’utiliser une autre DB
Posté par barmic . Évalué à 3.
Pour ton second problème, ça n'est pas forcément choquant. Est-ce que le champ en question est indexé ? Quelle taille font tes documents ? Est-ce que tu fais une projection de très données ?
[^] # Re: Le mieux est d’utiliser une autre DB
Posté par Crp (site web personnel) . Évalué à 1.
La commande db.collection.stats() me donne: size: 108258530, count: 5175, avgObjSize: 20919
J’affichais 50 résultats par page, les premières pages fonctionnaient correctement mais à partir de la page 70, la mémoire saturait. J’ai limité les champs retournés grâce à une projection, ça m’avais permis de gagner quelques pages. Créer un index aurait certainement résolut le problème, mais je trouvais ça abusé d’indexer des entiers naturels. Augmenter la mémoire utilisée ne me dérangeais pas et ça n’avait pas d’impacts sur les performances (la première page s’affichait aussi rapidement que la dernière).
Ce problème est arrivé après avoir ajouté un champ qui augmentait considérablement la taille des documents (+15ko), ce champ n’était pas utilisé pour la recherche.
[^] # Re: Le mieux est d’utiliser une autre DB
Posté par barmic . Évalué à 4.
:) ben si quelque soit la solution de stockage que tu choisi. Un index ça sert à ne pas parcourir la totalité de tes données (c'que les english appellent fullscan). Même s'il s'agit d'un booléen, si tu n'a pas d'index ton moteur de stockage doit parcourir toutes tes données les unes après les autres pour te données un résultat. Un index lui permet d'avoir plus d'info sur les données stockées sans avoir à les parcourir.
C'est clairement ce qui fais généralement le plus de mal à mongo : augmenter la taille des documents.
[^] # Re: Le mieux est d’utiliser une autre DB
Posté par freem . Évalué à 2.
Bah, en fait, si tes entiers tiennent sur 8 octets chaque mais que t'en as moins de 65000, un hash sur 2 octets pourrait les indexer pour te permettre de les retrouver plus vite, potentiellement.
Je ne connais pas mongoDB, genre, pas du tout en fait, mais bon, si t'as un tableau d'indexes de petite taille, tu peux améliorer la localité des données et donc améliorer l'usage des caches CPU, non?
# TLDR
Posté par devnewton 🍺 (site web personnel) . Évalué à 5.
AGPL ou SSLL peu importe, c'est trop long et compliqué pour les décideurs pressés. En matière licence, la taille compte: rien ne vaut une petite MIT !
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: TLDR
Posté par freem . Évalué à 4.
L'important n'est pas la taille, mais qu'elle laisse bosser :)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.