Sortie de MongoDB 2.0 RC

Posté par  (site web personnel) . Modéré par Lucas Bonnet. Licence CC By‑SA.
Étiquettes :
19
31
août
2011
Base de données

Moins de dix mois après la sortie de sa dernière version stable, l'entreprise 10gen a sorti la nouvelle mouture de sa base de données : MongoDB 2.0. Cette version ne propose rien de révolutionnaire, mais apporte tout de même un certain nombre de fonctionnalités appréciables. On retrouvera notamment :

  • la journalisation activée par défaut ;
  • l'amélioration de l'efficacité spatiale et temporelle des index ;
  • la gestion plus fine des priorités pour la réplication ;
  • et la datacenter awereness de certaines opérations.

N. D. M. : MongoDB est publiée sous licence AGPL v3.0.

N. D. M. : la version 2.0 de MongoDB n'est encore qu'en release candidate.

Détaillons :

  • MongoDB a été critiquée, dans sa jeunesse, pour son manque de stabilité et la perte des données dûe aux crashs. En effet, afin de gagner en performance, MongoDB stocke les données en RAM et flushe sur disque de façon asynchrone. Lors d'un crash les données non sauvées sur disques sont perdues. Le journaling a donc été développé comme une option permettant de stocker temporairement les données dans un journal en attendant l'écriture en bonne et due forme dans les fichiers de MongoDB. Cette option permet ainsi de ne perdre qu'un minimum de données lors d'un crash pour une perte de performance contrôlée [1]. L'option --journal est désormais activée par défaut (mais peut bien sûr être déactivée).

  • MongoDB permet d'optimiser certaines requêtes (comme la plupart des RDBMS) en utilisant des index. Ces index sont représentés par des B-Trees [2] qui permettent un accès rapide aux données. Le choix des B-Tree face aux tables de hashage (plus courantes) peut s'expliquer par la volonté d'optimiser les requêtes ensemblistes (du type : x in [0..18]).
    La structure de ces index a été améliorée afin de gagner jusqu'à 25 % en espace (des index plus petits permettent d'en stocker davantage en RAM) et en vitesse (nul besoin d'expliquer ce que ça implique !).

  • Afin de mieux satisfaire les utilisateurs en entreprise de MongoDB, 10gen a dévoilé un certain nombre de fonctionnalités dites datacenter aware. Il est désormais possible de tagger les machines afin d'imposer l'écriture des données sur au moins N répliques (ou slaves) ou plus intéressant sur X datacenters (ou Y serveurs portant un tag donné). Cette fonctionnalité permettra aux administrateurs de bases de données de mieux contrôler la réplication de leurs données et notamment de valider certaines écritures importantes.

  • MongoDB utilise un modèle 1-N pour la réplication c'est-à-dire un maître et plusieurs esclaves répliquant les opérations du maître. À tout moment, le maître peut cesser de répondre et les esclaves déclencher une élection d'un nouveau maître. Jusqu'alors deux niveaux de hiérarchie existaient : éligibles et non éligibles. Or, la réalité est souvent plus complexe et on désire hiérarchiser parmi les serveurs éligibles lesquels sont plus susceptibles d'être élus : c'est désormais possible [3].

La voie prise par MongoDB montre que le projet gagne en maturité et se concentre également sur des fonctionnalités d'administration permettant ainsi à des entreprises de l'utiliser plus facilement en production. Pour tester MongoDB, rien de plus simple http://www.mongodb.org/, ou mieux http://www.mongodb.org/downloads.

Aller plus loin

  • # RC

    Posté par  . Évalué à 5.

    Petite précision : il s'agit en fait de la 1ère RC.
    "MongoDB v2.0 has been released as release candidate v2.0rc0. This release candidate is not meant for production." (http://www.mongodb.org/display/DOCS/2.0+Release+Notes)

    • [^] # Re: RC

      Posté par  . Évalué à 3.

      Je dirais même plus : le statut de "RC" devrait figurer dans le titre de la dépêche, sinon l'effet est trompeur.
      Au moment où j'écris ce commentaire, le statut est mentionné dans une note du modérateur en fin de texte.

  • # Release Candidate

    Posté par  . Évalué à 2.

    Attention ce n'est pas encore la version finale pour la prod, qui est toujours la 1.8.3. Sinon pour ceux que ca intéresse je l'utilise sur mon projet libre Nodecast via Ruby on Rails pour le frontal et directement en C++ sur le backend pour des raisons de perf.

  • # ARM?

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

    Je n'ai pas tout suivi sur mongodb, mais est-ce que quelqu'un sait si elle est (enfin?) compilable sous ARM?
    Je me souviens l'avoir écartée (avec tristesse) pour ces raisons...

  • # Dépêche intéressante, mais imprécise

    Posté par  . Évalué à 10.

    Je suis un râleur. J'assume.

    Critique de la dépêche

    Je ne suis pas un spécialiste de MongoDB, mais je l'utilise régulièrement, et la dépêche me semble pour le moins imprécise.
    Tout d'abord, j'aurais ajouté dans la liste principale que les performances ont été améliorées pour plusieurs opérations (map-reduce, journalisation, index, concurrence).

    Ensuite, la dépêche a raison : l'écriture en RAM et la possibilité de perte de données en cas de crash d'une instance unique de MondogDB pendant l'écriture fait effectivement partie des principes de conception de ce SGBD. Par contre, elle ne précise pas que MongoDB propose depuis bien lontemps des remèdes : soit on force le client à attendre que l'écriture soit effective, soit on écrit sur plusieurs instances. La première solution est bien sûr beaucoup plus lente. La documentation officielle rappelle que toute application sérieuse doit utiliser des replica sets et forcer les écritures à se faire sur plusieurs nœuds. On n'est pas obligé d'apprécier ce mode de fonctionnement, mais cette information est essentielle pour comprendre MongoDB.

    • Journalisation
      Il faut rappeler que la journalisation existe dans MongoDB depuis la version 1.8. Le principal changement de la journalisation dans la future v2.0 est son activation par défaut pour les machines 64 bits, mais on y trouvera aussi des améliorations mineures (compression, configuration plus fine).
    • Réplication
      L'écriture sur N répliques est apparue en v1.6, alors que la dépêche laisse entendre que c'est une nouveauté de cette RC. Le texte insinue aussi que les termes "réplica" et "slaves" sont équivalents en MongoDB. Ce n'est pas le cas. Si on utilise la technique master/slave, on ne peut pas écrire sur le slave.
    • Data centers
      La réplication me semble être le domaine où la v2.0 apportera le plus de nouveautés, mais l'une seule est décrite par les release notes comme spécialement destinée aux data centers. AMHA, cette "awareness" n'est qu'un élément mineur de la gestion plus fine de la réplication.

    Critique de MongoDB

    A titre tout à fait personnel, je trouve que la grosse lacune de MongoDB est l'absence de recherche en plein texte. La doc officielle en propose un ersatz peu satisfaisant (construire des listes indexées de mots). Donc quand on a besoin de cette fonctionnalité, il faut utiliser un outil externe, que ce soit Sphinx Search, Elastic Search ou Solr. Ou Xapian si on ne veut pas de serveur pour cela. Mais dans tous les cas, si les données ne sont pas statiques, alors il faut synchroniser le moteur de recherche plein texte avec MongoDB, et c'est un travail long et pénible. C'est frustrant de ne pas pouvoir utiliser les points forts de Mongo, comme sa syntaxe de recherche. Comme de plus on a besoin des attributs pour les recherches (par exemple, texte_contient: "mise en examen" ", date>{timestamp}, type: 3), il faut recopier la plupart des données de Mongo, et donc sa valeur ajoutée par rapport à son complément s'amenuise. Par exemple Elastic Search a pas mal de points communs avec MongoDB, et c'est frustrant d'utiliser simultanément deux outils qui dédoublent autant de fonctionnalités.

    Il y a depuis des années un ticket de MongoDB sur la recherche plein texte. Certains ont dit avoir une implémentation presque fonctionnelle, basée sur Lucene (enfin, sa variante récrite en C++). Mais rien de public, pas d'évolution depuis des années. C'est vraiment ce que j'attendais de la version 2.0 et j'ai été désolé de voir que la branche de développement (v1.9.X) n'y travaillais pas. Dommage.

    • [^] # Re: Dépêche intéressante, mais imprécise

      Posté par  . Évalué à 1.

      Toi qui a l'air de maitriser le sujet, pourrais tu me dire quels sont les principaux concurrents de MongoDB et leurs points forts/faibles ?

      • [^] # Riak ?

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

        Il y a Riak qui est un modèle de base sans master.

        http://wiki.basho.com/

        Une comparaison avec MongoDB

        http://wiki.basho.com/Riak-Compared-to-MongoDB.html

        J'avais monté une petite maquette il y a quelques temps juste pour voir... pas plus d'expérience que cela.

      • [^] # Re: Dépêche intéressante, mais imprécise

        Posté par  . Évalué à 2.

        Je n'ai pas la prétention de dresser un tour d'horizon d'un sujet que je suis loin de maîtriser, je me borne à donner quelques mots-clés et pointeurs.

        MongoDB est une base de donnée orientée document dans le courant NOSQL.
        Le principal concurrent est CouchDB. Il y a une comparaison sur le site de Mongo. Elle est plutôt équilibrée à mon avis, mais je connais beaucoup moins CouchDB. On trouve aussi des tas de comparaisons sur Internet, ainsi que d'autres SGBDD de même type (orienté document) mais moins répandus.

        La notion même de point fort/faible est variable selon le projet et l'observateur. Par exemple, CouchDB est écrit en Erlang et MongoDB en C++. Pour moi qui connaît le C++ mais pas Erlang, un léger avantage va à Mongo. Le fait que CouchDB conserve toutes les anciennes versions des documents peut être utile ou pas suivant l'application. Pour la recherche en texte intégral, CouchDB a une avance indiscutable sur son rival. Sur un autre critère important à mes yeux, lancer une recherche est plus souple et plus facile avec Mongo : tous deux disposent de map/reduce, mais les views de Couch semblent souvent un carcan face à l'API de recherche de Mongo.

        • [^] # Re: Dépêche intéressante, mais imprécise

          Posté par  . Évalué à 1.

          MongoDB apparaît aussi comme beaucoup plus accessible. Notamment, le shell permet de s'y mettre facilement.

          • [^] # Re: Dépêche intéressante, mais imprécise

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

            Oh oui, avec un shell qui change de comportement selon qu'on se connecte à un serveur de config, un mongos, un mongod, un répliqué, etc. Et bien sûr, pas de gestion des erreurs, avec un usage de dialog très somaire. Très abordable, je confirme.

            Mais bon, l'outil a peut-être été amélioré depuis la dernière fois où je l'ai utilisé.

    • [^] # Re: Dépêche intéressante, mais imprécise

      Posté par  . Évalué à 6.

      Étant aussi un peu râleur je me permet de préciser, suggérer, qu'en bon français on dit recherche en texte intégral.

      Tout à fait cordialement.

      • [^] # Re: Dépêche intéressante, mais imprécise

        Posté par  . Évalué à 2.

        Mea culpa. Je n'avais que ce full-text search en tête. Encore une preuve de l'influence pernicieuse de l'anglais sur ma pratique du français.

        Pour poursuivre mon auto-critique :
        s/fait effectivement/font effectivement/
        s/n'y travaillais pas/n'y travaillait pas/

      • [^] # Re: Dépêche intéressante, mais imprécise

        Posté par  . Évalué à 2.

        Étant aussi un peu râleur je me permet de préciser, suggérer, qu'en bon français on dit recherche en texte intégral.

        oui enfin depuis seulement le 20 avril 2007 quand nos instances ont décidé d'appeler ça comme ça ... car avant tout le monde disait recherche plein texte depuis bien longtemps ...

        le petit test de la requête google est un indicateur :

        7 820 000 résultats pour recherche plein texte
        2 110 000 résultats pour recherche en texte intégral

        alors certes c'est la version officielle mais bon on va peut-être se détendre sur les néologismes inventés par nos grands experts bien longtemps après qu'on utilise un terme ...

    • [^] # Re: Dépêche intéressante, mais imprécise

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

      Remarques pertinentes, quelques précisions cependant à propos de la réplication :

      mongodb propose deux techniques : master/slave et replicasets (recommandée).

      Master/slave est très simple : un des serveurs est le maître et permet l'écriture et la lecure, les slaves ne sont que des backups des données, aucune autre action que la réplication ne les atteints.

      En revanche les replicasets assure une élection automatique d'un serveur primaire parmi les membres du replica en cas de crash du primaire actuel. On ne peut qu'écrire sur le primaire mais lire sur tous les serveurs (c'est une option).

      Effectivement ce n'est pas nouveau, ce que je pointais dans la dépêche c'est la possibilité de configurer des priorités pour l'élection du serveur primaire.

      Travaillant avec mongodb quotidiennement c'est une fonctionnalité qui manquait cruellement. C'est en tout cas l'angle pris dans cette dépêche : quelles sont les fonctionnalités les plus attendues de cette nouvelle version.

    • [^] # Re: Dépêche intéressante, mais imprécise

      Posté par  . Évalué à -1.

      Tant qu'à râler, je me joins à toi:

      Tout le monde n'est pas un spécialiste de tous les logiciels open-source. Est-ce que ça serait trop demander de reprendre une saine habitude: donner au moins une phrase explicative de ce qu'est MongoDB au début de la dépêche ?

      C'est indispensable pour permettre à un plus grand nombre de profiter de l'article. Là, c'est l'exemple typique de l'article imperméable.

      • [^] # Re: Dépêche intéressante, mais imprécise

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

        donner au moins une phrase explicative de ce qu'est MongoDB au début de la dépêche ?

        « Base de données : Sortie de MongoDB 2.0 RC »

        « Moins de dix mois après la sortie de sa dernière version stable, l'entreprise 10gen a sorti la nouvelle mouture de sa base de données »

        On pourrait dire que MongoDB est un système de gestion de base de données.

      • [^] # Re: Dépêche intéressante, mais imprécise

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

        MongoDB est une base de données c'est à dire un système (logiciel) permettant de stocker de façon organisée de grandes (ou petites) quantité de données.MongoDB fait partie des bdd qualifiées de NoSQL (Not Only SQL , c'est à dire se différenciant de la famille des bdd SQL qui ont étés majoritaires ces dernière années).
        MongoDB se caractérise notamment par le non respect du caractère ACID que l'on trouve classiquement parmi les bases de données transactionnelles. Pour plus d'informations, je t'invite à consulter :
        Propriétés_ACID
        Base_de_données
        NoSQL
        ou leurs versions anglaises (souvent plus complètes) et à suivre les liens que tu trouveras sur cette page.

Suivre le flux des commentaires

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