MongoDB sort en version 2.2

• # De la simplicité de MongoDB

  Posté par LupusMic (site web personnel, Mastodon) le 30 août 2012 à 02:01. Évalué à 10.

  

  C'est un mensonge. Déployer sérieusement MongoDB requiert beaucoup de rigueur, et même comme ça c'est loin d'être simple. J'avais dû réaliser les scripts de démarrage, de maintenance et de sauvegarde pour un jeu (qui devait scaler, mais qui n'a jamais dépassé les 16k users :o) ). Ben c'est franchement la croix et la bannière pour assurer un service correct, savoir ce qui se passe, comprendre pourquoi la réplication ne s'opère pas, comprendre pourquoi une collection a été créée avec le même sur deux serveurs d'un même shard, etc.

  Bref, pas si simple.

  • [^] # Re: De la simplicité de MongoDB

    Posté par Grégoire Seux (site web personnel) le 30 août 2012 à 07:36. Évalué à 4.

    

    Effectivement, mongodb peut se révéler une technologie étonnante lorsqu'on l'utilise à grande échelle et dans le but d'en tirer une grande performance.
    En revanche, l'administration est simplissime tant qu'on reste dans des petits clusters (2 shards, 3 serveurs par shards) ce qui est le cas de la plupart des utilisateurs de mongodb.

    Un des points faibles de mongodb reste son design (lock global puis par database, un thread par connection entre autres). Mais son objectif de simplicité est, je pense, atteint.

    • [^] # Re: De la simplicité de MongoDB

      Posté par isildur37 le 30 août 2012 à 09:42. Évalué à 2.

      

      Le principe du NoSQL c'est justement de relâcher cette contrainte habituelle des bases de données relationnelles qu'est le contrôle absolu des données.
      La scalabilité ce n'est pas juste répartir ce qui se calculait sur un serveur. C'est beaucoup plus compliqué que cela. Déjà, quand on développe une appli parallèle, il est souvent assez complexe de savoir précisément ce qui se passe sur chacun des thread/process. Donc quand on applique ce principe à une appli, ça devient d'autant plus compliqué…
      Donc, quand on veut scaler réellement, effectivement, il y a une complexité, mais qui pour le moment existe dans tous les logiciels que j'ai pu tester :s

• # Première appréciation

  Posté par FantastIX le 30 août 2012 à 10:11. Évalué à 1.

  

  Je suis arrivé à la leçon 13 de MongoDB et je ne suis déjà pas d'accord avec au moins deux principes. D'abord les opérateurs de comparaison: le style find( … {name: {$gt: …}} ne me plaît pas du tout. Puisqu'il s'agit de Javascript, je me serais attendu à passer un argument de type fonction ou callback.

  Je ne suis pas non plus d'accord avec le principe de fonctionnement de la méthode update (ou avec son nom), qui en réalité remplace un document par l'argument. Le nom de la fonction ne correspond donc pas à sa mise en oeuvre. Ça éviterait le loin-d'être-intuitif opérateur $set, un peu trop pour moi. Intuitivement, d'ailleurs la démo le montre, on s'attend à ce que les arguments de update ne mettent à jour que les propriétés spécifiées par l'argument. Donc soit le nom "update" est très mal choisi (auquel cas "replace" conviendrait bien mieux), soit sa mise en oeuvre devrait ne mettre à jour que les propriétés spécifiées.

  Sinon MongoDB est en effet très intuitif, en tous cas pour ce que j'en ai essayé.

  • [^] # Re: Première appréciation

    Posté par fredoche le 30 août 2012 à 10:35. Évalué à 3.

    

    Hello, le problème de base, et la raison pour laquelle, à mon avis, toutes les requêtes ne fonctionnent pas avec des callbacks écrites en js, c'est que le js est à priori lent comparé au reste du code mongo en c++. Donc, si on veut faire de bonnes requêtes, il faut juste utiliser les structures de données descriptives pour exprimer la teneur du dataset, et laisser le js là ou la performance n'est plus critique, ou sur de plus petits jeux de données.

    • [^] # Re: Première appréciation

      Posté par FantastIX le 30 août 2012 à 14:26. Évalué à 2.

      

      […] la raison pour laquelle, à mon avis, toutes les requêtes ne fonctionnent pas avec des callbacks écrites en js, c'est que le js est à priori lent comparé au reste du code mongo en c++.

      Je comprends. Mais n'est-il pas possible d'optimiser l'exécution de telles fonctions, d'une manière ou d'une autre, de faire en sorte qu'elles n'aient qu'un impact limité sur les performances? C'est juste une question de curiosité.

  • [^] # Re: Première appréciation

    Posté par case42 (site web personnel) le 30 août 2012 à 10:56. Évalué à 5.

    

    Je pense que ton problème avec "update" se résout de lui même une fois que tu intègre bien que MongoDB est une DB orientée document . Quand tu update quelque chose, c'est forcement le document dans son ensemble. Penser que tu ne mets a jour que les champs spécifiés montre que tu penses encore en termes de tables relationnelles…

    • [^] # Re: Première appréciation

      Posté par FantastIX le 30 août 2012 à 14:22. Évalué à 5.

      

      Quand tu update quelque chose, c'est forcement le document dans son ensemble.

      Ce n'est qu'une manière trop hâtive AMHA de modéliser ce concept. Si je mets un document à jour, je le remplace rarement (jamais?) dans son intégralité! Ça, c'est le logiciel qui le fait. Quand je mets un document à jour, je modifie quelques phrases ou paragraphes mais jamais tout d'un coup. Jamais, dans aucun système informatique que j'aie eu l'occasion de [bien] connaître le concept de "mise à jour" ne correspond au remplacement intégral du système, ce qui s'apparente à une réinstallation. Pourquoi ce concept devrait-il être modifié dès lors qu'on s'adresse à des documents.

      D'ailleurs si la démo en ligne ajoute cet indice quant à l'utilisation de la commande update, c'est justement que ses concepteurs se sont préparés à ce qu'il y ait confusion, ce qui confirme en substance mon argumentation! Si c'était limpide dans leur réflexion, alors pourquoi persister dans cette direction, qu'ils savaient pertinemment source de confusion? (poil aux arpions.)

      Penser que tu ne mets a jour que les champs spécifiés montre que tu penses encore en termes de tables relationnelles…

      (Faudrait vraiment être dans ma tête pour affirmer ça! Allez, encore un petit effort…)

      Que nenni, je me réfère à tout ce que je connais, où le concept "mise à jour" est le remplacement d'une partie du système ou de l'objet auquel s'applique la mise à jour. Pas l'objet dans son intégralité, auquel cas un autre terme que "mise à jour" doit être envisagé.

      Et de toutes façons, "update" est un terme beaucoup trop généraliste pour être compris de manière irréfutable comme les concepteurs l'entendent. Plus évident à appréhender: "update_properties()", "update_metadata()", "update_document_descriptor()" ou encore "replace_document()". Ce sont juste des suggestions à brûle-pourpoint, pas nécessairement appropriées, mais qui veulent illustrer à quel point la précision des termes utilisés réduit le doute quant à la compréhension de leur nature et de leur mise en oeuvre.

      Un système est intuitif s'il se base sur des concepts connus et maîtrisés, par exemple le langage. Demander à ce qu'on considère qu'une mise à jour est un remplacement est une erreur. Demander aux utilisateurs et aux développeurs de donner une définition intuitivement contradictoire à des termes bien connus et dont la signification est bien maîtrisée, bien assimilée est une erreur.

      Je pense que ton problème avec "update" se résout de lui même une fois que tu intègre bien que MongoDB est une DB orientée document .

      (La bonne vieille rengaine du "changement de paradigme", si j'ai bien compris?)

      Je répète: faudrait vraiment être dans ma tête pour affirmer ça. Que je ne sois pas d'accord avec un concept ou une mise en œuvre ne signifie absolument pas que je ne l'ai pas… intégré, compris ou quelqu'autre forme de limitation intellectuelle dont je pourrais être affublé.

      • [^] # Re: Première appréciation

        Posté par rogo le 31 août 2012 à 14:22. Évalué à 2.

        

        Je ne souscris pas à ta distinction entre update et replace.

        Je tente une transposition dans le langage de programmation C. Selon tes critères, le code a = a + 1; serait un replace du document-variable a. Idem pour a = f(a);. Avec le vocabulaire MongoDB, ce serait un update de a, alors que selon toi un update correspond à a[0] = 0;. Mais cette dernière opération n'est pas prévue dans MongoDB, puisque le document est un élément atomique du stockage. À partir du moment où on intègre ce principe, la dénomination update me semble justifiée : on modifie un document de la même façon qu'on modifie une variable atomique.

        C'est peut-être plus clair quand on connait le principe sous-jacent. On présuppose que l'application cliente fonctionne à la façon d'un ORM classique : on interroge la base pour récupérer des données structurées en "modèles", on les traite côté client, on sauvegarde chaque modèle modifié. En pseudo-code :

        post = Post.find(postid) # fetch from DB
        post.addcomment(...)
        post.save()              # write back to DB (update)
        
        

        AMHA, MongoDB est particulièrement adapté à ce mode de fonctionnement basé sur un ORM à la Active Record.

        • [^] # Re: Première appréciation

          Posté par FantastIX le 31 août 2012 à 16:47. Évalué à 0.

          

          Je tente une transposition dans le langage de programmation C.

          Cette transposition est inappropriée. Je parle du langage textuel utilisé par la syntaxe. Tu ne peux comparer des symboles (+, -, *, /, =) avec du langage textuel (insert, update, set) car la compréhension et l'appréhension des deux ne repose pas sur les mêmes bases. On n'aborde pas un symbole et un mot de la même manière.

          C'est peut-être plus clair quand on connait le principe sous-jacent.

          Et c'est précisément là mon opposition: la syntaxe est intuitive si elle se suffit à comprendre les effets d'une opération (au sens général). Si "c'est plus clair en connaissant les principes sous-jacents" c'est précisément que la syntaxe n'est pas intuitive.

          Toute mon argumentation repose sur le simple fait que l'auteur de la démo s'attendait à ce qu'il y ait confusion, c-à-d à ce que la fonction update() n'est pas intuitive. Et je ne fais qu'expliquer en quoi elle ne l'est pas.

          Je te suggère de lire (si ce n'est déjà fait) mes commentaires plus bas et celui de lothiraldan.

    • [^] # Re: Première appréciation

      Posté par FantastIX le 30 août 2012 à 16:57. Évalué à 0.

      

      Une petite analogie, pour se détendre?

      MongoDB: J'ai mis à jour le verre de Canada Dry par du Whisky.
      FantastIX: Non, tu as remplacé le Canada Dry par du Whisky, je me fous du verre!
      MongoDB: Mais non! J'ai mis à jour le Canada Dry par du Whisky.
      Le client: Sont devenus zinzins, m'en vais voir au café d'en face!

  • [^] # Re: Première appréciation

    Posté par lothiraldan le 30 août 2012 à 15:14. Évalué à 4.

    

    Tout d'abord, pour les opérateurs de comparaison, il faut se rappeler que MongoDB, bien qu'ayant un client Javascript, est une base de donnée C++ et surtout qu'il est utilisé depuis de nombreux languages différents. C'est déjà assez le bordel quand on veut faire un map/reduce depuis python (on doit passer des fonctions js sous forme de string), encore heureux que ça ne soit pas du js pour juste les comparaisons.

    Ensuite concernant la méthode update, je vois pas trop de quoi tu parle. Ex:
    > db.test.find()
    > db.test.save({'a': 'a', 'b': 'b', 'c': 'c'})
    > db.test.find()
    { "_id" : ObjectId("503f653894950c048f876c37"), "a" : "a", "b" : "b", "c" : "c" }
    > db.test.update({'a': 'a'}, {$set: {'b': 'd'}})
    > db.test.find()
    { "_id" : ObjectId("503f653894950c048f876c37"), "a" : "a", "b" : "d", "c" : "c" }

    J'ai plutôt l'impression que quand tu fais fais ton update, le critère ne match rien et dans ce cas crée un nouveau document. (cf http://www.mongodb.org/display/DOCS/Updating#Updating-%7B%7Bupserts%7D%7D)

    Sinon, ayant déjà utilise l'Aggregation Framework, c'est un outil très puissant et son arrivée fait du bien (plus besoin d'écrire du js depuis un autre language (dsl pour le troll, j'ai pas put me retenir)).

    • [^] # Re: Première appréciation

      Posté par FantastIX le 30 août 2012 à 16:34. Évalué à 4.

      

      Ensuite concernant la méthode update, je vois pas trop de quoi tu parle.

      db.test.update({'a': 'a'}, {$set: {'b': 'd'}})
      
      

      J'ai omis de préciser que c'est justement cet argument "$set" qui me pose ce problème de sémantique.

      Update a besoin d'un argument supplémentaire, $set, pour qu'on se ramène à ce que je conçois intuitivement d'une mise à jour, c-à-d la modification partielle des propriétés du document. Pour dire comme Coluche: «c'est plus long, faut faire le nœud!»

      J'irais même jusqu'à dire que l'usage de "update()" et "set$" conjointement remplissent des fonctions dont la signification intuitive de l'une est la mise en oeuvre de l'autre, à savoir update() = mise à jour partielle et $set = remplacement. De plus update( …. {property1: value} ) — donc sans l'argument $set — est, dans les faits, un remplacement du document. Bref…

      Considérons la situation suivante:

      • update( doc_id, array_of_properties ) met à jour les propriétés correspondantes du document. Si certaines propriétés de array n'existent pas dans le document, elles sont ajoutées. C'est l'équivalent d'une fusion entre les deux collections de propriétés, celles du document et l'argument.

      • replace( doc_id, array_of_properties ) remplace le[s propriétés du] document par les propriétés indiquées dans l'argument.

      Ces deux fonctions sont intuitives, parlent d'elles-mêmes, sans ambiguïté et n'ont pas besoin du degré de complexité (support de la fonction $set) pour correspondre à l'idée dont on s'en fait. Et là, je suis satisfait car je ne découvre pas de comportement caché ou implicite. (Et, surtout, j'ai pas besoin de lire la doc pour me rendre compte qu'on ne m'a pas tout dit à propos d'Henry^Wupdate()!)

      D'après la démo:

      db.unicorns.update( {_id: ObjectId('503f73fb563d8a0d850007b3')}, {weight: 55} )
      Well, something's not right, we lost the name, gender and vampire kill counter
      Ah, right, it turns out that update updates the entire document with the new value

      D'abord, il conviendrait de dire « it turns out that update replaces the entire document with the new value ». Le comportement décrit n'est pas une mise à jour mais un remplacement!

      Mon point de vue est que update, avec ses deux arguments, devrait se limiter à mettre à jour les propriétés qu'on lui demande. C'est d'ailleurs la définition d'une mise à jour.

      Allez, honnêtement, que signifie db.unicorns.update( {_id: ObjectId('503f73fb563d8a0d850007b3')}, {weight: 55} ) de manière intuitive, si l'on s'en tient uniquement à ce qu'on lit? «Mets-moi à jour ces propriétés-là dans le document dont l'ID est 503f73fb563d8a0d850007b3 avec ces valeurs-là.» L'élimination des autres propriétés est un comportement auquel on ne s'attend pas de manière naturelle. La preuve, puisque la démo l'affirme: « Ah, right, it turns out that update updates (replaces) the entire document with the new value »!

      Je pense pouvoir être difficilement plus explicite.

      • [^] # Re: Première appréciation

        Posté par lothiraldan le 30 août 2012 à 19:16. Évalué à 3.

        

        Ok au temps pour moi, je suis d'accord que ça serait plus intuitif. Mais il ne faut pas oublier qu'il n'y a pas que $set qu'on peut utiliser avec update, ya aussi tout celà : http://www.mongodb.org/display/DOCS/Updating#Updating-ModifierOperations.

        Et comme on peut les combiner entre eut (on peut mettre un $inc et un $set dans la même requête), ça permet d'avoir une api cohérente je trouve.

        Par contre, le fait qu'on remplace le document quand on ne met de modifier n'est pas des plus intuitif, on est d'accord (même si c'est clairement documenté (http://www.mongodb.org/display/DOCS/Updating#Updating-update%28%29). Je suis pas sûr que l'avoir exposé à des débutants dans la démo soit une bonne idée, je connaissais pas cette fonctionnalité avant de te lire perso.

        • [^] # Re: Première appréciation

          Posté par FantastIX le 31 août 2012 à 09:55. Évalué à 4.

          

          Par contre, le fait qu'on remplace le document quand on ne met de modifier n'est pas des plus intuitif, on est d'accord

          Bien :-) .

          Mais il ne faut pas oublier qu'il n'y a pas que $set qu'on peut utiliser avec update, ya aussi tout celà : http://www.mongodb.org/display/DOCS/Updating#Updating-ModifierOperations.

          Je me doutais effectivement qu'il ne devait pas y avoir que $set mais, si on y réfléchit, il aurait été tout aussi simple, peut-être même plus, de définir inc(), set(), unset(), push(), etc en tant que fonctions, non? genre db.unicorns( {name: 'mathusalem'} ).set( {age: 'unknown'} ) . N'est-ce pas plus simple?

          Et comme on peut les combiner entre eut (on peut mettre un $inc et un $set dans la même requête), ça permet d'avoir une api cohérente je trouve.

          L'API est sans doute cohérente avec elle-même mais pas nécessairement intuitive. Si on sait que les modificateurs renvoient tous le document sur lequel ils agissent, pourquoi pas

              db.unicorns( {name: 'mathusalem'} ).set( {weight: 'unknown'} ).inc( {age: 900} )
          
          

          L'API actuelle apporte du bruit inutile; pourquoi imposer l'utilisation d'une méthode update() alors qu'on sait très bien (ou devrait savoir) quel sera l'effet du modificateur, surtout si ce modificateur a un nom suffisamment intuitif, ce qui a l'air d'être le cas. Au final, update() ne sert qu'à rappeler qu'on va faire une modification mais dont la portée ou la signification est déterminée par le modificateur qu'on lui passe, ce qui ajoute encore à la confusion possible. Donc éliminer update() (qui n'apporte rien) et convertir les modificateurs en fonctions serait plus logique et donnerait une syntaxe plus claire et facile à appréhender, selon moi.

          Ah oui, je préfère aussi mais alors nettement ça

              db.unicorns( {name: 'mathusalem'} ).unset( [age, weight] )
          
          

          à ceci

              db.unicorns( {name: 'mathusalem'} ).unset( {age: 1, weight: 1} )
          
          

          Le ": 1" est du bruit inutile, {age: 0} n'a pas plus de sens que {age: 42}; cette syntaxe devrait être simplifiée.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.