Discussion :

[Mickael Baron]

Bonjour,

Salaheddine Babouche de la société Palo IT (http://www.palo-it.com/blog) vous propose un tutoriel sur la modélisation d'un schéma d'une base de données NoSQL orientée document.

Vous trouverez cet article à cette adresse : http://paloit.developpez.com/tutorie...ntee-document/

Profitez de cette discussion pour laisser vos commentaires.

Mickael

[Kropernic]

Hello,

Je n'ai encore jamais testé de base NoSql mais les lenteurs dont il est question dans l'article, et qui seraient la raison de migrer vers ce type de base de données, ne seraient-elles pas le signe d'une base de données non correctement modélisées et mal administrées ?

J'administre quotidiennement des bases de données et les lenteurs que je rencontre ne se produise que sur les DB que j'ai modélisées avant d'avoir le savoir nécessaire et suffisant pour faire quelque chose de correct. Si les DB que j'ai modélisées par la suite, il n'y a jamais de réels problèmes de lenteurs. Peut-être de temps en temps un léger ralentissement mais c'est en général car un index a été mal pensé ou une requête mal écrite.

D'après ce que j'ai compris de la description des bases NoSql qui est faite dans l'article, ce serait en fait une sorte de gros data warehouse. Du coup, pourquoi pas. Mais à condition que les données qu'il contient ne doivent pas être mises à jour (ex : stockage de données des ventes d'un magasin). Si son contenu est amener à "vivre", alors je ne troquerai ma DB transactionnelle (et surtout relationnelle) pour rien au monde !

[hugo123]

Tout d'abord il n'existe pas qu'une seule type de base Nosql. Certaines correspondent à des cas d'usage non triviaux en relationnel (par exemple les bases orientés graphe).

Je vous invite vraiment à tester et vous documenter sur les différentes bases et leurs cas d'usage. Au pire cela vous confortera dans votre idée mais avec de véritables données pour le faire.

[fsmrel]

Bonsoir,


Les points de vue peuvent être multiples, mais je donne celui du praticien du relationnel.


En remontant à un niveau conceptuel, votre exemple des auteurs et des livres est applicable à un cas particulier : celui des associations de plusieurs à plusieurs, non porteuses de données, stables dans le temps, ce qui est quand même limité et ne mérite pas d’être élevé au rang de « paradigme » (sic !)


Modélisons l’exemple sous forme d’un diagramme dans lequel ce que vous appelez « normalisation » est respecté :




Si l’on vous suit, la table REDACTION disparaît et ses attributs sont exportés pour moitié dans la table AUTEUR d’une part et dans la table LIVRE d’autre part :






Dans ce diagramme, {LivreId} représente soit une relation (au sens de la théorie relationnelle, c'est-à-dire un ensemble), soit un sac (bag, doublons autorisés). Question : qu’est-ce que {LivreId} dans votre système, une relation ? Un sac ? (Pour des raisons de symétrie évidentes, la question vaut pour {AuteurId}). Si {LivreId} et {AuteurId} sont des sacs, alors les tables AUTEUR et LIVRE sont à leur tour des sacs, et l’algèbre relationnelle ne s’applique plus : merci alors de décrire les opérateurs de l’algèbre des sacs que vous utilisez.

Par contre, si {LivreId} est une relation, c’est un ensemble et les doublons sont de facto interdits. Comment garantissez-vous alors l’unicité des valeurs de cet ensemble ?


Vous écrivez : « La solution réside dans la dénormalisation des données ».

Quelle forme normale est en cause ? Sachez que du point de de vue de la théorie relationnelle, si {LivreId} et {AuteurId} représentent des relations, alors en réalité ce sont des RVA (Relation-Valued Attributes) et selon votre modélisation, AUTEUR et LIVRE respectent (au moins) la première forme normale. Vous lirez avec profit ce qu’a écrit C. J. Date à ce sujet dans Database Design and Relational Theory: Normal Forms and All That Jazz (Theory in Practice), au chapitre 4. Pour mémoire, les RVA ne datent quand même pas d’aujourd’hui, elles ont été présentées par Date et Darwen en 1991, dans Relational Databases, Writings 1989-1991, ainsi que les opérateurs dont elles sont l’objet.


Questions :

— Quelle algèbre utilisez-vous dans votre système ? Quels en sont les opérateurs ?

— Comment garantissez-vous l’intégrité référentielle ?

— En comparant les figures 1 et2 ci-dessus, on comprend que vous mettez manifestement en cause l’opération de jointure. Où est votre prototype de performances et son bilan chiffré prouvant que votre système est tellement supérieur ès matière, que JOIN est bon pour être rangé au rayon des accessoires obsolètes ? Vous ne démontrez rien, vous ne faites qu’affirmer : opinions et incantations ne suffisent pas.


En passant, quand vous écrivez :

« L'idée est de dupliquer le minimum de données du document B dans A et de préférence, celles qui ne changent pas souvent, car lors de leur mise à jour, nous devrions faire un update sur l'ensemble des documents qui les contiennent, plutôt qu'à un seul endroit dans une base de données normalisée. N'oublions pas que ces modifications augmenteront le temps d'écriture. »

Selon la figure 1 ci-dessus, pour répondre à une question portant sur les seules données propres à un auteur : nom, prénom, indépendamment des ouvrages auxquels il a collaboré, la consultation de la table AUTEUR suffit. Maintenant, si un tuple de la table donne lieu à un enregistrement physique, selon la figure 2, certes la consultation de la table AUTEUR suffit là aussi, mais cet enregistrement physique est pondéralement surchargé par les données (images des « clés primaires ») relatives aux livres.


Supposons maintenant que l’on veuille savoir quels auteurs ont rédigé quels chapitres des livres. Selon la figure ci-dessous, ça sera simple. En effet, la structure de la figure 1 évolue ainsi :





Que devient votre propre structure ?

Dans le cas de la figure 3, pour répondre à la question, utilisons par exemple SQL :

Code SQL :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
SELECT AuteurNom, AuteurPrenom, LivreNom, ChapitreNo
FROM   AUTEUR AS x JOIN REDACTION AS y ON x.AuteurId = y.AuteurId
                   JOIN LIVRE AS z ON y.LivreId = z.LivreId ;

Merci de fournir la requête équivalente dans le contexte de votre propre système.


Vous concluez ainsi :

« Encore une fois, vous l'aurez remarqué, on vient d'assister à un bel exemple de retour vers le passé »

Phrase malheureuse ! Je remplacerais volontiers « bel » par un de ses antonymes...


Bref, étoffez, étayez, quantifiez, prouvez.

[hugo123]

Je vais me permettre de répondre à certains points même si je ne suis pas l'auteur du post initial.

De façon générale Mongodb, comme d'autres stores orienté document, déporte une partie de la logique référentielle côté applicatif comme par exemple les questions portant sur l'intégrité référentielle (mon id de document est il bien présent dans une autre collection ?).

Vous demandez quelle algèbre relationnel est utilisé. Or justement ce n'est pas un store relationnel. Il n'y a donc pas de notions ensemblistes, pas d'union, pas d'intersection rien de tout cela. En tout cas pas entre deux collections de document.

Par rapport aux performances, effectivement MongoDB a fait des choix de design en sacrifiant des fonctionnalités au profit de performances :
- pas de transactionnalité (*)
- pas de jointures (pas de contraintes d'intégrité également)

Par rapport aux preuves concernant les performances, le mieux est d'aller sur les docs officiels de tout ces stores nosql qui ont déjà publié sur le sujet.
Attention, je le répète, oui c'est plus performant (et encore ca dépend du contexte) mais au détriment de fonctionnalité et c'est un choix assumé.

Il faut bien comprendre que Mongo parie sur le fait que vous allez être capable de modéliser sous forme d’agrégats au sein d'une même collection. Donc que vous n'aurez pas besoin de jointures car votre document sera "autonome", il contiendra toutes les données nécessaire pour le comprendre. Même si pour cela il aura été nécessaire de dupliquer de l'information (d'ou la dénormalisation). La dessus je vous invite à regarder du côté de Domain Driven Design qui revient justement beaucoup sur cette différence d'approche avec le relationnel (tel qu'on le voit souvent pratiqué en tout cas).

En fait Mongodb n'est pas adapté à tous les cas d'usage. Si vous avez un fort besoin transactionnel alors ce n'est pas adapté par exemple. Vous aurez cependant peut-être des pistes pour vous ôter cette contrainte via des mécanismes de messaging et de reprise sur erreur mais en tout cas ce n'est pas certainement pas sans effort.
Mais ce serait une véritable erreur de prendre un modèle relationnel existant et de le traduire "mot à mot" en Mongo. Le paradigme sera différent et l'absence de fonctionnalités fera très mal. Tandis que le gain en performance sur une petite volumétrie sera peu visible, sinon inexistant. Il y a une réelle nécessité à repenser son architecture.
Oui le monde relationnel est très bon pour de la modélisation car il permet de représenter beaucoup de choses et c'est assez souple post "première modélisation", notamment grace aux formes normales.
La contrepartie c'est justement que cette souplesse amène parfois à des modélisations "monstrueuses" avec des centaines de tables, des dizaines de colonnes pour certaines. Je suis sûr que vous allez me dire que c'est exagéré ou que c'est la faute des développeurs. Par expérience j'ai pourtant souvent vu ces monstres, y compris avec des DBA sur le projet. Et c'est plutot logique pour un modèle qui évolue pendant des années.

Je suis conscient que cette réponse et l'article puisse paraître très frustrant car on ne voit pas forcément les possibilités offertes. De plus un grand nombre de cas ne se prête pas à l'utilisation d'un store orienté document et il y a des gens qui se plantent en s'y essayant. En tout cas en s'y essayant avec une approche "relationnelle" entré avec un marteau dans le modèle de Mongo.

Pensez peut-être à d'autres cas d'utilisation : stockage de logs (aucune relation entre logs, schéma flexible et non prédéfini), vue analytique, monitoring.
Vous trouverez d'autres cas d'usage possible sur cette page :
- http://docs.mongodb.org/ecosystem/use-cases/
- ou sur cette présentation http://fr.slideshare.net/Dataversity...cases-13695677


(*) A noter que Tokumx propose une surcouche transactionnelle au dessus de MongoDB.

[Mickael Baron]

Hugo,

ça c'est de la réponse. Merci pour ton point de vue.

Mickael

[landry161]

Je vais me permettre de répondre à certains points même si je ne suis pas l'auteur du post initial.

De façon générale Mongodb, comme d'autres stores orienté document, déporte une partie de la logique référentielle côté applicatif comme par exemple les questions portant sur l'intégrité référentielle (mon id de document est il bien présent dans une autre collection ?).

Vous demandez quelle algèbre relationnel est utilisé. Or justement ce n'est pas un store relationnel. Il n'y a donc pas de notions ensemblistes, pas d'union, pas d'intersection rien de tout cela. En tout cas pas entre deux collections de document.

Par rapport aux performances, effectivement MongoDB a fait des choix de design en sacrifiant des fonctionnalités au profit de performances :
- pas de transactionnalité (*)
- pas de jointures (pas de contraintes d'intégrité également)

En fait Mongodb n'est pas adapté à tous les cas d'usage. Si vous avez un fort besoin transactionnel alors ce n'est pas adapté par exemple.

Ouais

[SQLpro]

Vous demandez quelle algèbre relationnel est utilisé.

Il a demandé quel algèbre. Il n'a pas suggéré que c'était l'algèbre relationnelle. N'oubliez que l'ordinateur (et tout ce qui va avec) est un outil mathématique... Donc la question est bien celle de la théorie et donc des opérateurs algébriques utilisés....

A +

[landry161]

Bonjour,

Salaheddine Babouche de la société Palo IT (http://www.palo-it.com/blog) vous propose un tutoriel sur la modélisation d'un schéma d'une base de données NoSQL orientée document.

Vous trouverez cet article à cette adresse : http://paloit.developpez.com/tutorie...ntee-document/

Profitez de cette discussion pour laisser vos commentaires.

Mickael

Bonjour Salaheddine Babouche je suis moi même en train de rédiger en ce moment mon article sur le NoSQL ( mongodb). Tu as énuméré certains points tels que la dénormalisation et surtout la scalabilité. Je l'ai deja téléchargé et je compte même l'ajouter en référence dans mon article.

Bravo.