Nuxeo and MongoDBUne conférence MongoDB dédiée aux développeurs a récemment eu lieu dans une très belle salle située sur les Champs-Élysées à Paris. Ce fut une excellente occasion de rencontrer de nombreux adeptes de MongoDB, mais également des gens souhaitant découvrir les capacités de NoSQL et MongoDB. Les 9 heures de conférence ont donné beaucoup d'informations à un public très attentif et nombreux tout au long de la journée !

Voici les points à retenir de cette conférence MongoDB à Paris.

WiredTiger


L'une des interventions était centrée sur le moteur de stockage WiredTiger, qui est toujours en option dans MongoDB 3.0, mais qui devrait être présent par défaut dans la version 3.2. Le principal avantage de WiredTiger par rapport au stockage MMAPV1 se trouve au niveau de la stratégie de gestion des éléments concurrents (au niveau des documents), permettant ainsi de meilleures performances lors des opérations d'écriture.

Nous avons récemment réalisé des benchmarks à l'aide de Nuxeo Platform et MongoDB.

Nuxeo MongoDB Benchmarks

Avec ces benchmarks récents, nous avons également réalisé quelques tests pour comparer les moteurs de stockage MMAPv1 et WiredTiger.

Voici les résultats :


  • Performances en lecture similaires.

  • Lors des opérations d'écriture, WiredTiger peut être jusqu'à 2,5 fois plus rapide que MMAPV1 (et 5 fois plus rapide que SQL).


Benchmarking Mass Import

Ops Manager


La plupart des actions de configuration et d'administration de MongoDB se font en ligne de commande. En tant que développeur, je trouve ça très pratique et j'imagine qu'un DevOps serait assez d'accord. Cependant, ça peut vite poser problème lors de la gestion d'un cluster de grande taille.

Il semblerait qu'Ops Manager soit une bonne solution pour disposer d'une interface d'administration Web et éviter de devoir exécuter des centaines de lignes de commande dans 10 fenêtres différentes et dans un ordre bien précis. Cette présentation expliquait bien les avantages d'Ops Manager dans le cadre d'une mise à niveau régulière des nodes d'un cluster.

La même situation se présente chez Nuxeo : on peut faire beaucoup avec nuxeoctl et le shell Nuxeo, mais lorsqu'il faut gérer un cluster, il nous manque une interface Web d'administration centralisée nous permettant de coordonner les différents nodes.

Les principes de conception d'Ops Manager sont simples et efficaces, et nous envisageons donc d'utiliser une architecture similaire pour créer un gestionnaire de Cluster Nuxeo.

Nuxeo & MongoDB


Nous avons fait une courte présentation portant sur les raisons qui nous ont décidé à intégrer MongoDB dans Nuxeo Platform, sur la façon dont nous avons réussi cette intégration et sur les avantages que nous en avons retirés. Les slides sont disponibles en ligne. Nous allons faire une version raccourcie de cette présentation lors d'autres événements MongoDB :

À propos de MongoDB 3.2


Il semblerait que la version 3.2 de MongoDB apportera une multitude de nouvelles fonctionnalités. Voici, selon moi, les points les plus importants :

Validation de documents


Je sais que beaucoup de gens apprécient le côté « sans schéma » de MongoDB, et même si je peux comprendre l'attrait de la liberté, je pense que les opérationnels ne sont pas du même avis.

Le fait que la boîte à outils d'entreprise propose des outils tels que MongoDB Compass, pour le reverse engineering des schémas, prouve qu'il est plus logique d'avoir de vraies définitions de schémas au niveau applicatif, au moins d'un point de vue applicatif. Une fois que vous avez « compris le schéma », il est également logique de pouvoir définir des contraintes au niveau du stockage et on dirait que c'est l'objectif de la validation de documents (Document Validation).

Les répercussions seront minimes pour les utilisateurs de MongoDB via Nuxeo Platform, puisque la couche de base documentaire au-dessus de MongoDB gère déjà la logique de validation qui peut ensuite remonter jusqu'à l'interface utilisateur. Cependant, le point de vue interne Nuxeo DBS peut être intéressant afin de mieux gérer les schémas dans la base de données sans schéma.

In-Memory Storage Engine (moteur de stockage interne)


Avoir un véritable moteur de stockage interne a de grandes chances de délivrer des performances de haut niveau. Cependant, les cas d'utilisation sont limités s'il n'y a pas de durabilité des données. Heureusement, la beauté de la connectivité du moteur de stockage réside dans le fait qu'il est possible d'avoir plusieurs moteurs de stockage différents à l'intérieur du même ensemble de répliques. Cela signifie que le « master » peut utiliser le stockage « interne » pour délivrer des performances à couper le souffle tandis que les autres éléments de l'ensemble de répliques peuvent utiliser WiredTiger pour bénéficier d'une "eventual persistency".

Dans un sens, c'est assez proche de ce que nous faisons avec Redis : nous utilisons le Redis interne pour stocker les caches et les files de traitement tout en disposant de la persistance Redis pour « faire un backup de ce qu'on a en mémoire ».

Connecteurs BI et recherche


Comme on peut déjà le voir dans la documentation de développement, MongoDB a intégré un nouveau $lookup. C'est une sorte de liaison simple entre des collections et ça sera probablement la pierre angulaire du connecteur BI destiné à traduire le SQL dans les requêtes MongoDB et le framework d'agrégation.

Du côté de Nuxeo, puisque toutes les données d'une base documentaire sont accessibles dans une collection unique, nous n'avons pas vraiment besoin de cette liaison. Mais :


  • Avoir un accès SQL aux données Nuxeo stockées dans MongoDB paraît sensé.

  • Avoir des liaisons simples entre les collections permettrait à Nuxeo Platform de stocker les données d'audit dans MongoDB tout en gardant la possibilité d'exécuter des analyses basées sur la base documentaire et les données d'audit.


En résumé, il semblerait que nous allons très vite devoir tester MongoDB 3.2 avec Nuxeo Platform !