Grosse base de données et performances

[GyLes]

Et même s'il s'agissait des SGBD, étaient-ils correctement réglés, les tables normalisées ? Etc.

C'est un argument qui peut être repris pour les SGBDOs tant critiqués Il y a aussi des règles de l'art à appliquer.

Encore une fois, je ne rentre pas dans un combat de comparaison entre SGBDR et SGBDO, cela ne m'intéresse pas des plus, c'est l'ouverture vers ses systèmes, leur domaine d'application et leurs avantages qui m'intéressent.

On amalgame et on file vers le sophisme.

Etudions dans ce cas les avantages des SGBDOs dans leur domaine d'application, et arrêtons les critiques des plus simples comme "Les SGBDOs ne sont pas performants, obsolètes et inutiles, les SGBDRs sont les meilleurs, un point c'est tout". Ce type de discussion n'est pas très constructive.

Je serai bien plus heureux d'échanger de manière constructive la-dessus. Donnez moi une étude, un article, ... quoique ce soit qui montre l'utilisation d'un SGBDR dans les domaines d'application d'un SGBDO. Que le SGBDR dans ce domaine dépasse de loin les performances, la fiabilité et les avantages des SGBDOs.

Je vous ai donné quelques uns des domaines d'applications des SGBDOs, et c'est dans ces domaines qu'ils se montrent les plus utiles (Ingénierie, bureautique, base de données embarquées, génie logiciel, ...).

Je ne suis pas venu sur le topic en lancant que les SGBDRs étaient dépassés, et vive les SGBDOs. J'ai uniquement ouvert la voie vers une utilisation possible d'un SGBDO. Pourquoi pas ?

Je n'ai rien contre vous fsmrel, j'ai lu quelques uns de vos postes et j'en respecte le contenu. Ne rentrons pas dans une discorde de propos.

Votre réactions sur mon précédent poste m'auraient plus intéressé que votre remise en question sur une étude (sur quelles études se baser alors, il ne me semble pas que KLAS soit un fournisseur de SGBDOs d'ailleurs ).
http://www.healthcomputing.com/

Que pensez-vous des mécanismes d'optimisation similaires aux SGBDRs ? Des spécificités des optimiseurs ? Des benchmarks OO1, OO7 ou polepos qui comparent directement quelques SGBDRs avec mapping et un SGBDO (db4o pour le moment) ? Avez-vous lu les succes stories de Objectivity par exemple ?

Cordialement,
Gilles

[fsmrel]

Bonsoir Gilles,

Votre réactions sur mon précédent poste m'auraient plus intéressé que votre remise en question sur une étude (sur quelles études se baser alors, il ne me semble pas que KLAS soit un fournisseur de SGBDOs d'ailleurs).

Certes, mais je ne suis pas resté insensible à cette étude à laquelle vous renvoyez, à l’occasion de votre dernier message. Ce que j’ai écrit ne visait pas les SGBD quels qu’ils soient, mais les conclusions de ce sondage dont Coluche aurait pu s’inspirer (lessive machin contre lessive truc). Ce genre d’étude comparative a le don de m’énerver, ça valait un message d’avertissement à usage général. J’ai trop rencontré de ces prétendus experts qui ont bâti leur compétence en collectionnant ce genre de conclusions subjectives, bien habillées, pendant que de mon côté j’étais dans la soute à faire marcher la machine (ne prenez pas cela pour vous).

je ne rentre pas dans un combat de comparaison entre SGBDR et SGBDO

Moi non plus ! Comparer, je faisais ça quand j’étais jeune, mais sérieusement, avec les SGBD en main et sous le contrôle de qui de droit, comme je l’ai déjà dit. Cela motive aussi mon agacement à l’endroit du sondage évoqué.
Souvenez-vous de ce que j’ai écrit à propos de cette personne dont le sujet était l’accidentologie et ne jurait que par son SGBDO : je ne pensais pas que j’aurais été capable de faire aussi bien avec mon SGBDR "généraliste" (mon message du 27/04/2007). Il eut été stupide de ma part de chercher à la convaincre de changer.

Etudions dans ce cas les avantages des SGBDOs dans leur domaine d'application, et arrêtons les critiques des plus simples comme "Les SGBDOs ne sont pas performants, obsolètes et inutiles, les SGBDRs sont les meilleurs, un point c'est tout".

Une fois de plus, je ne fréquente pas le café du Commerce. Je ne critiquerai jamais gratuitement ni ne ferai l’éloge d’un SGBD que je ne connais pas, qu’il soit R, O, mixte, américain, français, martien ou autre. Tout au plus fais-je telle ou telle observation à propos de telle ou telle fonctionnalité importante sur laquelle je m’interroge, par exemple : comment garantit-on l’intégrité référentielle autrement que par programme ? Comment est définie la métabase et comment y a-t-on accès ? La théorie de la normalisation a-t-elle un sens ? Etc.

Je répète donc que je ne juge pas, contrairement à ce que vous laissiez entendre dire :

Loin de moi l’idée de sous-estimer les possibilités de récupérer mille "enregistrements" de la part d’un SGBDO. J’émets seulement des réserves — et ceci vaut également pour les SGBD relationnels !

=> Je ne critiquerai jamais un SGBD quel qu’il soit sans l’avoir secoué sur le terrain. Est-ce clair ?

Je ne suis pas venu sur le topic en lancant que les SGBDRs étaient dépassés

De fait, ceux qui, par exemple, font la promotion de Caché sont là pour ça, mais il ne fallait pas me mettre leur article sous les yeux.

Que pensez-vous des mécanismes d'optimisation similaires aux SGBDRs ? Des spécificités des optimiseurs ? Des benchmarks OO1, OO7 ou polepos qui comparent directement quelques SGBDRs avec mapping et un SGBDO (db4o pour le moment) ?

Je pense que du temps où je passais mon temps dans la soute, j’aurais étudié tout cela très sérieusement. Aujourd’hui, je préfère dire que je n’en pense rien, parce que ça relève plutôt de la technologie, donc avec le temps ça devient vite obsolète et ça se remplace : je préfère la réflexion portant sur les fondements, parce qu’ils sont intemporels, ils sont au dessus des technologies. Quand vous relirez dans dix ou vingt ans les articles techniques d’aujourd’hui, il y a de fortes chances que vous trouverez que ça aura bigrement vieilli, même si ça sera avec nostalgie. Ainsi, Je ne connais pas ce logiciel Hibernate que vous évoquiez, mais d’une façon ou d’une autre, s’il a une espérance de vie suffisante, il aura résolu ses problèmes actuels (ou d’autres s’en seront chargé...)
Le Modèle Relationnel de Données a ma faveur parce qu’il est solidement ancré dans la logique des prédicats sans être pour autant figé, on y parle d’ensembles et de prédicats plutôt que de pointeurs et quand je relis ce que Codd a écrit il y a trente-cinq ans, je constate que les fondements n’ont pas bougé, ce qui n’a pas empêché des évolutions, qui du reste continuent aujourd’hui (à l’instar de la logique, qui n’a jamais été remise en cause depuis Aristote mais s’est enrichie avec Frege et ses successeurs). A l’occasion, j’essaie d’en faire profiter les autres, en essayant de leur parler de la Théorie relationnelle, quitte à descendre au niveau de la technologie relationnelle quand cela s’avère nécessaire. Et puis la théorie relationnelle est particulièrement utile pour s’assurer de la validité d’un diagramme entité/relation ou d’un diagramme de classe (normalisation). Mieux on est équipé, mieux c’est...

[mhoudas]

Les premiers SGBDOs industriels ont vus le jour il y a plus de 12 ans, de cette génération il ne reste plus que Versant et (Poet) et dans une mondre mesure ObjectStore et Objectivity. Pour rappel Caché n'est pas vraiment un SGBDO mais une base de type NF2 (base de données de type Unidata ou VMark)Pourtant l'approche objet s'est imposé tant au niveau des langages que des méthodes et des produits ou frameworks, seul le stockage reste relationnel et le restera encore surement tres longtemps. Les critères de performance et de transpartence de la persistence (productivité en phase de développement et de maintenance) mis en avant par les éditeurs de SGBDO sont notoirement insuffisants pour faire basculer le marché et les retours d'expérience ne sont pas suffisament satisfaisants. Pourtant les performances peuvent être au rendez-vous, en effet un SGBDO est un SGBD réseau structuré par un modèle objet et il est évident que la navigation (pointeur) est plus rapide que la jointure (algo de trie) encore faut-il que les chemins soient prévus. Un SGBDO est donc bien adapté en terme de performance aux modèles complexes (beaucoup derelations entre classes et/objet) et peu aux applications de gestion traditionnelles. La performance va aussi dépendre du type d'applications (transactionnelle ou non, nombre d'objets, taille des objets) et de l'implémentation interne du SGBDO dans des proportions que l'on ne retrouve pas aujourd'hui entre les divers SGBDR sdu marché.
La transparence de la persistence est plus un argument marketing pour les grosses applications et va dépendre énormement des choix d'implémentation au niveau du produit (serveur d'objets, serveur de pages, granularité du verrouillage(objet vs page), modèle transartionnel (optimiste, pessimiste,transactions longues, transactions imbriquées, modèle objet du SGBDO lui-même).
Quelques problèmes liés à l'adoption des SGBDOs:
1) Manque de standard (L'ODMG (Binding C++ et Java, OQL) est plutôt un échec, SQL3 n'est pas objet et est complexe;
2) Interopérabilité entre les langages (C++ persistent, java persistent, modèle neutre (type O2C)
3) Evolution du schéma versus Modèle de classe de l'application à mettre en relation avec la problèmatique des vues
4) Langage de requêtes et optimiseur
5) Outils (les outils fonctionnent avec un SGBDR pas un SGBDO)
6) Administration et exploitation
7) Formation
8) Perennité

[fsmrel]

Bonjour mhoudas,

Je ne vous suspecte pas de favoriser outre mesure une classe de SGBD, mais manifestement vous exprimez des regrets... Cela dit, je souhaite commenter certaines de vos affirmations.

un SGBDO est un SGBD réseau structuré par un modèle objet et il est évident que la navigation (pointeur) est plus rapide que la jointure (algo de trie)

C’est du 2e degré ?

J’ai utilisé, chahuté des SGBD bourrés de pointeurs dans tous les sens entre 1970 et 1985 (IMS/DL1, IDMS, TOTAL, etc.) sur de très grandes bases de données. C’était l’époque héroïque, et nous proclamions : navigation par pointeurs = puissance absolue. Et puis j’ai utilisé DB2. Il y a maintenant 20 ans, j’ai pris la peine de passer près de deux cents nuits sur un mainframe à le comparer en termes de performance avec un champion « réseau » : ça m’a permis de confondre son promoteur français qui tirait à boulets rouges sur DB2, clamant en toute méconnaissance de cause que c’était une brouette (marketing oblige). Manque de chance, non seulement je connaissais très bien le SGBD réseau concerné, j’avais aussi appris à maîtriser DB2. J’ai prouvé au détracteur que, mal utilisé, DB2 pouvait aller 1000 fois trop lentement (à cause des produits cartésiens et autres facéties) mais qu’utilisé normalement (c'est-à-dire dans l’esprit ensembliste), c’était une bombe, allant au bas mot 10 fois plus vite que son champion. La performance d’un système réseau est à peu près constante, il n’y a pas de surprise. Au contraire, un SGBDR digne de ce nom, c’est comme une Ferrari : mal réglé, c’est une catastrophe, mais entre des mains compétentes, il laisse les SGBD non relationnels sur place. La clé : lui faire confiance (s'il le mérite !) et lui sous-traiter la programmation, le comment, le procédural, et ne lui présenter que le quoi, sous la forme d’un prédicat (« Donne-moi les noms des clients qui n’ont pas réglé leur cotisation depuis telle date et qui sont déjà fichés à la banque centrale avec un risque en trésorerie supérieur de 10% à la moyenne nationale »). L’optimiseur du SGBDR (inévitablement de plus en plus puissant au fil des versions) prend donc la programmation en charge, il l’encapsule pour utiliser un mot à la mode. Clairement, un SGBDR n’est pas un quelconque outil de stockage et, tel le bœuf moyen, auquel on ne demande pas de réfléchir ! Regardez Oracle, ce fut une brouette mais aujourd’hui vous ne pouvez qu’être impressionné quand vous constatez qu’il lui faut moins de 100 millisecondes pour traiter (récursivement bien entendu) une nomenclature de 150 000 lignes avec jointure avec d’autres tables à la clé, à partir d’une requête comportant 5 ou 6 lignes (10 millisecondes demain ?)... L’intérêt des SGBDR est qu’au lieu de vouloir nous intéresser aux cacahuètes les unes après les autres (pointer chasing), nous pouvons nous intéresser uniquement au sac qui les contient, quitte en fin de parcours à présenter les cacahuètes "résultat" aux utilisateurs, une par une, dans l’ordre qui fait plaisir à ces derniers (comme dans le cas de la nomenclature évoquée). Évidemment, si l’on n’adhère pas à l’esprit ensembliste, on peut en rester à une culture séquentielle et considérer un SGBDR comme un vulgaire outil de stockage, mais alors cela n’offre pas plus d’intérêt que de se mettre au volant d’une Ferrari et de rester en première...

Dans le même sens, c’est quoi cette histoire « d’algo de trie » ? Encore une fois, la cuisine au niveau physique doit rester sous le capot. Pour parler vulgairement, le tri on s’en tape, ça n’est pas notre problème, mais celui du SGBD. Je crois que vous confondez le niveau logique et le niveau physique. Si le SGBD a besoin de trier, qu’il le fasse, parce qu’indirectement on l’y force (ORDER BY, GROUP BY, DISTINCT, UNION, etc.) et qu’aujourd’hui c’est sa technique, ou parce qu’il n’a pas les bons index pour optimiser la durée de l’opération de jointure, mais parler d’algorithme de tri dans un contexte relationnel est une pétition de principe totalement gratuite. Quand tris et index, auront été remplacés par d’autres technologies, nos requêtes SQL (ou QUEL, QBE, D, etc.) n’auront pas à être modifiées (voyez par exemple le TranRelational Model de Steve Tarin, modèle dans lequel TransRelational signifie transformation et qui agit non pas au niveau logique, mais plutôt physique).

encore faut-il que les chemins soient prévus.

Ben oui. Je pense que l’approche OO est en cause. Par contraste, un des soucis de Ted Codd, père du Modèle Relationnel de Données était de celui de la symétrie : quel intérêt à favoriser telle ou telle requête au détriment de telle autre ? Un système relationnel doit être équilibré et équitable. Du fait de son caractère associatif par valeurs prises par les attributs des tables, son modèle ne privilégie effectivement aucun « chemin » (mot qui est donc sans signification avec le Modèle relationnel).

La performance va aussi dépendre du type d'applications (transactionnelle ou non, nombre d'objets, taille des objets) et de l'implémentation interne du SGBDO dans des proportions que l'on ne retrouve pas aujourd'hui entre les divers SGBDR sdu marché.

Allez explorer l’optimiseur de DB2, vous m’en direz des nouvelles. Cela dit, je suis d’accord que SQL est devenu monstrueux par sa corpulence et ses verrues et qu’il ferait bien de se recaler sur la théorie relationnelle, avec un bon lifting, un bon coup de rasoir d’Occam, pour que les optimiseurs des SGBDR puissent travailler sur des concepts parfaitement orthogonaux et fonctionner vraiment plein pot (en l’occurrence, orthogonalité veut dire indépendance, donc puissance).

Bien entendu, il y a d’autres éléments que le SGBD lui-même à prendre en compte pour qu’une application percute, sinon ça serait magique. Suite à la mauvaise performance des applications, j’ai audité bien des modèles de données. Ces modèles avaient été généralement concoctés par d’aimables amateurs qui auraient mieux fait de s’occuper d’autres choses. Mais ceci est une autre histoire...

[mhoudas]

bonjour FMSREL,
Je vois que vous avez une grande expérience de DB2 après avoir utilisé les SGBD réseau. Avez-vous déjà utilisé une SGBDO et aujourd'hui feriez-vous l'effort que vous avez fait quand vous êtes passé du modèle réseau au modèle relationnel, êtes-vous pret à faire l'effort d'un apprentissage equivalent à l'apprentissage du langage SQL et des formes normales ?

J'ai travaillé chez des éditeurs de SGBD tant relationnel qu'objet pendant une dizaine d'années plus particulièrement au niveau moteur et architecture ce qui permet de comprendre ce qui se passe réellement derrière une requête SQL ou au travers d'un langage objet. La vision ensembliste est naturelle dans l'approche relationnelle au niveau d'un utilisateur mais ce n'est pas du tout celle qui faut avoir pour utiliser un SGBDO de façon efficace, il faut avoir une vision objet où autrement dit un modèle objet.

Je ne suis pas un partisant ou un ennemi des SGBDRs ou des SGBDOs. J'ai participé à de nombreux benchmarks clients au gré de ma carrière portant tour à tour les couleurs d'Oracle, d'IBM puis de Versant et d'O2 avant de revenir chez IBM. il n'y a pas un vainqueur définitif entre ces produits sur le plan des performances. Les SGBDOs ont toujours eu un avantage sur les modèles complexes (modèle de type graphe ou arborescence) avec souvent des rapports de 10 à 100 voir plus de 1000 par contre sur des modèles simples (la majorité des applications) la tendance peut être différente.

Oui les performances des SGBDRs augmentent mais essentiellement comme la puissance des serveurs qui les supportent cela est vrais pour tout les produits. logiciels

Enfin l'utilisation d'un SGBDO n'a de sens qu'associé à l'utilisation d'un langage objet tel que C++ ou Java. L'utilisation de SQL avec un SGBDO n'a aucun sens et l'absence d'un langage de requête objet standard (OQL) est un véritable problème qui limite surement l'utilisation des SGBDO (voir mon post précedent).


La taille des bases de données reposant sur un SGBDO est en général relativement faible (quelques GO) à l'exception des bases de données reposant sur Objectivity (archivage des données collectéres sur les acélerateurs de particule) où on arrive un volume de données de l'orde du peta-octet mais il s'agit là uniquement d'archivage, pour Versant la plus grosse base est une base de données d'empreintes digitales réalisé par SAGEM-Morpho (environ 600 GO) et pour O2 des bases de l'ordre de 8 GO pour une compagnie d'assurance suisse.

[fsmrel]

Bonsoir MHOUDAS,

Envoyé par mhoudas

Avez-vous déjà utilisé une SGBDO et aujourd'hui feriez-vous l'effort que vous avez fait quand vous êtes passé du modèle réseau au modèle relationnel, êtes-vous pret à faire l'effort d'un apprentissage equivalent à l'apprentissage du langage SQL et des formes normales ?

Désolé, je n’ai pas utilisé de SGBDO et j’avoue que je n’aurai plus le courage de me lancer dans l’apprentissage d’un SGBD de quelque type que soit, de plonger dans C++ ou Java. J’ai commencé par l’assembleur bien mis en oeuvre le triplet Seek/Search/TIC, le Rotational Positioning Sensing (si vous êtes chez IBM, ça doit vous causer), pour faire percuter l’accès aux données, à l’opposé je suis passé par Prolog, j’en suis arrivé à la table de cardinalité 1 et de degré 0 (une ligne et zéro colonne), maintenant je pose le sac (Au passage, j’ai réécrit TOTAL il y a un peu plus de trente ans, pour le compte un client qui trouvait que son SGBD n’allait pas assez vite...)

Concernant SQL, l’effort ne fut pas bien grand, car une fois qu’on a compris le Modèle Relationnel de Données, cet avatar qu’est SQL s’apprend facilement, à ceci près qu’il est agaçant, qu’il a un comportement parfois bizarre et que je m’en méfie. SQL n’est pas le relationnel et comme je l’ai écrit dans un précédent message, c’est un monstre mais qui a un bon fond. En passant, il a un tas de petits côtés énervants : par exemple pourquoi code-t-on dans l’ordre :

SELECT
FROM
WHERE

alors qu’en toute logique, si on y réfléchit, la ligne SELECT est la projection finale du résultat et que l’on devrait écrire :

FROM
WHERE
SELECT

(Dommage que SQL ait avalé Quel et ISBL, autrement mieux conçus). En termes d’effort, c’est surtout la théorie relationnelle qui mérite que l’on transpire, qu’il s’agisse de la partie structurelle, de la partie manipulation ou de la partie intégrité. Pour être certain que l’on a compris cette théorie, on doit pouvoir expliquer la définition formelle du Modèle relationnel qui repose sur cinq composants :

1. Une collection non limitée de types scalaires (dont le type Booléen).
2. Un générateur de type Relation et l’interprétation attendue des types de relations générés par ce moyen.
3. Les mécanismes pour définir des variables relationnelles du type de relation voulu.
4. L’opération d’affectation relationnelle permettant d’affecter des valeurs à ces variables.
5. Une collection non limitée d’opérateurs relationnels génériques, pour produire des valeurs de type relation à partir d’autres valeurs de type relation.

Je ne fournis pas la réponse ici, car il est plus profitable que chacun creuse le sujet et transpire à son tour.

Vous évoquez les formes normales : je dirai qu’elles ne sont pas l’exclusivité du Modèle Relationnel de Données. Certes, ce sont des mathématiciens, des théoriciens du relationnel qui se sont préoccupé du sujet : Ted Codd, Raymond Boyce, Jorma Rissanen et last but not least Ronald Fagin (qui a démontré que par le mécanisme de projection/jointure sans perte, on ne pouvait aller au-delà de la 5NF (ou PJ/NF), que l’on aurait dû appeler FNF pour Fagin Normal Form, mais le garçon est un modeste). Cela dit, ce qui vaut pour une table vaut pour une entité-type, une association-type, une classe, à la limite pour un record, un fichier : toutes choses dotées d’attributs (ou propriétés, au choix). Et l'on sait les riques que l'on encourt à se passer de la normalisation.

il faut avoir une vision objet où autrement dit un modèle objet.

Qu’est-ce qu’une vision objet ? Existe-t-il une définition formelle du Modèle objet qui tienne en quelques lignes, comme celle que j’ai fournie du Modèle relationnel (et que l'on doit à Chris Date) ? Si vous avez cela en magasin, je suis preneur !

Les performances des SGBDRs augmentent mais essentiellement comme la puissance des serveurs qui les supportent

Il est évident que passer d’une machine de 90 mips à une machine de 900 mips est bon pour la performance des applications. Mais le gain est loin d’être linéaire. Si on est IO/Bound, on risque d’être déçu d’avoir investi beaucoup d’heuros pour un rendement qui peut être médiocre... A quoi bon une puissance CPU permettant de battre le record du nombre de décimales calculées de PI si c’est pour qu’elle ait un faible rendement, à cause de tombereaux d’entrées/sorties ? C’est là qu’est le défi, réduire drastiquement ces E/S et la conjugaison de l’identification relative au niveau conceptuel, de la normalisation, d’une bonne connaissance de l’algèbre relationnelle et du métabolisme des données, des index clusters (au sens DB2 du terme) et du partitionnement, est un facteur décisif pour la performance. Le mariage de raison de la sémantique et de la tuyauterie peut donner de beaux fruits.

La taille des bases de données reposant sur un SGBDO est en général relativement faible

J’en reste aux SGBDR car comme je l’ai dit, je les ai bien secoués (au moins l’un d’entre eux...) et n’ai jamais été déçu. Mais leur pratique sans connaissance profonde du Modèle relationnel peut être très délicate. Grâce à celui-ci, j’ai pu aider les concepteurs à produire des MCD de deux mille entités-types avec des tables dépassant les cent millions de lignes, et ça tourne comme une horloge en production. Bien sûr il y a des petits problèmes par-ci par-là, mais rien de méchant. Sans cette connaissance profonde du Modèle relationnel je ne sais pas où j’aurais été nager et avec quelle rapidité on m’aurait flanqué à la porte.

[begooden-it]

Je déterre ce post et présente mes plus plates excuses pour ce fait, mais je trouve très marrant que personne ne parle d'Informix dans toute cette discussion :-)
Parti pris, oubli volontaire, oubli involontaire ou méconnaissance ?