MongoDB

Bonjour à tous,

J'ai commencé (il y a 1 mois, 3 semaines) la rédaction d'un tutoriel dont l'intitulé est MongoDB.

J'aimerais obtenir un maximum de retour sur celui-ci, sur le fond ainsi que sur la forme, afin de proposer en validation un texte de qualité.

Si vous êtes intéressé, cliquez ci-dessous

Hello,

Enfin ! J'aurai mis le temps, mais la première partie est terminée. J'attends quelques retours pour le passer en validation.

Pour info, voici les sept parties prévues pour l'instant. En sachant qu'il y a de grandes chances pour que je réorganise tout ça, mais le contenu même devrait pas trop changer (je couvre déjà pas mal de choses).

• Prise en main
• Index, performance et administration
• Aggregation
• Schema design
• Replication
• Fragmentation
• Introduction à Map Reduce

Je voulais terminer cette première partie qui traîne en attente de relecture depuis le mois d'avril, mais le reste attendra un peu (je voudrais notamment faire avancer, voire terminer la ZEP-24).

Merci d'avance pour votre aide

Introduction

Idéalement en javascript mais n'importe quel langage

qui utilise le javascript

JavaScript

Prise en main/Introduction

fait partie de ce qu'on appelle "NoSQL"

Guillemets français ?

Prise en main/NoSQL/Introduction

Dès les années 1970, et jusqu'à très récemment, les bases de données relationnelles (MySQL, Oracle, PostgreSQL, …) utilisant le langage SQL étaient presque

L'imparfait ne va pas avec le "dès". Plutôt : "Des années 1970 jusqu'à très récemment".

avec l'évolution de l'informatique et l'accroissement et l'évolution des données

Un peu trop de "et". Plutôt : "avec l'évolution de l'informatique ainsi que l'accroissement et l'évolution des données".

Prise en main/NoSQL/Les causes

Big Data, Big Users, "The internet of things"

Guillemets français ? Je ne le dirai plus par la suite, ma la suggestion vaut pour toutes les fois où tu utilises des guillemets non-français.

Il y a au moins un "s" à la fin de "Appelé", non ? Peut-être aussi un "e". Mais ça rejoint un peu la remarque suivante.

les big data sont des données tellement massives

Je croyais qu'on parlait du Big Data. Le Big Data, c'est le fait d'avoir beaucoup de données ou ce sont les données elles-mêmes ?

Du coup, se pose la question des majuscules.

entre les relations entre les membres, les publications

Un peu répétitif. Plutôt : "avec les relations".

données d'un réseau social peut très vite exploser.

Plutôt un point-virugle à la fin, non ? Même remarque pour la fin du deuxième point de la liste.

les capteurs divers (astronomiques, météorologiques, …)

Plutôt : "météorologiques…", ou : "météorologiques, etc.".

quelques centaines ou dizaines d'utilisateurs simultanés

Je dirais plutôt : "dizaines voire centaines".

utilisation massive et croissante d'internet

"Internet" ?

il n'est pas rare d'avoir des applications sur lesquels

lesquelles

un grand nombre d'objets est connecté à internet

Majuscule ?

systèmes domotiques pour les maisons, …

par qui il est utilisé, …

Même remarque qu'au-dessus, sur les "…".

les bases de données relationnelles ne sont pas très adapté à ce mode d'évolution

adaptées

Il va de soi que c'est intéressant et très explicite, mais serait-il simple et court d'expliquer un peu plus en détail les limitations des bases SQL ? Tu donnes des situations où ces limitations sont recontrées, mais tu n'expliques pas leur cause et leur nature. Enfin, j'imagine que ça devient plus complexe et plus laborieux à expliquer. Voire que ça mériterait un tutoriel propre. Comme tu veux, mais si tu ne le fais pas, j'ajouterais à ta place un mot au début de l'extrait pour dire que c'est trop long et pas le sujet, en fournissant si possible une source à ce propos.

Prise en main/NoSQL/Ainsi naquit NoSQL

Proposer une architecture qu'il est facile de faire évoluer horizontalement

Il existe un terme anglais pour "évoluer horizontalement" ? Est-ce la scalabilité ?

même si un des serveurs plante : les autres peuvent prendre le relais.

Ca implique de stocker toutes les données sur tous les serveurs, non ? Ou peut-être plutôt d'utiliser des méthodes telles que dans les systèmes RAID ?

format de données qui puisse facilement évoluer dans le temps, et qui permettent

permette

dont la structure n'est pas définie a priori

"à priori" ou "a priori".

Les différents modèles et technologies ayant émergés sont aujourd'hui regroupées

regroupés

qu'on distingue selon leur manière de stocker les documents

Il ne me semble pas que tu aies expliqué ce qu'est un document.

• les bases de données clé-valeur ;
• les bases de données orientées document ;
• les bases de données orientées colonnes ;
• les bases de données orientées graphes.

Les "s" à la fin, c'est aléatoire ? Tu en as mis un à "document" dans le sous-titre du tutoriel. Si tu changes ici, il y a d'autres endroits à modifier, que je n'ai pas relevés.

Représentation des données dans une base de données relationnelles

relationnelle

Un autre problème que j'ai rencontré avec de telles bases, c'est la représentation des listes.

Les tables sont normalisées de manière à ce qu'on ait le moins de répétition de données possible. Le but

Je mettrais plutôt une virgule.

agnostique

J'ai cherché la définition, et je suis tombé sur : " Qui pense que l'absolu est inaccessible, et qui est donc sceptique vis-à-vis de la religion et de la métaphysique.". J'imagine que ce n'est sous ce sens-là qu'il apparaît dans ton texte.

un certain type de données (nombre, chaine de caractère

chaîne de caractères

nombre, chaine de caractère, date, …

Les …

le contenu même de l'article (date, titre, texte, …)

Idem.

Dans une base de données relationnelles, toutes les données seraient séparées

relationnelle

pour référencer les catégories et les lier aux article

articles

Récupérer toutes les informations nécessaire

nécessaires

ne soit lié qu'à une seule catégorie, référencée dans la table article

Je formaterais plutôt comme ça : article. Quoique…

Les valeurs stockées peuvent être n'importe quoi (un nombre, une chaine de caractères, un objet complexe,…) Les

chaîne

Les …

Un point à la fin.

Les valeurs stockées peuvent être n'importe quoi

Qu'en est-il des clés ? Uniquement des chaînes, comme en JSON ?

Les requêtes sur la BDD

Je préfère "base" que "BDD". Mais c'est très personnel.

Les requêtes sur la BDD ne peuvent se faire que via les clés

via

développé initialement par LinkedIn.

Un point-virugle à la fin plutôt ? Même remarque pour la ligne suivante.

soit en utilisant des attribut du document

attributs

Les document sont semi-structuré

semi-structurés

Les performances sont moins bonne qu'avec le modèle clé-valeur

bonnes

directement à partir d'un navigateur internet

Majuscule ?

Bases de données orientées document

La notion de document n'est pas très claire. Tu devrais en donner un exemple. Je ne suis pas un expert, mais le suivant devrait convenir, non ?

1
2
3
4
5
6
7

{
  "key": "value",
  "keykey": 2
  "keykeykey": {
    "key": [5, 6, 7]
  }
}

Les données sont stockées dans des tables sous forme de colonnes

Ce n'est pas très clair.

optimisé pour faire des requêtes sur de larges sets de données

"ensembles" plutôt que "sets" ?

BigTable est un logiciel propriétaire.

basé sur BigTable et open source

;

c'est à dire où les éléments sont connectés entre eux

c'est-à-dire

sous forme de noeuds, d'arrêtes

liés entre eux par les arrêtes

les propriétés des noeuds et arrêtes

Chaque arrête peut lier de 2 à X noeuds

arêtes

Les attributs permettent de définir les propriétés des noeuds et arrêtes.

Ce sont des étiquettes en fait, non ?

Je ne peux que tu féliciter grandement pour ton travail. J'avais beaucoup aimé ton tutoriel sur MySQL, et je suis bien parti pour apprécier celui-ci.

On relève principalement quatre grandes tendances qui expliquent ce besoin de bases de données qui n'obéissent pas au modèle relationnel : Big Data, Big Users, "The internet of things", et le Cloud Computing.

Tant de buzz words dans une seule phrase <3.

De ce que j'en ai lu, en tout cas, le tuto est sympa. J'essaierai de faire une lecture plus approfondie dans la semaine, le sujet m'intéresse !

Wouw ! Ca c'est du retour ! Merci Vayel !

Normalement, tout ce qui est orthographe, grammaire et formulation, j'ai corrigé selon tes suggestions (ou quasi pour certaines formulations).

les big data sont des données tellement massives

Je croyais qu'on parlait du Big Data. Le Big Data, c'est le fait d'avoir beaucoup de données ou ce sont les données elles-mêmes ?

J'ai déjà vu les deux. Pour moi on parle du concept Big Data, ou de big data dans le sens littéral de "la blinde de données".

Plutôt un point-virugle à la fin, non ? Même remarque pour la fin du deuxième point de la liste.

Pour les liste, sauf quand c'est juste pour citer une suite de mots ou de concepts, je suis plutôt adepte d'avoir une phrase complète par puce (avec majuscule au début et point à la fin donc). J'ai reformulé à certains endroit la phrase qui introduit la liste pour ne pas terminer celle-ci par « : » (t'as vu, je m'applique ) par contre, pour rester cohérente.

Il va de soi que c'est intéressant et très explicite, mais serait-il simple et court d'expliquer un peu plus en détail les limitations des bases SQL ? Tu donnes des situations où ces limitations sont recontrées, mais tu n'expliques pas leur cause et leur nature. Enfin, j'imagine que ça devient plus complexe et plus laborieux à expliquer. Voire que ça mériterait un tutoriel propre. Comme tu veux, mais si tu ne le fais pas, j'ajouterais à ta place un mot au début de l'extrait pour dire que c'est trop long et pas le sujet, en fournissant si possible une source à ce propos.

Effectivement, c'était sans doute pas assez développé en ce qui concerne les limitations des bases relationnelles. J'ai étoffé cette partie, j'espère que c'est mieux.

Il existe un terme anglais pour "évoluer horizontalement" ? Est-ce la scalabilité ?

En anglais on parle de « horizontal scaling/scalability » (on ne m'arrête plus !). Je ne pense pas que « scalabilité » existe en français donc j'utilise « évolutivité » faute de mieux.

EDIT : après rapide recherche, ce mot est visiblement employé un peu partout. Pas sûr qu'il soit dans le dico mais vu que c'est plus adapté que « évolutivité », je changerai sans doute

même si un des serveurs plante : les autres peuvent prendre le relais.

Ca implique de stocker toutes les données sur tous les serveurs, non ? Ou peut-être plutôt d'utiliser des méthodes telles que dans les systèmes RAID ?

J'ai séparé le fait de distribuer les données sur plusieurs serveurs du fait de répliquer les données sur plusieurs serveurs. Ca devrait être plus clair.

agnostique

J'ai cherché la définition, et je suis tombé sur : " Qui pense que l'absolu est inaccessible, et qui est donc sceptique vis-à-vis de la religion et de la métaphysique.". J'imagine que ce n'est sous ce sens-là qu'il apparaît dans ton texte.

Non, c'est dans le sens informatique du terme : les données d'un base relationnelle se veulent « application-agnostique », dont ne font aucune hypothèse sur la ou les application(s) qui utiliseront les données et donc pourront s'adapter à n'importe quelle application. Ou plutôt, c'est à l'application de s'adapter au format des données.

Je pensais que c'était un terme plutôt connu, je dois préciser dans le cours ? Si oui, genre note de bas de page ou vraiment dans le texte ?

ne soit lié qu'à une seule catégorie, référencée dans la table article

Je formaterais plutôt comme ça : article. Quoique…

J'ai un gros souci de cohérence au niveau de mes formats. Des fois je mets italique, des fois du code. Et dans ma tête y a vraiment une différence : italique c'est plutôt le concept « article », code c'est vraiment la collection ou l'attribut (au sens mongo du terme) « article ». Mais finalement, dans le texte la différence est pas aussi nette et du coup je mets parfois l'un parfois l'autre… Faudrait que je choisisse une fois pour toute.

Les valeurs stockées peuvent être n'importe quoi

Qu'en est-il des clés ? Uniquement des chaînes, comme en JSON ?

Bonne question. A priori ce sont des chaines de caractères mais il est fort possible que certains SGBD utilisent/autorisent autre chose. J'avoue que je me suis pas penché sur la question, je ferai une petite recherche.

La notion de document n'est pas très claire. Tu devrais en donner un exemple. Je ne suis pas un expert, mais le suivant devrait convenir, non ?

En effet, j'ai rajouté un exemple

Les données sont stockées dans des tables sous forme de colonnes

Ce n'est pas très clair.

Oui, je vais reformuler et étoffer. J'avoue, j'arrivais à la fin du chapitre, et c'est pas mon chapitre préféré .

Les attributs permettent de définir les propriétés des noeuds et arrêtes.

Ce sont des étiquettes en fait, non ?

C'est le terme mathématique ? Dans ma tête c'est des attributs quoi, mais si « étiquette » est le terme exacte, ça vaut la peine de le mentionner.

Merci Et encore merci pour tes moultes corrections (quand je pense que y a que le premier chapitre…) !

Tant de buzz words dans une seule phrase <3.

Super combo de la mort ! C'est que c'est addictif ces p'tites choses

Je pensais que c'était un terme plutôt connu, je dois préciser dans le cours ? Si oui, genre note de bas de page ou vraiment dans le texte ?

Une note fera l'affaire.

C'est le terme mathématique ? Dans ma tête c'est des attributs quoi, mais si « étiquette » est le terme exacte, ça vaut la peine de le mentionner.

C'est le terme qu'on utilise en théorie des graphes/arbres.

J'avais lu le tutoriel de ThunderSeb, mais visiblement tu es allé beaucoup plus loin. J'ai plus qu'à me pencher sur le sujet du coup !

Sachant qu'on me demande de faire des formations sur MongoDB mais que je ne connais rien au côté administration (réplication, sharding, etc.), tu as prévu d'ajouter des contenus là-dessus ou tu te limites au côté développeur ?

Ça m'apprendra à lire en diagonale

Merci <3

Ah bah tiens. Je m'étais récemment un peu intéressé à MongoDB et voilà qu'un tuto se profile à l'horizon !

Merci, chef !

Présentation de MongoDB/Introduction

RAS.

Présentation de MongoDB/Fonctionnalités principales

sous forme de documents, au format JSON

JSON ?

certaines de ces propriétés étant elle-mêmes

elles-mêmes

On peut stocker directement des documents complexes dans Mongo.

Je le placerais après le premier exemple, juste avant le second.

"b" : "Texte"

Broutille : le second exemple est en anglais.

Dans MongoDB, un document est le pendant d'un objet.

Et une collection, késako ?

c'est-à-dire que les objets stockés n'ont pas une structure fixée et définie à l'avance

"c'est-à-dire que les objets stockés n'ont pas de structure fixe et définie à l'avance" ?

on peut en entretenir plusieurs copies

Question me passant par la tête : peut-on versionner ?

en créant facilement un ensemble de fragments

Je détaillerais un chouïa le terme "fragments" : on constitue une partition des données (au sens mathématique du terme), c'est ça ? En formulant peu ou prou comme ça : "un ensemble de fragments (en anglais, "shards"), c'est-à-dire un ensemble de…".

Présentation de MongoDB/Fonctionnalités absentes ou restreintes

pas de schéma fixe, objets complexes

Il me semble qu'il manque un truc avec "objets complexes". Par exemple : "objets complexes facilement représentables".

Par exemples, les informations sur un livre

"exemple" ?

Si plusieurs collections sont nécessaire pour récupérer

nécessaires

Je l'ai signalé plus haut, mais tu n'as pas défini ce qu'était une collection.

il faudra faire autant de requête qu'il y a de collections

requêtes

Dans une base de données relationnelles, il est possible de regrouper

relationnelle

Ce qui signifie que toutes ces opérations seront exécutées en une fois, ou pas du tout

Plutôt : "Ce qui signifie que toutes ces opérations seront toutes exécutées en une fois, ou pas du tout".

Les étapes intermédiaires entre chaque opération d'une transaction ne seront jamais visible

visibles

une transaction constituée de 3 opérations est exécutée

trois

effectuée ?

Les pièces d'or (po) de Mjolnir sont diminué de 30 po

Plutôt "La bourse de Mjolnir est allégée de 30 pièces d'or (po)".

Ou alors : diminuées

Les étapes intermédiaire n'existent pas

intermédiaires

Si votre petite soeur éteint la console en plaine transaction

J'ai rien vu.

et ne lui ai donné son marteau

ait

Gérer les éléments qui nécessite une transaction avec un SGBD relationnel

nécessitent

Une transaction doit être une opération atomique, donc indivisible.

MongoDB n'a pas de transaction à proprement parler, par contre la modification d'un document est une opération atomique.

Pour chercher la petite bête (c'est pas marrant, pour l'instant tout est bien :P), je dirais que les deux phrases ne se suivent pas correctement.

Dans la première, tu dis qu'une transaction doit être exécutée entièrement ou pas du tout et qu'une transaction doit être atomique.

Dans la seconde phrase, tu dis qu'il n'y a pas de transactions avec Mongo, mais que la modification d'un document est une opération atomique. Et tu en déduis que modifier un document est une sorte de transaction : tout ou rien.

Pour corriger (ou pas, c'est pas très important), je dirais dans la première phrase que ce sont les opérations atomiques qui sont "tout ou rien", opérations atomiques dont une transaction est un cas particulier. Or, dans Mongo, il n'y a pas de transaction, mais bien des opérations atomiques, qui seront alors effectuées entièrement ou pas du tout.

Pour résumer ce que, je pense, tu dis :

• SQL : transaction = "tout ou rien" et transaction = "atomique"
• Mongo : modif doc = "atomique" donc modif doc = "tout ou rien"

Et ce que, je pense, tu devrais dire :

• SQL : atomique = "tout ou rien" et transaction = "atomique"
• Mongo : modif doc = "atomique" donc modif doc = "tout ou rien"

Quel que soit le nombre d'attributs modifié, lorsque l'on enregistre

"modifié" convient, mais je mettrais tout de même un "s".

que tous les changements seront effectués, ou aucun

Plutôt : "que tous les changements seront effectués, ou qu'aucun ne le sera".

d'un état valide à un autre état valide, sans étape intermédiaire

Je préciserais : "d'un état valide à un autre état valide, sans étape intermédiaire dans laquelle les données seraient invalides".

Cependant, dans certaines configuration, MongoDB peut être cohérente

configurations

MongoDB peut être cohérente au final

"seulement à la fin" plutôt que "au final" ?

où des données qui n'existent plus sont visible

visibles

qu'on autorise les requêtes de lecture à lire les serveurs secondaires

C'est un peu bizarre de dire qu'une requête lit. Plutôt "à se faire sur les serveurs secondaires" ?

plutôt que de les diriger tous vers le serveur primaire

toutes

Au passage, tu n'as pas introduit les notions de "secondaire" et "primaire" dans le premier extrait.

tous les documents d'une collection pour leur ajouter un champs

champ

il est possible que cette modification soit perdue

Pourrais-tu expliciter ce que tu entends par "perdue" ? Littéralement perdue, ou écrasée par l'ajout du champ ?

Les opérations qui n'affectent qu'un seul document sont de facto isolée dans MongoDB

de facto

isolées

Chaque modification des données est d'abord enregistrées en mémoire

enregistrée

Toutes les 100 millisecondes, elles sont ajoutées au journal

C'est le même principe que ext4 ?

J'imagine qu'il est plus rapide d'écrire dans le journal que dans la base (techniquement parlant, mais aussi parce que, à cause de l'isolation, l'écriture dans la base peut ne pas commencer immédiatement. Du coup, comment est gérée l'isolation par le journal ?) ? Que se passe-t-il si écrire dans le journal prend plus de 100ms ? Par exemple (temps en ms) :

• t = 0 : demande d'opération
• t = 0 : écriture dans journal
• t = 120 : crash
• t = 140 : fin de l'écriture dans le journal. Ca n'a pas lieu, à cause de crash, mais c'est pour rendre compte de la durée d'écriture dans le journal.

Ici, la dernière opération a été demandée 120ms avant le crash, mais ne pourra être reprise au redémarrage.

Ce n'est peut-être pas le sujet, mais un exemple serait le bienvenu.

Présentation de MongoDB/Modèle client - serveur

de communiquer avec le serveur, d'envoyer des requête à celui-ci

requêtes

Lorsque l'on installe "MongoDB"

Tu as mis des guillemets pour dire qu'on n'installe pas vraiment MongoDB, mais un ensemble d'outils. Mais, du coup, que désigne le terme "MongoDB" ?

mongod : le serveur

mongod ? Même remarque pour les autres.

Je me suis toujours demandé : pourquoi ce "d" ?

et d'autres logiciel clients utilitaires

logiciels

permettant par exemple de faire des backup

backups ? Ou alors : sauvegardes.

Si vous êtes dans ce cas, référez vous à la documentation

référez-vous

Présentation de MongoDB/Installation et démarrage

Pour des instructions détaillées sur l'installation de mongoDB

MongoDB

Si vous ne pouvez pas (ou voulez pas) utiliser Homebrew

Plutôt : "(ou ne voulez pas)"

Même remarque pour Windows

Si vous avez utilisé un gestionnaire de paquets, vérifiez où mongoDB a été installé

MongoDB

et ouvrer le fichier mongod.conf

ouvrez

Nous allons maintenant démarrer le serveur

Je parlerais de l'option --dbpath, qui me semble intéressante.

Présentation de MongoDB/Présentation du shell Mongo

Pour les instructions, je mettrais dans la balise code un aperçu du shell :

1
2
3
4

> var x = 3
> 3+2
5
>

Tu n'as pas dit comment quitter le shell.

Ni comment éteindre le serveur.

D'ailleurs, pour insister sur la dépendance du client au serveur, tu pourrais commencer par faire le lecteur démarrer le client, recevoir une erreur de connexion et lui expliquer qu'il faut un serveur de démarré pour que ça fonctionne.

Je n'ai pas relevé les guillemets anglais, j'ignore ce que tu souhaites en faire.

Je n'ai pas relevé non plus les "blabla, …". J'ignore si tu souhaites les remplacer par "blabla…".

Format des données

Pas d'introduction ?

JSON

Le format JSON (JavaScript Notation Object)

JSNO ?

est un format facile à lire

Peut-être pourrais-tu préciser "format de représentation de données", ou un truc du genre ?

De nombreuses API délivrent leurs données sous format JSON par exemple

On a un peu l'impression que le "par exemple" porte sur le "sous format JSON".

et les deux documents ne doivent pas avoir la même structure

Peut-être pourrais-tu rajouter "nécessairement" : "et les deux documents ne doivent pas nécessairement avoir la même structure" ?

Ce sont des données semi-structurées.

Je vois ce que sont des données structurées (table SQL), ce que sont des données semi-structurées (objet JSON), mais pas ce que pourraient être des données non-structurées. Le "semi-structuré" vient du fait qu'on impose le format clé-valeur ?

elle doit être entourée de guillemets

Ca marche les apostrophes ?

un array : donc des tableaux de valeurs

Pourquoi ce "donc" ?

La clé "phones" est composé d'une liste (array) de numéros de téléphone comme valeur

composée

Mais ce terme ne me semble pas très adapté. Peut-on dire qu'une clé est composée d'une valeur ? Plutôt "associée à une valeur", non ?

Quant à l'adresse

Pourquoi ne formates-tu par l'adresse comme ça ?

1
2
3
4
5
6
7

"address" : {    //un objet imbriqué
    "streetname" : "Avenue de la Couronne",
    "streetnumber" : "4",
    "zipcode" : "75040",
    "city ": "Paris",
    "country" : "France"
}

Notez que les array peuvent contenir des objets.

C'est bête, mais vu que tu as parlé avant d'objets imbriqués, on ne sait pas trop si tu désignes bien {} avec le terme "objet". Une solution consisterait à être plus général : "Notez que les array peuvent contenir n'importe quels types de valeurs.".

Par ailleurs, il est possible d'imbriquer des objets sur autant de niveaux que l'on veut.

Les arrays aussi. En fait, je donnerais un exemple un peu loufoque d'objets et tableaux imbriqués, et de tableaux contenant des éléments de tous types. En précisant qu'en pratique, on a rarement un tableau avec des éléments de types différents.

BSON

Le BSON (contraction de Binary et JSON) est une représentation binaire du JSON

Comme tu ne le dis pas après, je pose la question à ce niveau : c'est quoi une représentation binaire ? Tout est représenté en binaire dans un PC, non ?

Imaginons que l'on a l'objet JSON suivant

Dédier une ligne par clé rendrait tout ça plus clair. Là, j'ai mis un peu de temps avant de trouver le champ "x" dont tu parles après.

Il est donc possible, sur base de la taille, de passer directement d'un champ à l'autre, sans devoir parcourir toute la valeur.

Si "x" avait été dans l'objet imbriqué, ça aurait fait quoi ?

Je ne vois pas trop comment il fait en pratique.

Toujours aussi plaisant !

Opération du CRUD

Reprenez votre client. Au démarrage

Peut-être préciser qu'il faut bien avoir le serveur démarré ?

deux informations : la version de mongoDB utilisée

Pour être exact, c'est la version du client qui est fournie.

Nous voilà donc dans une base de données nommée crud.

Ca va peut-être un peu vite. Le débutant se demandera probablement : "mais comment je crée ma base crud avant de l'utiliser ?".

Création et sauvegarde d'un document

Petit rappel : une base de données est donc composée

Le "donc" me semble de trop.

Et voici la commande à utiliser pour enregister Plop dans la collections

Comment on crée la collection avant de la remplir ?

On travaille sur un objet db ("database"), qui représente en fait la base de données courante, dans notre cas crud.

Je viens de comprendre qu'en fait, toutes les commandes étaient du JS. Peut-être devrais-tu le dire dans "Présentation du shell Mongo" ? Insister sur le fait que le shell nous fournit une API JS pour commander le serveur, et non pas juste la possibilité de faire des boucles et autres joyeusetés.

{ "_id" : ObjectId("557c64a85aa209c3b5c4c65d"), "name" : "Plop" }

Le lecteur risque de se demander ce qu'est ce champ _id qu'il n'a pas spécifié.

db.character.findOne()

Résultat ? Même si c'est le même que précédemment…

Mais, du coup, il pourrait être intéressant d'ajouter un deuxième document avant de faire les exemples. Et pour bien faire comprendre au lecteur qu'il fait du JS, tu pourrais procéder ainsi :

1
2
3

> var doc = {...}
> db.character.insert(doc)
WriteResult({ "nInserted" : 1 })

Une question que l'on va se poser c'est : quel document affiche findOne quand il y en a plusieurs ?

ensuite seulement sélectionner celle-ci

Je ne comprends pas trop le "seulement".

La commande use nom_db

C'est du JS ça ?

*Démonstration*

Pour la suite de la démo, il me semble préférable de ne pas séparer commande et réponse du shell. Par exemple :

1
2

> use superbase   
switched to db superbase

Aucune trace de la base de données superbase : elle n'existe pas encore ! Par contre, la base de données crud existe bel et bien : elle a été créée automatiquement lorsque nous avons enregistré Plop.

Et local, c'est quoi ?

Il faut donc être prudent avec ce que l'on insère.

Tu pourrais expliquer en quoi c'est un problème d'avoir deux champs de même clé avec des types de valeur différents.

Identifiant

Il s'agit d'un identifiant unique, ou clé primaire, pour le document.

Unique dans la collection ou dans la base ou dans toutes les bases ?

s'il n'est pas précisé à la création, il est créé automatiquement.

Et si je précise un identifiant existant ? Il va me dire "unique key error" ?

"Presque", car ce n'est précis qu'à la seconde.

Et aussi parce qu'il n'y a pas qu'un timestamp dans un ObjectId, non ? A moins qu'il n'apparaisse avant les autres informations et donc détermine souvent la position du document dans l'ordre alphabétique ?

Le cas échéant, tu pourrais préciser : "Un ObjectId est composé de 4 éléments, concaténés dans cet ordre", ou un truc du genre.

Sélection de documents

je peux donner un document en paramètre à find() ou findOne(), qui ne sélectionneront alors que les documents qui correspondent à celui passé en paramètre.

On pourrait penser qu'il ne sélectionnera que ceux égaux au document passé en paramètre, alors qu'en fait il travaille sur les champs. Par exemple, tu n'as pas de document {name : "Wolfy"}, mais db.character.find({name : "Wolfy"}) te retourne un résultat.

D'ailleurs, est-ce vraiment un document qui est passé en paramètre de find ?

Ce qui donne :

Il est un peu dommage d'avoir le même résultat pour db.character.find({name : "Wolfy"}), db.character.findOne({name : "Wolfy"}) et db.character.find({name : "Wolfy", type : "Loup-garou"}). Tu pourrais compléter la collection, avec des Wolfy non loup-garous et des loup-garous ne s'appelant pas Wolfy.

Lorsque MongoDB enregistre des documents, les enregistrements sont contigus sur le disque

Pourrais-tu préciser ? Si ma collection fait 7G, j'aurai 7G de données contiguës sur le disque ? Le cas échéant, ce sont les enregistrements d'une même base qui sont contigus ou seulement d'une même collection ?

Suppression de documents

Tu ne respectes pas l'ordre "CRUD" ?

si on ne lui passe pas de requête en paramètre, remove ne fonctionnera pas sans requête

"document" plutôt que "requête", non ?

mais il est également possible de préciser qu'on ne veut supprimer qu'un seul document

Ce sera le premier dans l'ordre naturel ?

Modification de documents

Plop possède maintenant un attribut type.

Je placerais cette phrase avant le bloc information. Là, elle fait un peu isolée.

correspondant à la requête, il va insérer le document update dans la collection

Ca fait un peu bizarre, parce que tu utilises update pour désigner la méthode et l'argument. On s'y perd un peu.

Par exemple, le code suivant va simplement créer le personnage Hermione.

Vu que tu l'as déjà fait plus haut, c'est un peu perturbant.

Petit rappel : le shell est un interpréteur Javascript. On peut donc manipuler les objets avec du simple code Javascript !

Peut-être le mettre après le bloc de code suivant ?

D'ailleurs, j'organiserais plutôt le code comme ça :

1
2
3
4
5

> hermy.maxLife = 60
> db.character.save(hermy)
WriteResult({ "nMatched" : 1, "nUpserted" : 0, "nModified" : 1 })
> db.character.find()
...

J'ai posé mes questions au fur et à mesure de la lecture, pour que tu te rendes compte de ce qu'un lecteur peut penser sur le coup. J'ai laissé celles auxquelles tu réponds par la suite. J'ignore si tu veux laisser le lecteur avoir des questions plein la tête ou si tu préfères lui fournir les réponses immédiatement ou au moins lui indiquer qu'il les aura plus bas.

Au niveau des codes, tu sépares souvent commande et réponse de Mongo. Peut-être serait-il préférable de faire comme si on était vraiment dans le shell ?

1
2

> command
response

Peut-être le fais-tu par la suite, mais il serait chouette de nous faire pratiquer. Créer un document, le récupérer en base et le stocker dans une variable, le modifier avec save, faire ça sur plusieurs documents, avec un boucle…

Si j'ai bien compris, un update est équivalent à un findOne puis un save ?

Sinon, j'aime beaucoup cette découverte pas-à-pas du shell, avec des loup-garous et d'autres trucs chouettes comme ça !

Projection

un document avec comme clés les attributs, comme valeur un booléen (vrai si l'on veut récupérer l'attribut, false sinon).

Tu pourrais préciser que, par défaut, tous les attributs sont à true, si je ne dis pas de bêtise. En fait, ce n'est pas si clair que ça. D'après la suite, ils sont à true si on ne spécifie pas de second argument, mais à false (sauf pour l'identifiant) si on le spécifie.

On peut aussi remarquer le document vide donné comme paramètre de requête.

Je donnerais plus bas des exemples où le premier argument n'est pas {}.

Opérateurs logiques

Exemple 2 : Combinaison !

https://zestedesavoir.com/forums/sujet/3266/or-dans-un-parametre-de-find/

On ne veut pas les personnage avec maxLife inférieur ou égal à 50, mais les personnages qui n'ont pas un maxLife supérieur à 50.

Ce n'est pas très clair dans cette phrase : "On veut sélectionner les personnages dont les points de vie maximum n'est pas plus grand que 50.".

Opérateurs utiles pour les arrays

Attention qu'il s'agit bien d'une égalité parfaite, y compris dans l'ordre et le nombre des éléments. Les deux requêtes suivantes ne produiront aucun résultat.

https://zestedesavoir.com/forums/sujet/3261/ensemble-de-valeurs-sans-ordre-particulier/

En effet, elle sélectionne les personnages qui ont un accessoire, et qui ont dans leur inventaire quelque chose

Quelque chose, pas nécessairement un accessoire je crois.

Autres opérateurs et critères

Lorsqu'un attribut comprend du texte

Le type est-il alors nécessairement "string" ?

Exemple 3 : Personnage faisant un sport contenant les lettres "ui" ou "au"

Titre.

Javascript

Pas très explicite.

var fct = function() {

Tu as un problème d'indentation juste en dessous.

Certaines requêtes méritent, je pense, d'être affichées sur plusieurs lignes. Surtout qu'elles commencent à devenir complexes.

Pour quelle raison ne mets-tu pas les résultats de certaines requêtes ?

Sinon, tu ne mets jamais d'espace après les // des commentaires. Je pense que ça ferait plus aéré. Mais c'est une question de goût personnel.

A plus !

Retour sur la modification

Opérateurs de modification de base

Exemples

Exemple : jouons un peu avec la vie de Plop

Peut-être pourrais-tu présenter la chose ainsi, pour aérer ?

On ajoute 5 à maxLife d'Hermione :

1

db.character.update({name : "Hermione"}, {$inc : { maxLife : 5}})

On donne à maxLife la plus petite valeur entre 43 et sa valeur actuelle (45) :

1
2
3
4

> db.character.update({name : "Plop"}, { $min : {maxLife : 43 } })
Response
> db.character.find({name : "Plop"}, {name : 1, _id : 0, maxLife : 1})
Response

Initialisation à l'upsertion

Dernier opérateur bien pratique : $setOnUpsert

Après, tu utilises $setOnInsert.

db.character.update({name : "Plop", type : "Lutin"}, {$set : { weapon : {name : "Pioche", twoHanded : false} }, $setOnInsert : {maxMana : 5}}, {upsert : true});

Il y a un point-virgule à la fin. Faut-il en mettre ?

Récupérer et modifier un document en une opération

Cette méthode prend un paramètre un objet qui peut contenir les attributs suivants

en paramètre

Facultatif. Critère de sélection classique, identique au premier paramètre de la méthode find()

Je rajouterais une colonne au tableau pour les "facultatif" et "obligatoire".

identique au premier paramètre de la méthode find()

Comment as-tu formaté le find() ?

Pourquoi n'utilises-tu pas la coloration syntaxique du JS pour tes codes ? Il semblerait que des fois ce soit le cas, d'autres non. A moins que le code ne soit pas pris en compte ?

Tri, limites et méthodes utiles

Vous êtes désormais capable de créer une base de données

capables

Du moins, c'est ce que tu as mis dans la conclusion de la partie "Prise en main".

Curseurs

Exemple 2 : forEach()

J'indiquerais que la fonction ne prend un et un seul argument : le document courant.

Dans le cas où l'on voudrait pouvoir manipuler les résultats avec plus de souplesse, on peut utiliser la méthode toArray() pour parcourir le curseur et récupérer un array de résultats.

Peut-être préciser que là, par contre, on n'a plus un générateur, mais bien un ensemble de valeurs qu'on peut parcourir plusieurs fois. En appuyant par exemple tes propos avec :

1
2
3
4

printjson(array[13])
printjson(array[164])
printjson(array[89])
printjson(array[164])

Tri et limites

//Trier par maxMana décroissant, puis par ordre alphabétique pour les maxMana égaux

Mongo prend en compte l'ordre des clés dans un document ? oO

En effet, un curseur de résultats ne va pas chercher les résultats dans la base de données tant qu'ils ne sont pas utilisés, c'est-à-dire affichés ou manipulés.

Je l'indiquerais dans l'extrait sur les curseurs.

//Bien préciser "var" à chaque assignation sinon les résultats associés au curseur seront affichés

Pourquoi ? cursor = cursor.sort({maxLife : -1}) ne va pas ?

Cadeau bonus : deux méthodes bien utiles

distinct() renvoie (sous forme d'array) les valeurs distinctes d'un attributs parmi les résultat d'une requête avec le critère donné

Que me reverra db.character.distinct("type") si ma collection contient ce seul document :

1
2
3
4
5
6
7
8
9

{
    type : "A",
    obj : {
        type : "B",
        obj : {
            type : "C"
        }
    }
}

Sinon, comptes-tu publier cette première partie indépendamment du reste ? Ca me semble judicieux, pour les lecteurs d'une part, vu qu'ils auront accès plus rapidement au contenu, et pour les validateurs d'autre part, qui auront moins de travail à faire d'un coup (et pourront plus facilement se partager la validation).

Merci !

Bonjour à tous !

La beta du tutoriel a été mise à jour.

Merci pour vos relectures

Dans MongoDB, un document est le pendant d'un objet.

Et une collection, késako ?

Je dis au tout début du chapitre que les données sont enregistrées dans des collections sous forme de documents. C'est pas suffisant ? En soi une collection c'est vraiment rien de plus que ça : un truc dans lequel tu mets des documents.

on peut en entretenir plusieurs copies

Question me passant par la tête : peut-on versionner ?

Pour autant que je sache, non. C'est pas fait pour ça.

en créant facilement un ensemble de fragments

Je détaillerais un chouïa le terme "fragments" : on constitue une partition des données (au sens mathématique du terme), c'est ça ? En formulant peu ou prou comme ça : "un ensemble de fragments (en anglais, "shards"), c'est-à-dire un ensemble de…".

Fait !

pas de schéma fixe, objets complexes

Il me semble qu'il manque un truc avec "objets complexes". Par exemple : "objets complexes facilement représentables".

J'ai formulé autrement, ça devrait petre plus clair.

Une transaction doit être une opération atomique, donc indivisible.

MongoDB n'a pas de transaction à proprement parler, par contre la modification d'un document est une opération atomique.

Pour chercher la petite bête (c'est pas marrant, pour l'instant tout est bien :P), je dirais que les deux phrases ne se suivent pas correctement.

J'ai reformulé cette partie

MongoDB peut être cohérente au final

"seulement à la fin" plutôt que "au final" ?

J'ai un souci avec ça, il n'existe pas de traduciton française vraiment nickel, ou en tout cas j'ai pas trouvé. En anglais on parle de "eventual consistency"…

Au passage, tu n'as pas introduit les notions de "secondaire" et "primaire" dans le premier extrait.

Fait !

il est possible que cette modification soit perdue

Pourrais-tu expliciter ce que tu entends par "perdue" ? Littéralement perdue, ou écrasée par l'ajout du champ ?

J'ai précisé mais j'ai l'impression que j'embrouille un peu du coup

Toutes les 100 millisecondes, elles sont ajoutées au journal

C'est le même principe que ext4 ?

Aucune idée

J'imagine qu'il est plus rapide d'écrire dans le journal que dans la base (techniquement parlant, mais aussi parce que, à cause de l'isolation, l'écriture dans la base peut ne pas commencer immédiatement. Du coup, comment est gérée l'isolation par le journal ?) ? Que se passe-t-il si écrire dans le journal prend plus de 100ms ? Par exemple (temps en ms) :

• t = 0 : demande d'opération
• t = 0 : écriture dans journal
• t = 120 : crash
• t = 140 : fin de l'écriture dans le journal. Ca n'a pas lieu, à cause de crash, mais c'est pour rendre compte de la durée d'écriture dans le journal.

Ici, la dernière opération a été demandée 120ms avant le crash, mais ne pourra être reprise au redémarrage.

Ce n'est peut-être pas le sujet, mais un exemple serait le bienvenu.

Il est possible que je parle des mécanisme de journaling dans la seconde partie donc je mettrais ça à cet endroit. Cela dit, je suis pas du tout sûre que j'irai aussi loin. Je pense que pour des questions pointues comme ça, faut plutôt aller voir la doc.

Tu as mis des guillemets pour dire qu'on n'installe pas vraiment MongoDB, mais un ensemble d'outils. Mais, du coup, que désigne le terme "MongoDB" ?

L'ensemble d'outils

mongod : le serveur

mongod ? Même remarque pour les autres.

Je me suis toujours demandé : pourquoi ce "d" ?

Du coup, je suis allée voir (me suis déjà posé la question 8000 fois aussi), et du coup, je l'explique

Nous allons maintenant démarrer le serveur

Je parlerais de l'option --dbpath, qui me semble intéressante.

En effet, je compte expliquer quelques options dans la seconde partie mais cette option là vaut la peine d'être introduite directement.

Pour les instructions, je mettrais dans la balise code un aperçu du shell :

1 2 3 4

> var x = 3 > 3+2 5 >

J'hésite. Pour l'instant j'ai laissé comme ça.

D'ailleurs, pour insister sur la dépendance du client au serveur, tu pourrais commencer par faire le lecteur démarrer le client, recevoir une erreur de connexion et lui expliquer qu'il faut un serveur de démarré pour que ça fonctionne.

Le message d'erreur est franchement explicite donc bof.

Je n'ai pas relevé les guillemets anglais, j'ignore ce que tu souhaites en faire.

J'ai remplacé là où tu me l'a signalé, et ceux que j'ai trouvé par la suite. Il en reste sûrement mais c'est certainement pas la dernière fois que je le relis

Je n'ai pas relevé non plus les "blabla, …". J'ignore si tu souhaites les remplacer par "blabla…".

J'ai plutôt remplacé par etc.

J'ai mis à jour la bêta avec les corrections des deux premiers chapitres. Merci pour tes retours

Je dis au tout début du chapitre que les données sont enregistrées dans des collections sous forme de documents. C'est pas suffisant ? En soi une collection c'est vraiment rien de plus que ça : un truc dans lequel tu mets des documents.

Tu as raison, il n'est pas nécessaire de faire le parallèle entre collections et POO, mais j'expliquerais tout de même un peu le terme. C'est comme si tu disais qu'en SQL les données sont enregistrées sous forme de lignes dans des tables. Le lecteur va se demander ce qu'est une table. Expliquer ce qu'est une colection pourrait se faire en expliquant son intérêt : pourquoi ne pas stocker tous les documents ensembles dans la base ?

J'ai un souci avec ça, il n'existe pas de traduciton française vraiment nickel, ou en tout cas j'ai pas trouvé. En anglais on parle de "eventual consistency"…

En fait, je pense qu'il manque un "seulement". Ce que tu veux dire, me semble-t-il, c'est que Mongo garantit la cohérence des données mais que, parfois, ce n'est garanti qu'à la fin. Au fait : à la fin de quoi ?

J'effectuerai une seconde passe un de ces quatre.

J'ai un souci avec ça, il n'existe pas de traduciton française vraiment nickel, ou en tout cas j'ai pas trouvé. En anglais on parle de "eventual consistency"…

Pour être totalement sûr, il faudrait une phrase anglaise complète à traduire, mais je partirais sur « MongoDB finit (systématiquement) par être cohérente (à un moment ou à un autre). », avec la combinaison que tu veux de parenthèses, voire aucune.

Bonjour à tous !

La beta du tutoriel a été mise à jour.

Merci pour vos relectures

Jusqu'où le contenu a-t-il été mis à jour ?