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.
# Dépêche intéressante, mais imprécise
Posté par rogo . En réponse à la dépêche Sortie de MongoDB 2.0 RC. É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.
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).
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.
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.