Discussion :

[Minim0i]

Bonjour,

Actuellement en 5ème année dans une école supérieure en informatique, je dois réaliser un mémoire afin de valider cette dernière.

Celle-ci portant sur le NoSQL j'aimerais solliciter votre aide afin de m'orienter et répondre à certaines de mes questions.

Le sujet est le suivant : "Le NoSQL mettra t-il fin à l'utilisation des bases de données relationnelles?"

Voici un plan non exhaustif:

I/ Introduction
II/ SGBDR (qui présentera les caractéristiques des SGBDR)
III/ NoSQL (présente les caractéristiques du NoSQL)
IV/ L'utilisation actuelle du NoSQL (montre actuellement ce que l'on peut faire avec)
VI/ Un SGBD complémentaire (j'essaierais d'émettre de nouvelles idées permettant d'associer le NoSQL et les SGBDR

Pour le moment, j'aurais voulu savoir si vous avez eu l'occasion de manipuler le NoSQL, vos ressenti sur cette techno.
Pensez vous qu'il est possible de l'adapter pour des applications?

En vous remerciant par avance pour vos réponses.

Cordialement,
Thewmat

[Jester]

Un constat simple, dans les 3 entreprises où j'ai travaillé, il y avait à chaque fois des données non relationnelles stockées dans des bases de données relationnelles (MySQL, Oracle et SQL Server).

J'avais vu une présentation qui montrait que du non structuré sous postgresql était aussi rapide que sous mongodb. Je n'ai plus le lien sous la main.

Plus qu'une vision purement technique, il peut être intéressant d'apporter un éclairage culturel à la chose. Le NoSQL vient d'un milieu plus axé sur le dev applicatif qui ne cherche pas à utiliser ni comprendre 99% du monde relationnel. Des sociétés comme facebook ou yahoo ont une ressource considérable pour développer leur système de gestion de données qui est le coeur de leur business. De fait il peuvent aussi bien faire un soft qui répond exactement à leur besoin et leur culture.

Si on regarde Hadoop/Hive vs les SGBD MPP équivalent, les performances sont très mauvaise, même sur les sujet propre à hadoop (parsing de log). Mais le coût du soft est faible. Là encore ce n'est pas la technique qui parle mais la culture, enfin les finances.

[ddoumeche]

D'un point de vue du développeur, on peut espérer que le NoSQL ne remplacera pas le SQL à long terme, car il lui manque l'outil indispensable et basique que sont ... les contraintes, donc le fameux Relationel sur lesquels repose toute la cohérence d'un SGBDR. Mais également les transactions, et j'en passe.

Sinon nous allons en revenir 40 ans en arrière, temps béni où il fallait gérer la cohérence soit-même. J'ai connu récemment une société qui avait aussi fait le choix du partitionnement horizontal (en shards) avec très peu voir aucune contrainte. Il a fallut tout mettre en place petit à petit, un travail long et minutieux.. pour finalement passer à vrai produit NoSQL. Je souhaite bien du courage à cette société.

Pour ce qui est du sockage de données non structurées, les types binary et varbinary existent fort longtemps et permettent de stocker ce qu'on veut.

D'un point de vue d'architecte, reconnaissons que les bases NoSQL répondent à une problématique précise, celle du BigData, ou d'autres marchés de niche (base de données orientées object, etc..). C'est à dire que pour stocker des volumes importants de données, petaoctets et au dela, il vaut mieux dénormaliser (rappelons que la dénormalisation est un processus connu, conseillé et pratiqué par les DBA). Mais un tel volume de donnée ne touche qu'un nombre restreint de sociétés.

Pour surenchérir sur ce que disait Jester, effectivement le milieu du dev ne connait pas assez la modélisation et le problème est là : on parle de pattern et d'anti-patterns en développement, mais ils existent aussi dans le monde relationnel, mais presque personne n'en parle ou les connait à part les DBAs qui sont une espèce rare.

[Minim0i]

Bonjour et merci d'avoir répondu.

Intéressant le point de vue comme quoi postgresql serait plus rapide que mongodb. Je vais chercher pour en savoir plus.

Certes le relationnel est mis de côté comme tu as pu le souligner, mais il est possible de gérer les relations dans l'application et c'est ce qui se dessine de plus en plus. Nombreux sont les projets ou j'ai pu constater une base de données dans relations.

Peut être essayer de trouver un système de base de données qui serait un complément des deux, c'est à dire trouver un compromis entre la "scalabilité" et la relationnel?!?

Cordialement,

Thewmat

[DotNetMatt]

Certes le relationnel est mis de côté comme tu as pu le souligner, mais il est possible de gérer les relations dans l'application et c'est ce qui se dessine de plus en plus. Nombreux sont les projets ou j'ai pu constater une base de données dans relations.

Je ne partage pas cette analyse S'il n'y avait pas de relations, c'est que tu es tombé sur des projets particuliers (avec des besoins très spécifiques), ou sur des projets où des personnes incompétentes ont eu à mettre en place une base de données qui aurait dû être relationnelle.

Les bases de données relationnelles ne sont certainement pas mises de côté et ne sont pas prêt de l'être sur la plupart des projets. L'une de leurs utilités est la contrainte d'intégrité référentielle. Ces mécanismes peuvent être réalisés côté applicatif, mais l'intérêt n'est limité qu'à certains types de projets. Les moteurs de base de données sont conçus pour gérer ces choses-là, donc autant les laisser faire et éviter de perdre du temps à réinventer la roue.

Peut être essayer de trouver un système de base de données qui serait un complément des deux, c'est à dire trouver un compromis entre la "scalabilité" et la relationnel?!?

C'est une utopie. Les systèmes de type NoSQL et les SGBDR sont utilisés de manière complémentaire, car les besoins sont différents. On va utiliser du NoSQL dans certains cas, mais dans d'autres, cela sera nettement moins performant qu'un SGBDR, et vice-versa...

Tout est une question de projet et de besoins.

[fsmrel]

Pour appuyer l'approche DotNetMatt des choses :


Défense et illustration de l'intégrité référentielle.

Quitte à me répéter, je reprends un échantillon d'expériences que j'ai vécues chez ceux qu'on appelle les "grands comptes".

Peut-on faire l'impasse sur le contrôle de l'intégrité référentielle par le SGBD ? Demander à l’application de garantir l’intégrité des données suffit-il ?

Dans le cas des applications traditionnelles de gestion, mais néanmoins centrales, vitales, dans le monde des entreprises telles que les banques, les sociétés d’assurance, les caisses de retraite, dans la distribution, l’industrie, les administrations, etc., la réponse est non, car il peut en résulter de très sérieux dommages. Pour l’illustrer, voici quelques péripéties dans lesquelles j’ai trempé, dépêché par mon entreprise (une SSII) pour rattraper le coup quand c’était possible.

Il était une banque où je fus appelé pour tenter de rétablir les liens entre les tables des comptes, des contrats, des clients, etc. La cata. J’ai tout tenté pour remettre les choses d’aplomb. Le Président lui-même me posait tous les matins la même question dans laquelle l’angoisse était à peine voilée : « Alors ? mes en-cours ? » Peine perdue. La banque n’existe plus.

Une société d’assurance. Pour le DSI, la base de données Clients c’était du béton : « Je n’ai jamais entendu parler de quelque problème que ce soit, tout baigne ». J’étais alors chargé de valider un modèle conceptuel de données et le modèle logique dérivé, ceci pour une autre base, alimentée à partir des données de production. Ayant mis en œuvre l’intégrité référentielle pour la nouvelle base, ce qui devait arriver arriva, ce fut un révélateur : 30% de données rejetées lors de la « remontée » dans la base toute neuve. Le DSI verdit et il fallut plus d’un an pour arriver à remettre la base Clients à peu près d’équerre.

Une société de crédit automobile. Pour valider une application en cour de refonte, j’avais été autorisé à copier les données de production. Je fus obligé de porter le pet au plus vite, car il y avait quelques milliers de contrats faisant référence à des clients inconnus au bataillon. Panique à bord, tout le monde sur le pont... Après enquête, il s’est avéré que, suite à un incident matériel en production, il y avait eu une restauration des données Clients/Contrats, mais à partir d’une sauvegarde des clients ayant eu lieu à une date n’ayant rien à voir avec la date de sauvegarde des contrats. Heureusement, il y avait un an de backup en magasin et le coup put être rattrapé. (Le SGBD n’était pas relationnel. Il a par la suite été remplacé par DB2, lequel aurait tout de suite détecté le décalage des sauvegardes.)

Une caisse de retraite. Un décideur (fonctionnel) décide de faire débrancher l’intégrité référentielle pour une partie de la base de données. Prudent, je recopie les tables de production dans un environnement qu’on m’a affecté, j’écris toutes les requêtes SQL pour vérifier (de nuit, car il est hors de question de pomper du temps machine pendant la journée) que les tables impliquées sont restées cohérentes suite à traitement diurne. Au résultat, ça n’a pas traîné : je constate que 780000 périodes passées par les cotisants dans les entreprises se sont envolées (peut-être étaient-ce les vôtres ?) Traitements à refaire, avec ordre cette fois-ci du décideur de brancher l’intégrité référentielle. Qu’est-ce qu’il ne faut pas faire pour que les gens comprennent...

Et j’en ai bien d’autres...

Il faut être vraiment naïf pour croire que les contrôles d’intégrité assurés par programme permettent de dormir sur ses deux oreilles. Après tout, dans la série « ceinture, bretelles et épingle à nourrice », si vous avez un DBA sous la main, tout en laissant l’application consciencieusement contrôler ce qu’elle à a à contrôler, demandez donc à ce spécialiste de mettre en œuvre l’intégrité référentielle, au moins pour les tables les plus sensibles, ou (si le chef refuse), de développer et exécuter les requêtes permettant d’auditer le contenu des tables et montrer les dégâts.

Par référence aux trois petits cochons, il faut préférer construire une maison en briques plutôt qu’en paille, il faut implanter l’intégrité référentielle. Attention au loup, si vous préférez l’approche Nouf-Nouf et Nif-Nif et effectuer les contrôles au niveau de l'applicatif...



L’approche Naf-Naf est décisive...




François

(40 ans d'expérience dans les grandes bases de données, de la dunette à la soute.)

[SQLpro]

Pour info, sur l'IR, j'ai fait maintenant plus de 50 audits de bases.
Dans toutes des bases de données ou l'IR n'existait pas de manière native côté SGBRD, j'ai trouvé des lignes orphelines.

Il y a quelques années, pour une entreprise japonaise du domaine du photocopieur, on m'a dit d'emblée qu'il n'y avait pas d'IRD, mais que les développeurs japonais (et on sait le haut niveau de qualité exigé par les japs...) n'avaient jamais eu de problème dans le contrôle de cet intégrité faite du côté applicatif par des processus robustes et maintes fois éprouvées....
Manque de pot, la base de données française était la plus grosse du monde (état jacobin et centralisation...) et il y avait des lignes orphelines dans deux tables (sur plus d'une centaines) ce qui était déjà peu. Dans l'une, une seule ligne était en défaut et dans l'autre moins de 0,01%...
Lorsque j'ai remis mon rapport à la direction française on m'a dit que cette partie serait retirée du rapport, parce que les japonais prenant tout au sérieux et ne voulant pas être désavoués, il était probable que le responsable se fasse harakiri !
Bref, il fallait qu'il découvre par lui même le problème un jour ou l'autre !

A +

[Minim0i]

Bonjour et merci pour vos réponses, je prend bien note.

Je suis parti sur le plan suivant:

1. Introduction

2. Présentation du SQL
2.1. Algèbre relationnelle
2.2. Présentation du SGBDR
2.3. Modèle entité / relation
2.4. Langage de traitement de données

3. Présentation du NoSQL
3.1. Les différents type de BDD
3.2. Les leaders du marché

4. L'utilité du NoSQL
4.1 Différences entre NoSQL et SQL
4.2 Différences entre les différents type de BDD NoSQL

5. Vers un nouveau système de SGBD?
5.1. Mise en place d'un nouveau SGBD
5.2. NewSQL

6. Conclusion



Est-ce judicieux?

Je n'oublie rien?

Cordialement,

Thomas

[ddoumeche]

Cela me semble judicieux. Fait nous parvenir ton mémoire finalisé

[SQLpro]

Bonjour et merci pour vos réponses, je prend bien note.

Je suis parti sur le plan suivant:

1. Introduction

2. Présentation du SQL

Non pas SQL, relationnel

2.1. Algèbre relationnelle
2.2. Présentation du SGBDR
2.3. Modèle entité / relation

Non, entité association (les relation sont les conséquences du passage du modèle conceptuel au modèle logique, et ce sont les objets mathématiques porteur des données)

2.4 bases du langage SQL
2.5 gestion des transactions

2.4. Langage de traitement de données

3. Présentation du NoSQL
3.1. Les différents type de BDD
3.2. Les leaders du marché

4. L'utilité du NoSQL
4.1 Différences entre NoSQL et SQL
4.2 Différences entre les différents type de BDD NoSQL

5. Vers un nouveau système de SGBD?
5.1. Mise en place d'un nouveau SGBD
5.2. NewSQL

6. Conclusion



Est-ce judicieux?

Je n'oublie rien?

Cordialement,

Thomas

A +