MongoDB 1.4, prêt pour la production

Posté par  (site web personnel) . Modéré par j.
Étiquettes :
22
26
mar.
2010
Base de données
MongoDB est une base de données de type documents, sous licence GNU AGPL V3, et dont la version 1.4 vient de sortir. Elle s'inscrit dans le mouvement NoSQL, et propose des fonctionnalités très intéressantes :
  • Le stockage des documents se fait dans un format très proche du JSON (le BSON) et sans avoir à imposer un schéma ;
  • Les requêtes dynamiques sont d'une richesse fonctionnelle que je pense être équivalente au SQL, et de nouveaux opérateurs font apparition au fur et à mesure des versions ;
  • Il est possible d'indexer plein de choses, dont les objets internes et, nouveauté de la 1.4, des données géospatiales ;
  • Les requêtes peuvent être profilées ;
  • Il est faisable de stocker des objets binaires volumineux, comme des photos ou des vidéos, dans MongoDB grâce à GridFS ;
  • MongoDB supporte la réplication, le failover, et de manière expérimentale le sharding automatique ;
  • Des pilotes permettent de l'utiliser depuis de nombreux langages, dont le PHP, le Ruby et le Python.
Cela en fait une base de données solide, offrant des performances impressionnantes. Elle est déjà utilisée par de grands noms comme Sourceforge, EA, le New-York Time et bien d'autres. Elle me semble être particulièrement bien adapté pour le développement web (enfin, si vous visez à devenir le prochain twitter, Cassandra est probablement un meilleur choix). Certains prédisent même qu'elle pourrait prendre la place de MySQL dans ce domaine.

Aller plus loin

  • # Théorème CAP

    Posté par  (site web personnel) . Évalué à 10.

    L'article suivant explique bien la différence fondamentale entre les bases de données relationnelles (MySQL, PostgreSQL et toutes les autres) et les bases NoSQL :
    http://blog.nahurst.com/visual-guide-to-nosql-systems

    CAP est un sigle pour désigner (traduction approximative) :
    - Consistency (cohérence) : chaque client a toujours la même vue des données
    - Availability (disponibilité) : tous les clients peuvent lire et écrire
    - Partition tolerance (tolérance au partionnement ?) : le système peut être réparti physiquement à travers le réseau

    Le théorème CAP dit qu'on peut pas tout avoir : au mieux, on peut en avoir que deux.

    Les bases de données relationnelles ont choisi Consistency+Availability (donc mauvaise performance pour une base distribuée), Cassandra et CouchDB ont choisi Availability+Partition tolerance (donc mauvaise cohérence), et MongoDB a choisi Consistency+Partition tolerance (donc mauvaise disponibilité).
    • [^] # Re: Théorème CAP

      Posté par  . Évalué à 3.

      Je ne comprend pas très bien. La « partition tolerance » permet d'augmenter la disponibilité, non ?

      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

      • [^] # Re: Théorème CAP

        Posté par  . Évalué à 2.

        Tu dois quand même perdre en disponibilité pour l'écriture.

        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

    • [^] # Re: Théorème CAP

      Posté par  . Évalué à 3.

      D'après le théoreme, que je ne connaissait pas, le Partition tolérance ce defini comme :

      No set of failures less than total network failure is allowed to cause the system to respond incorrectly ( http://www.julianbrowne.com/article/viewer/brewers-cap-theor(...) )

      On peut faire ça avec les RDBMS classiques il me semble, non ?
    • [^] # Re: Théorème CAP

      Posté par  . Évalué à 2.

      MongoDB a choisi Consistency+Partition tolerance

      D'après ce que je comprends de Nosql, la cohérence est de type 'eventually consistency' pas stricte. C'est un peu gonflé de mettre ça comme choix numéro 1.
    • [^] # Re: Théorème CAP

      Posté par  . Évalué à 10.


      Le théorème CAP dit qu'on peut pas tout avoir : au mieux, on peut en avoir que deux.


      Ah! moi je ne connaissais que le théorème BAC qui me bien parait plus intéressant car on peut satisfaire les 3 :
      - le Beurre
      - l'Argent du beurre
      - Le Cul de la crémière.

      Le vendredi, c'est permis :o)
      • [^] # Re: Théorème CAP

        Posté par  . Évalué à 1.

        Et tu as oublié la dernière composante : le sourire du crémier.

        Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

    • [^] # Re: Théorème CAP

      Posté par  . Évalué à 1.

      Je penses mal comprendre une partie de ton propos : quand tu parle de mauvaise disponibilité pour MongoDB, tu parles de principe théorique mais pas réel? ou alors quel sont les limites de mongo dans ce domaine?
    • [^] # Re: Théorème CAP

      Posté par  (site web personnel) . Évalué à 2.

      Un lien intéressant sur ce sujet : http://pl.atyp.us/wordpress/?p=2521

      Il explique Availability et Partition tolerance.
    • [^] # Re: Théorème CAP

      Posté par  (site web personnel) . Évalué à 3.

      Je ne sais pas si les développeurs de MongoDB lisent LinuxFr.org, mais ils viennent de publier un billet sur le sujet : http://blog.mongodb.org/post/475279604/on-distributed-consis(...)
  • # What about CouchDB?

    Posté par  . Évalué à 2.

    "Certains prédisent même qu'elle pourrait prendre la place de MySQL dans ce domaine."

    Moi je vois encore pas mal de compétition entre MongoDB et CouchDB. Il est encore trop tôt à mon avis pour dire lequel de ces deux projets sera le prochain MySQL.
    • [^] # Re: What about CouchDB?

      Posté par  (site web personnel) . Évalué à 2.

      L'impression que j'en ai est que CouchDB a de plus en plus de mal à avancer et à convaincre. Ça semble vraiment être un projet qui a vendu trop de choses sur le papier, et qui maintenant, n'arrive plus à assumer. J'ai pu discuter avec des personnes qui revenaient du NoSQL Live à Boston [http://nosqlboston.eventbrite.com/], et elles me disaient qu'elles pensaient que CouchDB allaient sûrement mourir.

      Par contre, MongoDB a de la concurrence pour devenir le prochain MySQL, c'est indéniable. Par exemple, j'aimerais bien trouver un peu de temps pour explorer Riak [http://riak.basho.com/].
      • [^] # Re: What about CouchDB?

        Posté par  . Évalué à 3.

        Moi l'impression que j'avais c'est que les base No-SQL et les base SQL devaient co-exister sur des applis différentes, alors "le prochain MySQL", je vois pas très bien ce que ça veut dire.

        Comment ces BDD vont-elles s'imposer et surtout où??
        Moi je vais pas lancer mon Twitter perso et me jeter sur le premier hébergeur qui va me le proposer...
        MySQL, par contre, c'est limite si tu t'insurges pas quand c'est pas inclus d'office!
        • [^] # Re: What about CouchDB?

          Posté par  (site web personnel) . Évalué à 4.

          De ce que j'en ai compris, être "le prochain MySQL", ça veut surtout dire être le choix par défaut pour commencer une nouvelle application quand on n'a pas de contraintes particulières. Donc, ça demande à être disponible sur plein d'hébergeurs, de ne pas trop mal marcher, d'avoir du support, de ne pas être trop compliqué et d'être assez complet (avoir du full-text et des indexes géospatiaux, par exemple).

          Je verrais bien ces bases de données NoSQL se répandre pour les applications web, car les bases de données SQL ne sont pas vraiment ce qu'il y a de plus adaptées pour ça, et ça se ressent quand on utilise des ORM.
      • [^] # Re: What about CouchDB?

        Posté par  (site web personnel) . Évalué à 1.

        Couchdb est quand même
        1) trés connu ( cf article sur linux mag )
        2) utilisé pour desktopcouch ( et donc gwibber, ubuntuone, feedie, etc )
      • [^] # Re: What about CouchDB?

        Posté par  (site web personnel) . Évalué à 2.

        CouchDB est programmé en Erlang alors que MongoDB semble être programmé en C++. N'est-ce pas le fait qu'Erlang soit un langage peu connu des programmeurs (comparé au C++) qui limite les capacités de développement de CouchDB par rapport à d'autres projets ?
        • [^] # Re: What about CouchDB?

          Posté par  (site web personnel) . Évalué à 2.

          Le fait que ce soit du Erlang doit jouer, mais ça n'explique pas tout à mon avis.

          Si on prend un autre domaine, les files d'attentes, il y a également une forte concurrence entre différents produits. Le gagnant (à mes yeux) est RabbitMQ, qui est également en Erlang. Et pourtant, il y avait une concurrence avec d'autres projets en C (beanstalkd), Java (ActiveMQ) ou Ruby (Starling).
    • [^] # Re: What about CouchDB?

      Posté par  . Évalué à 9.

      Surtout que MySQL, c'est pas forcement un compliment, c'est juste répandu.
  • # pitié ...

    Posté par  . Évalué à 8.

    Par pitié, qu'on arrête de comparer MongoDB, Cassandra, Redis, etc à une base de données. Comparer MongoDB avec une "vrai" base de données comme PostgreSQL c'est tout simplement un non sens.
    • [^] # Re: pitié ...

      Posté par  . Évalué à 3.

      Je suis bien d'accord. Mais il me semble que simplement il y a un amalgame qui a été fait.

      On peut comparer le choix d'un MySQL ou Mongo pour une application en fonction d'un problème, cela est parfaitement censé.

      Là où cela a dérivé je pense, c'est qu'une bonne partie des web apps ont une utilisation tellement basique des DB que virer le SQL ne ferait pas de mal ( sur le papier ).

      Ca me rappele le début de Rails, avec toute sa hype à la con, qui finalement nuit à la techno elle même en lui donnant une réputation de truc juste à la mode tellement certains fanboys aveugles racontent que c'est 'la solution à tout nos problèmes (tm)'.
    • [^] # Re: pitié ...

      Posté par  (site web personnel, Mastodon) . Évalué à 10.

      Le non sens est plutôt de confondre Base de données et base de données relationnelles.

      Par exemple, pour stocker les pages d'un wiki, utiliser postgresql me semble être une hérésie. Ceci étant dit, j'adore PostgreSQL pour sa puissance fonctionnelle ; mais ce n'est pas appliqué à tout type d'application ; tout dépend des besoins, des contraintes.

      Je vais prendre un exemple concret, d'expérience. Au boulot, on gère des bases de données de blob de plusieurs millions d'entrées avec mots-clés associés. On doit tout charger en mémoire sur des applis spécifiques. On utilise des bases Postgresql pour gérer les bases de données "référence" (ie celles qui garantissent la qualité et la cohérence des données de nos clients) parce que c'est lié à notre système d'information et parce qu'on a besoin de gérer des requêtes complexes, des procédures stockées, etc ; mais les serveurs qui manipulent les données en question les chargent via des fichiers SQLite (on les convertit entre temps) parce que d'un point de vue performances au chargement, il n'y a pas photo. Pour tous les outils internes "courants" (bugzilla, wiki, etc) on utilise MySQL parce que ça ne nécessite pas d'administration courante (c'est plus autonome qu'une base PostgreSQL). Et pour la gestion du code source, on utilise CVS qui est aussi une base de données à part entière (et qui est basée sur des fichiers) (notez: CVS est obsolète, je dis pas le contraire, mais ça marche bien:).

      Typiquement pour les outils de gestion de version, si les bases de données relationnelles étaient la poule aux oeufs d'or, on n'aurait plus de systèmes "non SQL".

      C'est comme si on disait : "par pitié, parler de PHP ou Python comme un langage de programmation est un non sens". Ne pas admettre qu'à des besoins différents les meilleures solutions sont différentes, ça oui, c'est un non sens à mon avis.
      • [^] # Re: pitié ...

        Posté par  . Évalué à 3.

        oui, je voulais bien entendu parler des bases de données relationnelles .. merci pr la rectification
        • [^] # Re: pitié ...

          Posté par  (site web personnel) . Évalué à 4.

          Mais personne ne semble confondre MongoDB avec une base de donnée relationelle.
          • [^] # Re: pitié ...

            Posté par  . Évalué à 1.

            apparement si.

            "Elle me semble être particulièrement bien adapté pour le développement web (enfin, si vous visez à devenir le prochain twitter, Cassandra est probablement un meilleur choix). Certains prédisent même qu'elle pourrait prendre la place de MySQL dans ce domaine."
            • [^] # Re: pitié ...

              Posté par  . Évalué à 5.

              La majeure partie des développeurs du dimanche (ce n'est pas une insulte) n'utilise pas la partie relationnelle de MySQL. Ils n'utilisent que la partie base de données et le langage d'interogation qui va avec. Donc n'importe quelle base de données fait l'affaire, si elle est pourvue du nécessaire pour l'interroger.

              Et pour les programmeurs qui ne sont pas du dimanche, c'est souvent la même chose. A titre pro nous utilisons trois applications web (un wiki, un gestionnaire de tâches, et un calendrier/agenda) qui ne tirent aucun parti du fait que la base de données soit relationnelle. Pour preuve, le wiki utilise uniquement le système de fichiers :-) Le gestionnaire de tâches n'a aucune liaison entre les tables, idem pour le calendrier. Les deux derniers pourraient donc utiliser tout aussi bien le système de fichiers, ou une base NoSQL, ou presque n'importe quel stockage (avec un moyen d'interrogation un poil pratique, forcément).
              • [^] # Re: pitié ...

                Posté par  . Évalué à 1.

                Le gestionnaire de tâches n'a aucune liaison entre les tables

                tu sous-entends que mongodb ne permet pas d'avoir des relations entre les documents, ce qui est faux, voir la doc de mongoid par exemple : http://mongoid.org/docs/associations ou mongomapper : http://railstips.org/blog/archives/2009/06/27/mongomapper-th(...)

                Donc même avec des besoins relationnels légers, mongodb répond au besoin :)
                • [^] # Re: pitié ...

                  Posté par  . Évalué à 3.

                  tu sous-entends que mongodb ne permet pas d'avoir des relations entre les documents
                  Non.
                  J'indique que la majeure partie des programmes n'utilise pas cela.
                  • [^] # Re: pitié ...

                    Posté par  . Évalué à 2.

                    Moi, j'ai l'impression que c'est l'inverse. J'ai du mal à voir des applications qui ont des bases de données sans avoir de relations.

                    Rien que sur ton message, il y a une relation évidente (ton message est relié à ton profil). Une autre relation est entre la news et les messages. C'est un exemple, mais cette application est pourtant simple.

                    Envoyé depuis mon lapin.

                    • [^] # Re: pitié ...

                      Posté par  . Évalué à 4.

                      Rien que sur ton message, il y a une relation évidente (ton message est relié à ton profil)
                      Qu'est ce qui prouves que cette "relation évidente" est gérée par la base de données ?
                      Bon d'accord, il suffit d'aller voir le code :-) Pour les 3 exemples hyper courants que j'ai cité, il n'y a _aucune_ liaison gérée par la base de données. Pourtant ce sont des logiciels libres connus et maintenus. Et ça fonctionne.

                      Tu confonds la liaison logique, qui est dans le cerveau du programmeur, et la liaison codée en dur dans la base de données.

                      Si tu as deux tables SQL reliées par une clef, c'est une "vraie" relation.
                      Si tu as deux tables SQL tout court, la relation n'existe que virtuellement dans le programme. Et donc n'importe quel autre base de données sans cette relation fonctionne pareil.
                      • [^] # Re: pitié ...

                        Posté par  . Évalué à 2.

                        L'intégrité des données c'est quand même un des points les plus importants dans un RDBMS, utiliser un RDBMS sans utiliser de contraintes ça me parait vraiment anormal (quoique ... j'ai découvert récemment le script postgresql de drupal et je suis tombé 4 fois).
                        • [^] # Re: pitié ...

                          Posté par  . Évalué à 5.

                          On ne te dit pas que ce n'est pas important, on te dit que presque personne ne l'utilise. Regarde de pourcentage d'applications qui mettent ça en oeuvre. Et tu verras tout de suite que n'importe quelle base de donnée hyper simple ferait tout aussi bien l'affaire.

                          Si tu ne veux pas comprendre que la réalité n'a rien à voir avec les beaux principes, c'est ton affaire :-)
            • [^] # Re: pitié ...

              Posté par  (site web personnel) . Évalué à 6.

              Hummm, tu peux préciser pourquoi tu penses quand je confonds les deux ?

              Quand je relis mes propos, j'ai du mal à voir ce qui cloche. Je vais essayer de reformuler ça différemment.

              L'idée est que la plupart des développeurs web ont besoin de stocker des données et prennent l'option la plus facile, en l'occurrence une base de données relationnelles, MySQL. Maintenant, si d'un coup, stocker ces données dans des fichiers yaml devenait trivialement simple, cela pourrait devenir le choix de beaucoup de développeurs (même si des fichiers yaml et une base de données relationnelles, ça n'est pas vraiment comparable). Il se trouve que je pense la même chose si on remplace "fichiers yaml" par "MongoDB (ou un équivalent)".
            • [^] # Re: pitié ...

              Posté par  . Évalué à 6.

              Je pense que le "prendre la place de MySQL" c'était plus en terme de popularité.
              • [^] # Re: pitié ...

                Posté par  . Évalué à 2.

                mmh j'avais pas compris ça comme ça ..
  • # En test sur unixfr.org, retour d'exp sur Overblog

    Posté par  (site web personnel) . Évalué à 5.

    Je viens de le mettre en test sur la beta de http://unixfr.org/ ... Je vais bien voir ce que ca donne.

    Au boulot on a aussi commencé à évaluer MongoDB pour http://www.over-blog.com, c'etait un peu la seule option NoSQL viable qui correspondait a peu près à nos besoins. Au final on l'a laissé de coté car postgresql est mieux adapté à notre infra ...

    On reconsiderera l'option pour plus tard.
    C'est pas comme si y'avait urgence, la mode NoSQL est encore jeune et le meilleur reste à venir :)
  • # Vous n'avez rien à faire ce weekend ?

    Posté par  . Évalué à 2.

    Vous n'avez rien à faire ce weekend ? Vous pouvez créer une nouvelle base de données NoSql !

    Pouvoir participer au mouvement NoSql dès sa création est une chance incroyable, en plus en seulement deux jours, vous pouvez avoir un moteur qui est digne de se confronter aux autres.

    Bon plus sérieusement, je trouve que ces nouvelles bases de données sont vraiment très légères, en termes de fonctionnalités. Ça remplace avantageusement une bidouille sur les fichiers, mais c'est un peu près tout. Surtout que l'utilisation du javascript pour manipuler les données n'est vraiment pas convainquant.

    Je suis quand même allé voir le code source par curiosité: http://github.com/mongodb/mongo/tree/master/db/

    Bon, il y a quand même du code, mais ça fait plus petit programme que moteur de base de données relationnelle. Ça donne envi de se lancer dans l'aventure quand on voit ça.

    Envoyé depuis mon lapin.

    • [^] # Re: Vous n'avez rien à faire ce weekend ?

      Posté par  (site web personnel) . Évalué à 2.

      > Bon plus sérieusement, je trouve que ces nouvelles bases de données sont vraiment très légères, en termes de fonctionnalités.

      Par curiosité, quelles fonctionnalités attendrais-tu de MongoDB qui n'est pas déjà là ?

      Pour ma part, je crains plutôt l'inverse : que MongoDB (ou les autres bases NoSQL) essayent de tout faire, mais le faire mal.
      • [^] # Re: Vous n'avez rien à faire ce weekend ?

        Posté par  . Évalué à 3.

        En fait, c'est moi qui doit faire erreur. Car j'attends des fonctionnalités de bases de données relationnelles dans des bases de données qui ne le sont pas.

        Envoyé depuis mon lapin.

    • [^] # Re: Vous n'avez rien à faire ce weekend ?

      Posté par  (site web personnel) . Évalué à 1.

      J'ai une super idée !

      On inventerait DBfs opur recycler les povres vieux mysql solitaires :
      1 fichier = BLOB qui possède des attributs permissions droits et tout. On pourrait implémenter des droits qui n'existe pas encore.

      Et on créerai aussi mogoFS tout accès au file system se ferait pour être sûr que ce soit bien long avec un webservice :)

      Développeurs du dimanche ou pro souffrent du même atavisme : la maladie du sentier.
      Les premiers préfèrent prendre les nouveaux sentiers et haïssent les sentiers battus, les deuxièmes préfèrent les sentiers battus et n'aiment pas les nouveaux.

      Les problèmes d'entreprises sont malheureusement eux assez agnostiques des modes :)
  • # le mouvement NoSQL ...

    Posté par  . Évalué à 3.

    ... me fait penser aux mouvements des langages dynamiques avec typage dynamique voir typage faible, qui présentent l'incapacité d'analyse statique comme une qualité !
    Ce mouvement surf sur la frustration qu'on peut ressentir à devoir respecter tout un tas de contraintes pour aboutir à une structure validée, que ce soit un programme correctement typé ou une base de donnée avec des relations valides. C'est un peu, de façon générale, le mouvement noRTFM. On ne veut plus étudier et concevoir, on ne veut plus de contraintes statiques, on veut retarder au maximum le verdict, on veut des outils les plus souples possibles et puis après tout, si on a envie d'y mettre n'importe quoi on a le droit, on s'en rendra compte nous même. Peut-être un jour en production parce que, dans le meilleur des cas, le code plantera et dans le pire il donnera une info erronée parce que 1 + null == 1.
    J'ai testé CouchDB et tenté de l'appliquer à un programme. Constat : c'est plus proche d'un système de fichier spécialisé que d'une base de donnée relationnelle. C'est pratique pour certains cas, je n'en doute pas, mais qu'on arrête de dire que ça va concurrencer des bases relationnelles. Si le résultat c'est que les scripteurs PHP qui subissaient le relationnel abandonnent tout simplement le relationnel au lieu de l'apprendre, ce ne sera pas vraiment un progrès :)

    Ah, pour être tout à fait honnête, il y a un aspect qui m'a beaucoup séduit : la réplication. Je suis fan de décentralisé, donc j'aimerais que les BDD relationnelles proposent des mécanismes de réplications aussi simples que ce que propose CouchDB. Il suffirait probablement que les clefs primaires ne soient plus séquentielles. Savez-vous ce qui existe pour cela ?
    • [^] # Re: le mouvement NoSQL ...

      Posté par  (site web personnel) . Évalué à 5.

      Je suis d'accord que le mouvement NoSQL est très semblable au mouvement vers les langages dynamiques.

      Par contre, tu sembles penser que les langages statiques permettent d'écrire des applications plus fiables. Les études semblent au contraire montrer que le nombre de bugs est proportionnel au nombre de lignes de code et les langages dynamiques permettent généralement d'écrire un même code de manière plus courte. D'autre part, le vrai facteur qui améliore grandement la fiabilité d'un programme est la présence de tests. Les langages dynamiques proposent généralement des bibliothèques de tests bien plus avancées et pratiques à utiliser que celles pour des langages compilés. Mais, au final, peu importe que ce soit un langage statique ou un langage dynamique, un bon développeur écrira toujours du code de meilleure qualité qu'un développeur débutant (mieux testé, et donc plus fiable).

      Tu sembles aussi sous-entendre que les "vrais" développeurs utilisent des langages statiques, alors que les langages dynamiques sont tout juste bons pour les scripteurs PHP du dimanche. C'est faux. De très bons développeurs utilisent des langages dynamiques par choix. Il suffit par exemple de regarder les sites à fort trafic pour croiser de nombreux exemples : facebook (PHP), twitter (Ruby), wikipedia (PHP), etc.
      • [^] # Re: le mouvement NoSQL ...

        Posté par  . Évalué à 2.

        Le typage valide est une condition nécessaire à la fiabilité du code bien qu'elle ne soit pas suffisante, c'est vrai. Une couverture de tests complète est indispensable pour faire la qualité. Seulement, il y a des choses que tu ne pourras pas faire avec des tests, parce que ce serait trop long. Par exemple, hier j'ai voulu recompiler 'gitit', un wiki correctement conçu, avec la nouvelle version d'une librairie SMTP. Cette dernière venait de changer d'interface. Paf, les types avaient changé et les noms de fonctions aussi. Le compilo m'a directement dit que ça ne passerait pas, inutile de continuer. Sans cette analyse statique, il aurait fallu que je relance toute la couverture de test après coup, et franchement non merci ... En plus, je n'ai pas envie d'écrire de façon systématique des tests destinés à mettre en évidence des erreurs qui peuvent être détectées par une analyse statique.
        Sinon, je manipule régulièrement 3 langages : haskell, ruby et scheme. Ces deux derniers sont très proches, certes. De façon générale, j'écris nettement moins de lignes de code en haskell pour faire la même chose. La vérification statique est poussée et les performances sont incomparables avec les deux derniers. Ça me fait bien réfléchir, après 6 ans de ruby et 3 de rails ...
        Enfin, je ne veux pas juger les développeurs, il y a mille contraintes dans les projets qui peuvent pousser à devoir utiliser telle ou telle techno. Mais je ne me gène pas pour juger les langages, et PHP en l'occurrence, est grossier, car il cumule tous les défauts de tous les langages, sans en avoir la moindre qualité :)
        • [^] # Re: le mouvement NoSQL ...

          Posté par  (site web personnel) . Évalué à 3.

          Pour 'gitit', il t'a fallu combien de temps pour le recompiler ? Lancer les tests t'aurait pris combien de temps ?

          De mon expérience, compiler et lancer des tests sur un projet prennent souvent un temps comparable.

          Sinon, concernant le typage statique, je considère que c'est une forme de tests que l'on t'oblige à écrire. Mais je considère que ce sont des tests assez mauvais et quitte à passer du temps à écrire des tests, je préfère en écrire qui soient pertinents. Par contre, le typage statique a un effet de bord très intéressant : les performances.

          Pour le développement d'applications web, les performances sont souvent une considération secondaire. On cherche plutôt la vitesse de développement, et là, les langages dynamiques sont souvent très efficaces. Et le typage statique n'apporte souvent pas grand chose en terme de fiabilité, car une très grande partie des objets manipulés sont de toute façon des chaînes de caractères.
          • [^] # Re: le mouvement NoSQL ...

            Posté par  . Évalué à 1.

            Hoy,

            c'est long à compiler certainement, mais à la fin t'as du code machine, donc la valeur ajoutée de la compilation ne se limite pas à l'analyse statique. Le facteur de gain en vitesse d'exécution entre une implem ruby MRI 1.9 et Haskell GHC 6.10 est de l'ordre de 50 en moyenne ... Je suis prêt à attendre 3 minutes que mon projet compile pour un tel gain. Le gain en mémoire est considérable également. Mon job est de développer et d'héberger des applis en RoR. Quand je vois comme c'est lent et tout ce que ça mange comme mémoire, malgré l'utilisation de toutes les optimisations possibles, je ne trouve pas que ce soit un problème secondaire.

            Le temps requis pour aboutir à du code fonctionnel à 90% est inférieur en ruby qu'en haskell. Mais je pense que le temps pour aboutir à 99% est inférieur en haskell qu'en ruby ;)

            Enfin, un système de types tel que celui de Hindley-Milner (cf journal récent) permet d'exprimer une grande partie de la logique de ton programme avec des types. Peu importe si la représentation sous-jacente est à chaque fois une chaîne de caractères, tu peux définir un type nom, un type prénom et un type numéro de téléphone, et l'analyse validera leur utilisation dans ton programme.
            • [^] # Re: le mouvement NoSQL ...

              Posté par  (site web personnel) . Évalué à 5.

              > Le facteur de gain en vitesse d'exécution entre une implem ruby MRI 1.9 et Haskell GHC 6.10 est de l'ordre de 50 en moyenne ...

              Tu t'appuies sur quoi pour dire ça ? Si ce sont des micro-benchmarks à la shoutout, ça ne veut rien dire (cf http://shootout.alioth.debian.org/flawed-benchmarks.php ).

              > Je suis prêt à attendre 3 minutes que mon projet compile pour un tel gain.

              Moi aussi, mais avant d'en arriver là, il aura fallu coder pendant des dizaines d'heures. Et coder avec des langages dynamiques va généralement bien plus vite qu'avec des langages statiques. Quand je fais du développement web, je préfère la vitesse de développement aux performances.

              > Mon job est de développer et d'héberger des applis en RoR. Quand je vois comme c'est lent et tout ce que ça mange comme mémoire, malgré l'utilisation de toutes les optimisations possibles, je ne trouve pas que ce soit un problème secondaire.

              Je développe également des applications Rails. Certaines d'entre elles font des millions de visites par mois, tournent sur un seul serveur dédié et le goulot d'étranglement n'est jamais Ruby mais la base de données.

              > Mais je pense que le temps pour aboutir à 99% est inférieur en haskell qu'en ruby ;)

              Ouais, c'est connu, les programmes en haskell, ça court les rues. Le seul programme en haskell que je connais, c'est darcs, et il est connu pour deux choses : être le meilleur DVCS sur le papier, et avoir des performances qui varient entre le meilleur et le pire sans que personne ne sache trop pourquoi.
      • [^] # Re: le mouvement NoSQL ...

        Posté par  . Évalué à 3.

        « un bon développeur écrira toujours du code de meilleure qualité qu'un développeur débutant (mieux testé, et donc plus fiable). »

        Petit aparté : un « bon développeur » peut parfaitement être débutant. Un « mauvais développeur » peut aussi être un « développeur senior ». Bien entendu, l'expérience joue pour devenir meilleur, mais honnêtement, un bon développeur, même avec des habitudes de développement à parfaire [1], est souvent clairement bon dès le départ.



        [1] Je pense à des habitudes de présentation de code, d'utilisation d'outils et de tests unitaires pour tester ledit code, etc., bref de choses qu'on apprend soit en cours, soit (plutôt) avec l'expérience.
    • [^] # Re: le mouvement NoSQL ...

      Posté par  . Évalué à 3.

      C'est pratique pour certains cas, je n'en doute pas, mais qu'on arrête de dire que ça va concurrencer des bases relationnelles.

      Ce que tu oublies (et qui a été décris plus tôt), c'est qu'actuellement, beaucoup de programmes ne tiennent pas compte de la partie relationnelle. Ce qui fait que des bases non relationnelles sont effectivement mieux adaptées à ces programmes.

      C'est pour cela qu'on dit que cela va (peut-être) remplacé MySQL, car beaucoup d'applis web n'utilise pas le relationnel. Les bases de données ne sont pas une concurrences des bases de données relationnelles mais des bases de données tout court (ce qui inclus les bases de données relationnelles).

      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

  • # Voici un exemple de site utilisant mongodb 1.4 en production

    Posté par  . Évalué à 2.

    Bonjour à tous,
    Je me suis intéressé assez tôt à mongodb pour sa possibilité de scaler facilement horizontalement...

    Je travaille sur http://solimap.com qui est un site utilisant mongodb 1.4 et Ruby on Rails.

    Bien entendu on aurait pu faire la même chose avec MySQL ou PostgreSQL mais j'ai voulu créer une appli utilisant cette nouvelle base de données noSQL pour pouvoir tester en live.

    Résultat :
    Et bien les perfs sont bonnes, et j'ai presque envie de ne coder qu'avec ce genre de base de données maintenant ... Je trouve qu'il y a beaucoup de souplesse avec ce genre de bases.

Suivre le flux des commentaires

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