Traductions pour la plateforme Java

Cours MongoDB semaine 1: Introduction

Le but de la première semaine est donner une vue très générale de MongoDB, d'installer les outils nécessaires et d'introduire l'application qui servira à la plupart des exercices.

MongoDB, c'est quoi ?

MongoDB est un dépôt d'objets JSON non-relationnel.

  • Dépôt d'objets JSON: MongoDB stock des documents structurés au format JSON.
  • Non-relationnel: MongoDB ne supporte pas l'algèbre relationnelle (autrement dit SQL)

Bon je ne vais pas m'étendre sur ce qu'est un document JSON ou bien l'algèbre relationnelle. En ce qui concerne JSON, le  cours revient en détail sur ce format, notamment sur les tableaux et les sous-documents. De toutes façons, on comprend très vite qu'il va falloir se séparer de nos vieux raisonnements sur le schéma suivant (Les copies d'écran sont tirées des vidéos du cours, disponibles sur YouTube):

scalabilité de MongoDB

Le schéma d'Andrew Erlichson est evidemment très commercial, il nous montre qu'on a le beurre (une super scalabilité) et l'argent du beurre (presque toutes les fonctionnalités des SGBD) . Mais bon concentrons-nous plutôt sur les enseignements qu'il faut en retirer.

Le principal atout de MongoDB est sa scalabilité horizontale: il est très facile d'ajouter des noeuds supplémentaires, alors que c'est notoirement difficile avec nos bons vieux SGBD. Mais du coup on n'a plus accès aux jointures et aux transactions, parce qu'elles passent très mal à l'échelle si on multiplie les noeuds... Imaginez les performances en cas de transaction ou de jointures entre des collections (grossièrement l'équivalent MongoDB des tables) si elles se trouvent sur des noeuds différents.

Attendez ! Rasseyez-vous tout n'est pas perdu ! Chaque fonctionnalité perdue peut être compensée en ayant une approche différente:

  • Transactions: dans MongoDB on accède  à un document de manière atomique, même si on n'a pas de transaction sur plusieurs documents
  • Jointures: un document peut être structuré pour contenir toutes les infos nécessaires. Donc, ce qui demanderait plusieurs updates en relationnel ne demande plus qu'une modification atomique de document avec MongoDB.

Enfin, il est très naturel pour un développeur d'utiliser les documents stockés par MongoDB puisque ce sont déjà des objets. On a pas le mismatch objet-relationnel qu'on se traine à longueur de journée avec les SGBD.

Architecture de l'application d'exemple

L'application d'exemple est une application de blog basique. Son architecture est illustrée par le schéma suivant:

Architecture de l'application utilisée dans les exercices

Voyons les différents éléments de ce schéma:

  1. mongod est le processus chargé de faire tourner un noeud MongoDB.
  2. mongo est le shell de MongoDB. On en reparlera par la suite, mais il ne fait pas à proprement parler de l'application.
  3. Le driver Java pour MongoDB est ce qui nous permet, en tant que développeur Java, de dialoguer avec le serveur mongod.
  4. Spark est le framework web qui se chargera du routage des URLs. C'est un framework très léger, sans configuration XML.
  5. Freemarker est mieux connu. Il s'agit d'un moteur de templates qui nous servira à générer les pages Web du blog.
  6. Bien sûr, le code de l'application elle-même !

Je ne m'étend pas plus sur cette architecture étant donné que le but du cours est quand même d'apprendre à utiliser MongoDB, mais j'avoue que j'ai trouvé l'association Spark - Freemarker assez intéressante - et à mille lieues des solutions compliquées que l'on utilise souvent dans le monde Java.

Le shell Mongo

On nous montre ensuite comment utiliser le shell Mongo:

Introduction au shell de MongoDB

On lance le shell au moyen de la commande mongo. Evidemment, il faut d'abord avoir lancé un serveur par le biais de mongod.

Par défaut, on est connecté à la base test. On utilise use <nom_base> pour changer de base. A partir de là, la base en cours est connue sous l'alias db.

On voit tout d'abord que les collections n'ont pas de schéma, ce qui veut dire qu'il est tout à fait possible de stocker des objets ayant des propriétés complètement différentes dans la même collection. Ou, de façon plus réaliste, que différentes versions d'objets peuvent coexister dans une collection.

On remarque aussi que lorsque l'on enregistre un document, un identifiant unique de nom _id est généré, et cet identifiant est toujours indexé. Tout document doit disposer d'un identifiant unique. Si celui-ci n'est pas précisé, le système en génère un automatiquement.

Ensuite viennent quelque exemples de requêtes basiques au moyen de la méthode find(). Sans paramètre, elle retourne tous les documents de la collection. On peut aussi passer en paramètre un objet JSON qui décrit tout ou partie des documents que l'on souhaite trouver.

Le driver Java

public class HelloWorldMongoDBStyle {
    public static void main(String[] args) throws UnknownHostException {
        MongoClient client =
                new MongoClient(new ServerAddress("localhost", 27017));

        DB database = client.getDB("course");
        DBCollection collection = database.getCollection("hello");

        DBObject document = collection.findOne();
        System.out.println(document);
    }
}

Ce Hello World à la sauce MongoDB montre les principales étapes pour travailler avec une base.

  1. Obtenir un client en fournissant l'hôte de la base, et éventuellement le port (par défaut 27017). La classe MongoClient est assez intelligente pour gérer un pool interne de connexions et on n'aura qu'une instance par JVM.
  2. Obtenir la base avec laquelle on veut travailler (ici "course")
  3. Obtenir une des collections contenues dans la base (ici "hello")
  4. Travailler sur cette collection. Dans l'exemple, on récupère un document quelconque de la collection en utilisant la méthode findOne(), puis on affiche ce document.

L'application d'exemple: un blog

Il s'agit d'un embryon d'application qui permet:

  • de se logger (notion de user)
  • de créer un billet et de l'associer à des mots-clés (notion de post et de tag)
  • de laisser des commentaires sur un billet (notion de comment)

Si on devait utiliser un modèle relationnel pour stocker tout ça, on obtiendrait quelque chose qui ressemblerait à cela:

Schéma relationnel du blog

Quand on fait du relationnel, on n'a pas trop de questions à se poser: on dispose de règles bien définies pour la modélisation.

Voyons maintenant la version MongoDB des mêmes informations:

Schéma MongoDB du blog

On a seulement deux collections:

  • La collection posts qui regroupe les informations sur les posts, leurs tags et leurs commentaires.
  • La collection authors qui héberge les informations sur les auteurs, c'est-à-dire les utilisateurs autorisés à se connecter au système et à créer des posts.

On voit que c'est le post qui embarque la plupart des données utiles à l'application. D'où la question, comment décider quand embarquer des données dans un document et quand créer une collection séparée ? La réponse est liée à l'utilisation que l'on va faire des données.

Prenons par exemple le cas des tags. On pourrait stocker cette information de deux façons:

  1. Embarquer les tags dans les posts
  2. Créer une collection séparée et faire un lien entre les posts et les tags, de façon assez semblable au modèle relationnel.

Pour déterminer la meilleure option, il faut réfléchir à la manière dont on va accéder aux tags dans l'application. Va-t-on les manipuler le plus souvent en même temps que les posts, ou bien ont-ils des vies vraiment indépendantes ? Dans notre cas, le plus souvent on ne se servira des tags que pour rechercher les posts associés, ou bien afficher les tags d'un post. On peut donc sans souci embarquer les tags dans les posts. Evidemment cela sera un peu pénible si un jour on veut renommer un tag par exemple, mais c'est une opération relativement peu courante.

Attention tout de même quand on détermine la structure des documents: la taille maximale d'un document est 16 Mo. Dans certains cas, assez inhabituels, il faudra donc créer des collections séparées.

Voilà, c'est tout pour la première semaine de cours ! Nous avons abordé quelques notions générales sur la nature de MongoDB, l'outillage fourni et le décalage entre ce modèle et le modèle relationnel. La première semaine inclut aussi un certain nombre de leçons et d'exercices qui permettent de s'assurer que l'environnement nécessaire (Java, Maven, MongoDB, Spark et Freemarker) est bien en place et que l'on comprend bien ce qui se passe, mais comme c'est un peu plus éloigné du sujet je n'en ai pas parlé.

C'était en tous cas assez alléchant, j'attends avec impatience la deuxième semaine !

Commentaires

J’utilise MongoDB en ce

J’utilise MongoDB en ce moment grâce à l’aide d’un tutoriel vidéo sur http://www.alphorm.com/tutoriel/formation-en-ligne-mongodb-administration. Et vu que je suis encore un débutant dans ce domaine, je vais essayer d’assimiler quand même votre cours. Merci pour ce partage.

Merci

Beau travail, merci !

Fongo

Salut,
 
n'hésite pas à utiliser fongo (https://github.com/fakemongo/fongo) pour l'écriture de tes TU :) #autopub :)