Publicité
+ Répondre à la discussion
Page 1 sur 2 12 DernièreDernière
Affichage des résultats 1 à 20 sur 27
  1. #1
    Membre habitué
    Inscrit en
    avril 2005
    Messages
    206
    Détails du profil
    Informations forums :
    Inscription : avril 2005
    Messages : 206
    Points : 103
    Points
    103

    Par défaut Grosse base de données et performances

    Bonjour

    Question de noob en grosses bases de données…

    Admettons une base avec une table de 1 500 000 enregistrements de 30 ko chacun (il est possible qu’à l’avenir cela soit multiplié par 10). Les PC clients doivent se connecter dessus périodiquement pour chercher des enregistrements à traiter, par exemple 1000 enregistrements non traités. Quand ils font cela, ils marquent l’enregistrement comme en traitement, avec la date et l’heure de début. Quand ils ont fini de traiter leurs 1000 enregistrements, ils les mettent à jour dans la base centrale puis en redemandent 1000, jusqu’à ce que la totalité des documents soient traités.

    Sachant que 30 clients peuvent travailler en même temps, que les clients ne doivent jamais être interrompus parce que le serveur ne suit plus, et que les clients traitent environ trois enregistrements par secondes, cela nous fait 30 connections qui peuvent être simultanées, et que le serveur envoie grosso modo 90 enregistrement par secondes en moyenne, 3 par 3 sur vers chaque client (en moyenne).

    Alors voici ma question de débutant avec de grosses bases. Est-ce que c’est envisageable avec les bases actuelles ? Elles font cela et beaucoup mieux les doigts dans le nez ? Ou bien est-ce que certaines bases sont plus aptes à le faire que d’autres ?

    Merci

  2. #2
    Expert Confirmé Sénior
    Avatar de fsmrel
    Homme Profil pro François de Sainte Marie
    Spécialiste en bases de données
    Inscrit en
    septembre 2006
    Messages
    4 662
    Détails du profil
    Informations personnelles :
    Nom : Homme François de Sainte Marie
    Localisation : Autre

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : septembre 2006
    Messages : 4 662
    Points : 12 439
    Points
    12 439

    Par défaut Des sacs de patates

    Bonjour Promeneur,

    Votre question est très générale. Je ferai une observation : si chaque ligne de la table mesure 30 KO et si le serveur envoie 90 lignes par seconde, cela nous fait globalement 2,7 MO transférés à la seconde. Chaque PC client traite 3 lignes à la seconde donc 8 MO/seconde...

    Ces chiffres sont-ils bien raisonnables ? En admettant que les connexions soient soulagées du fait d’une compression des données, au final cela fait quand même beaucoup (et vous évoquez une multiplication par 10 de ces chiffres...)

    Vous parlez de documents, mais quels types de données stockez-vous ? Des images ? des chaînes de caractères et des nombres ?

    Dans le premier cas, de fait, 30 KO pour une donnée élémentaire est raisonnable.

    Dans le second cas, quand une ligne dépasse une centaine d’octets, on regarde de près la table pour voir s’il y a lieu de la normaliser (disons 3e forme normale), c’est-à-dire d’en faire plusieurs petites tables de taille raisonnable.

    Sur ces 30 KO, combien méritent d’encombrer les connexions ? Autrement dit, combien ont vraiment besoin d’être transférés à destination des PC pour être effectivement lus (et mis à jour le cas échéant) par l’utilisateur final (humain ou programme) ? Pardonnez-moi, mais n’y a-t-il pas un peu de gabegie ? J’ai le sentiment que pour éplucher trois pommes de terre, on s’échange le sac complet...
    Faites simple, mais pas plus simple ! (A. Einstein)
    E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)


    De grâce, pas de questions techniques par MP, ma boîte de réception explose !
    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale (Bonne lecture !)

  3. #3
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro Frédéric BROUARD
    Expert SGBDR & SQL
    Inscrit en
    mai 2002
    Messages
    13 362
    Détails du profil
    Informations personnelles :
    Nom : Homme Frédéric BROUARD
    Localisation : France

    Informations professionnelles :
    Activité : Expert SGBDR & SQL
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 13 362
    Points : 27 472
    Points
    27 472

    Par défaut

    LA notion d'enregistrement n'existe pas dans les SGBDR. ON parle de ligne car les donées sont écrite sur le disque par paquet qui n'ont heureusement rien à voir avec la ligne.

    1 500 000 lignes cela ne veut rien dire... SI votre ligne ne comporte qu'une seule donées, mettons un entier (soit 4 octets) cela fait un volume de 6 Mo. AUtrement dit même une simple carte mémoire stick de la génération 1912.. SUfit à traiter votre base !

    Un peu plus de précision serait donc bienvenu !

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Blog SQL, SQL Server, modélisation données : http://blog.developpez.com/sqlpro
    http://www.sqlspot.com : modélisation, conseils, audit, optimisation, formation
    * * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *

  4. #4
    Membre habitué
    Inscrit en
    avril 2005
    Messages
    206
    Détails du profil
    Informations forums :
    Inscription : avril 2005
    Messages : 206
    Points : 103
    Points
    103

    Par défaut

    Salut et merci de votre temps.

    Comme je l'ai dit, chaque "ligne" pèse environ 30 ko. Quelques champs classiques (textes, date/heure, logiques) et une image. Malheureusement, toutes ces données sont nécessaires au client... Cela fait un fort volume. Actuellement, sans passer par client serveur, on fait quelque chose comme cela avec des connexions TC/IP, sur un prototype, et 30 clients. Mais je voudrais examiner plusieurs solutions, y compris une liaison client serveur classique.

  5. #5
    Membre Expert
    Homme Profil pro Stéphane
    Inscrit en
    novembre 2005
    Messages
    1 901
    Détails du profil
    Informations personnelles :
    Nom : Homme Stéphane
    Localisation : France

    Informations forums :
    Inscription : novembre 2005
    Messages : 1 901
    Points : 2 062
    Points
    2 062

    Par défaut

    Indépendamment du SGBDR, le débit réseau sera primordial pour votre besoin.

  6. #6
    Membre habitué
    Inscrit en
    avril 2005
    Messages
    206
    Détails du profil
    Informations forums :
    Inscription : avril 2005
    Messages : 206
    Points : 103
    Points
    103

    Par défaut

    Citation Envoyé par kuzco
    Indépendamment du SGBDR, le débit réseau sera primordial pour votre besoin.
    Partons de l'hypothèse que l'infrastructure matérielle sera adaptée à nos besoins.

  7. #7
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro Frédéric BROUARD
    Expert SGBDR & SQL
    Inscrit en
    mai 2002
    Messages
    13 362
    Détails du profil
    Informations personnelles :
    Nom : Homme Frédéric BROUARD
    Localisation : France

    Informations professionnelles :
    Activité : Expert SGBDR & SQL
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 13 362
    Points : 27 472
    Points
    27 472

    Par défaut

    SI vous voulez des performances il est préférable de ne pas mettre d'images et en général tous type d'objet se traduisant in fine en fichier dans une base de donées :
    - vous augmentez artificiellement le volume des données à manipuler dans la base
    - les BLOBS doivet être réinstancié sous forme de fichiers.

    Donc prévoyez plutôt de les stocker dans un serveur de fichier.

    LIsez l'article que j'ai écrit à ce sujet :
    http://sqlpro.developpez.com/cours/stockerimages/

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Blog SQL, SQL Server, modélisation données : http://blog.developpez.com/sqlpro
    http://www.sqlspot.com : modélisation, conseils, audit, optimisation, formation
    * * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *

  8. #8
    Membre habitué
    Inscrit en
    avril 2005
    Messages
    206
    Détails du profil
    Informations forums :
    Inscription : avril 2005
    Messages : 206
    Points : 103
    Points
    103

    Par défaut

    Citation Envoyé par SQLpro
    Donc prévoyez plutôt de les stocker dans un serveur de fichier.

    LIsez l'article que j'ai écrit à ce sujet :
    http://sqlpro.developpez.com/cours/stockerimages/
    Très intéressant article, SQLpro, merci !

  9. #9
    Expert Confirmé Sénior
    Profil pro
    Développeur informatique
    Inscrit en
    novembre 2006
    Messages
    4 859
    Détails du profil
    Informations personnelles :
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : novembre 2006
    Messages : 4 859
    Points : 6 293
    Points
    6 293

    Par défaut

    Attention il ne faut pas seulement prendre en compte la taille de la BDD; mais aussi la manière dont les traitements via requêtes SQL sont effectués.
    Il va s'en dire que par exemple plus on délégue au moteur de BDD les traitements ( procédures stockées...) plus les performances seront accrues

  10. #10
    Membre Expert
    Profil pro
    Inscrit en
    mars 2005
    Messages
    1 682
    Détails du profil
    Informations personnelles :
    Âge : 32
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations forums :
    Inscription : mars 2005
    Messages : 1 682
    Points : 2 329
    Points
    2 329

    Par défaut

    Citation Envoyé par SQLpro
    SI vous voulez des performances il est préférable de ne pas mettre d'images et en général tous type d'objet se traduisant in fine en fichier dans une base de donées :
    - vous augmentez artificiellement le volume des données à manipuler dans la base
    - les BLOBS doivet être réinstancié sous forme de fichiers.

    Donc prévoyez plutôt de les stocker dans un serveur de fichier.

    LIsez l'article que j'ai écrit à ce sujet :
    http://sqlpro.developpez.com/cours/stockerimages/

    A +
    Que pensez-vous de l'utilisation du partitionnement (vertical et/ou horizontal) afin de conserver l'homogénéïté qu'apporte l'utilisation des blobs et de résoudre une partie des problèmes de performance qu'ils peuvent engendrer ?

    Votre article traite d'une des solutions possibles (traiter des liens vers un système de fichier) et j'aurais avoir des avis sur cette autre approche.

  11. #11
    Membre du Club
    Profil pro
    Inscrit en
    septembre 2005
    Messages
    73
    Détails du profil
    Informations personnelles :
    Âge : 37
    Localisation : France, Nord (Nord Pas de Calais)

    Informations forums :
    Inscription : septembre 2005
    Messages : 73
    Points : 50
    Points
    50

    Par défaut

    Avez-vous penser à l'utilisation d'un SGBDO ?

    Un SGBDO travaille sur des transactions longues en utilisant le cache côté client.
    Le client peut ainsi récupérer 1000 enregistements, les travailler localement sur sa machine tout en ayant sécuriser les enregistrements (gestion concurrence, transactions, ...) et renvoyer le paquet au serveur une fois le traitement effectué.

    Les SGBDOs permettent justement ce type de traitement et sont adaptés aux transactions longues de gros paquets de données.

    En fonction du contexte, peut-être une piste à explorer ?

  12. #12
    Expert Confirmé Sénior
    Avatar de fsmrel
    Homme Profil pro François de Sainte Marie
    Spécialiste en bases de données
    Inscrit en
    septembre 2006
    Messages
    4 662
    Détails du profil
    Informations personnelles :
    Nom : Homme François de Sainte Marie
    Localisation : Autre

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : septembre 2006
    Messages : 4 662
    Points : 12 439
    Points
    12 439

    Par défaut

    Citation Envoyé par GyLes
    Un SGBDO travaille sur des transactions longues en utilisant le cache côté client.
    C'est très bien. Mais comment fait-on s'il faut, côté serveur, une heure au SGBDO pour collecter les données à destination du client ? Sans parler du temps qu'il doit consacrer aux mises à jour...

    Puisque le thème de la discussion est "Grosse base de données et performances", je m'intéresse évidemment ici à des bases de données composées de tables (ou équivalent) dont certaines ont une volumétrie dépassant les cent millions de lignes (pour en moyenne une centaine d'octets par ligne).
    Faites simple, mais pas plus simple ! (A. Einstein)
    E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)


    De grâce, pas de questions techniques par MP, ma boîte de réception explose !
    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale (Bonne lecture !)

  13. #13
    Membre du Club
    Profil pro
    Inscrit en
    septembre 2005
    Messages
    73
    Détails du profil
    Informations personnelles :
    Âge : 37
    Localisation : France, Nord (Nord Pas de Calais)

    Informations forums :
    Inscription : septembre 2005
    Messages : 73
    Points : 50
    Points
    50

    Par défaut

    Vous sous-estimez les SGBDOs pour leur donner une heure pour récupérer 1000 enregistrements. Une base de données est un conteneur de données, pas forcément sous forme de table.

    Les SGBDOs sont optimisés pour des applications d'ingénierie. Le traitement de gros plans de milliers de pièces est un exemple.

  14. #14
    Expert Confirmé Sénior
    Avatar de fsmrel
    Homme Profil pro François de Sainte Marie
    Spécialiste en bases de données
    Inscrit en
    septembre 2006
    Messages
    4 662
    Détails du profil
    Informations personnelles :
    Nom : Homme François de Sainte Marie
    Localisation : Autre

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : septembre 2006
    Messages : 4 662
    Points : 12 439
    Points
    12 439

    Par défaut

    Bonsoir GyLes,

    Vous écrivez :
    Vous sous-estimez les SGBDOs pour leur donner une heure pour récupérer 1000 enregistrements
    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 ! — quand recueillir un, dix, mille ou un million d’enregistrements implique de balayer dans tous les sens des espaces-disques gigantesques, avec des entrées-sorties à l’infini. Les 1000 enregistrements que vous évoquez correspondent pour moi non pas à 1000 accès (disque ou mémoire) mais au résultat disons d’une requête au sens relationnel du terme, ayant nécessité 10 exp N accès physiques, N pouvant varier entre 2 et 18... Peut-être n’avons-nous pas la même perception du mode de recueil des données : je ne recherche pas moi-même les 1000 enregistrements un par un, je demande au système relationnel, par le biais de cette requête, de me fournir un résultat qui soit une table (au nom du principe de fermeture) et dont j’extrairai finalement chacune des 1000 lignes, par exemple pour les transmettre à un autre traitement qui ne manipule pas de tables ou pour les imprimer, etc.

    J’ai passé énormément de temps dans les entreprises à rendre performantes des applications utilisant des SGBDR, souvent en catastrophe, avec une casquette "docteur des bases" (sic). Autant on a peu de surprises avec un SGBD pré-relationnel en termes de performances (je l’ai vérifié pendant des années), autant avec un SGBDR, si l’on n’a pas modélisé correctement, c’est généralement la catastrophe et c’est rédhibitoire quand le projet revêt une certaine ampleur. Et si l’on a modélisé correctement, il reste à procéder à certains réglages (réorganisations, choix des index, mise à jour des statistiques du catalogue relationnel, campagnes dites d’explain) pour obtenir des temps de réponse et des durées de traitements batch satisfaisants, répondant au cahier des charges ayant conduit à bâtir des prototypes de performance et toutes ces sortes de choses. Si l’on ne procède pas à ces réglages, les temps de traitement peuvent être infinis (généralement pour cause de produits cartésiens), mais au contraire, si le DBA a fait son travail, on est souvent impressionné par la vitesse à laquelle les résultats sont obtenus (« Chef ! ça va trop vite, il doit y avoir une erreur ! »).

    Concernant les SGBDO, il ne m’a pas été donné l’occasion de les chahuter, contrairement aux autres SGBD et je le regrette vivement. Une question : avec un SGBDO, la performance d’un traitement est-elle relativement facile à prévoir, ou bien faut-il mettre en oeuvre, comme dans le cas des SGBDR, des réglages minutieux pour éviter que les temps de traitement tendent vers l’infini ?


    Les SGBDOs sont optimisés pour des applications d'ingénierie. Le traitement de gros plans de milliers de pièces est un exemple
    Je vous l’accorde bien volontiers. J’ai échangé il y a une douzaine d’années avec quelqu’un qui faisait dans l’accidentologie et utilisait un SGBDO : cette personne était emballée car si le sujet n’était pas simple, son SGBD lui était d’une aide essentielle et elle ne jurait que par lui. Elle traitait environ 30000 objets complexes et je pense que je n’aurais pas été capable de les manipuler avec mon SGBDR "généraliste", lequel ne permettait pas que l’on définisse ses propres types (classes).

    Pour ma part, je suis plus habitué à des thèmes relativement simples, disons orientés "gestion". Les volumes sont souvent énormes. Imaginez par exemple, chez tel ou tel opérateur, la collecte ad nauseam des trames téléphoniques, de structure simple, mais qui se présentent par millions tous les soirs déversés par les autocommutateurs et qu’il faut exploiter au plus tôt (les nuits sont courtes...) Songez encore aux 40 années de cotisation des adhérents qu’il faut conserver (en ligne) dans les caisses de retraite, etc. Les traitements sont évidemment beaucoup plus simples par rapport à ceux qui se rapportent à l’accidentologie ou aux plans que vous évoquez, mais il y a quand même des problèmes non triviaux qui se posent en relation, par exemple, avec la prise en compte du temps, ou tout simplement avec des aspects algorithmiques que l’on peut fort heureusement sous-traiter au SGBDR (ne serait-ce que ceux, basiques, relevant des "appareillages de fichiers") qui se révèle être un algébriste, un analyste et un développeur sans pareil.

    Je ne cherche pas à critiquer pour critiquer, ainsi les concepts OO de classe et d’héritage sont essentiels et manquaient au Modèle relationnel d’origine qui s’appuyait sur des types simples, parce qu’à l’époque cela suffisait. Depuis, on a assisté à une certaine évolution. Évidemment, quand il y a 20 ans, le professeur Gardarin et ses collègues ont créé Sabrina, ils ne pouvaient se contenter de types simples, alors que leur système était un système de gestion de bases de données relationnelles. S’ils avaient entrepris leurs travaux dix ans plus tard le qualificatif orienté objet eût à coup sûr remplacé celui de relationnel.

    En revanche, je reste dubitatif concernant l’apport du concept d’OID. Au niveau physique, L’OID permet-il par exemple de minimiser l’effet I/O bound, en regard des 10 exp N accès disque possibles, quand N prend une valeur importante ? Au niveau conceptuel, dispense-t-il de définir des clés candidates, permettant entre autres à l’utilisateur d’accéder à un objet en particulier ?

    J'ai vu que vous aviez répondu à un autre message. Je ne manquerai pas de l'étudier. Sans doute des questions-réponses s’entrechoquent-elles, mais ça n'est pas bien grave...
    Faites simple, mais pas plus simple ! (A. Einstein)
    E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)


    De grâce, pas de questions techniques par MP, ma boîte de réception explose !
    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale (Bonne lecture !)

  15. #15
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro Frédéric BROUARD
    Expert SGBDR & SQL
    Inscrit en
    mai 2002
    Messages
    13 362
    Détails du profil
    Informations personnelles :
    Nom : Homme Frédéric BROUARD
    Localisation : France

    Informations professionnelles :
    Activité : Expert SGBDR & SQL
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 13 362
    Points : 27 472
    Points
    27 472

    Par défaut

    Force est quand même de constater que les SGBDO ont quasiment disparus au profit des SGBDR en raison justement des mauvais performances générales des SGBDO...
    De même les langages purement objet (SmallTalk en est un bon exemple) on fait un flop, car on fait plus d'aditions basiques que d'opérations sur des objets dans la plupart des traitements.
    C'est pourquoi aujourd'hui les SGBDR comportent une petite partie O afin de satisfaire les deux mondes sans perdre de vue le point essentiel, la performance face aux volume des données.

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Blog SQL, SQL Server, modélisation données : http://blog.developpez.com/sqlpro
    http://www.sqlspot.com : modélisation, conseils, audit, optimisation, formation
    * * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *

  16. #16
    Membre du Club
    Profil pro
    Inscrit en
    septembre 2005
    Messages
    73
    Détails du profil
    Informations personnelles :
    Âge : 37
    Localisation : France, Nord (Nord Pas de Calais)

    Informations forums :
    Inscription : septembre 2005
    Messages : 73
    Points : 50
    Points
    50

    Par défaut

    Les SGBDOs offrent des mécanismes d'optimisation qui leurs sont propres. Le regroupement de données en est un exemple, permettant d'optimiser l'emplacement des objets en relations les uns avec les autres dans un espace disque proche. Les problématiques de conception restent les même que dans un SGBDR. Le SGBDO ne connaît pas la sémantique des données/objets contenus dans la base. C'est au développeur de lui donner la sémantique et le paramétrage/développement nécessaire à l'optimisation tout comme dans les SGBDR pour la création des index. C'est par exemple le cas pour le regroupement.

    L'OID et les techniques d'optimisation, de génération de ces OIDs offrent de très bonnes performances. Il existe différentes implémentation de ces OIDs et diverses avantages / inconvénient liés. Les bases de données réparties est un exemple de l'avantage des OIDs. Un SGBDO sait concaténer l'identifiant d'une machine réseau à un OID, permettant ainsi à l'objet de voyager sur le réseau de machine en machine et de manière transparente pour l'utilisateur.
    Un OID unique, un OID suppléant, un OID avec identification du type, vont offrir des performances différentes mais des fonctionnalités supplémentaires.

    Les techniques de swizzling permettant de convertir les OIDs en pointeurs mémoires permettent à un ensemble d'objets en relation d'être vus comme une structure de données en langage C (uniquement des pointeurs mémoires, et donc pas de traitements supplémentaires).


    Concernant les performances, les benchmarks OO1 puis OO7, et enfin le produit open source polepos (sur sourceforge) offrent des analyses de performances entre un SGBDR, SGBDO, SGBDRO et mapping, selon le type de requêtes et le type d'application que l'on en fait.

    Objectivity, Object Store, Versant, Matisse, Caché, db4o, .... sont autant de SGBDO qui font vivre leurs sociétés. Db4o offre d'ailleurs un intérêt accru vue le nombre de publications sur le net et dans les magasines.

    Je ne pense pas que les SGBDOs soient "presque" disparus. On les attendait peut-être sur un domaine qui n'est pas forcément le leur. Un SGBDR restera toujours (je pense) bien plus performant qu'un SGBDO en terme de traitement de transactions courtes et rapides.

    Un point sur lequel je m'étais focalisé au début de mes recherches, je pensais que les SGBDOs étaient la solution pour l'aspect dysfonctionnement des langages. Nous parlons des performances d'un SGBDR, performances brutes lors de traitement par procédures stockées sur le serveur. Quand est-il des problématiques de plus en plus courantes de l'utilisation d'un langage objet couplé à un SGBDR, et des dysfonctionnements des deux langages nécessitant de fortes conversion de types de données, et des mapping entre deux mondes très différents (objets et tables) qui diminuent fortement les performances globales, donc performance de l'application, qui est finale la plus importante car visible par l'utilisateur. Que faire d'un SGBDR qui peut répondre en un minimum de temps à une requêtes si il faut derrière moultes traitements, conversion de données pour offrir l'information finale à l'utilisateur ?

    Le début de succès de Db4o me donne l'impression qu'il a su très bien se positionner sur cette problématique: Développez en OO sans les problèmes de mapping Hibernate, JDO ou autres. Pas de problèmes de dysfonctionnement, langage de programmation auquel on a ajouté les principes d'une base de données (transactions, concurrence, langage de requêtes, relations, intégrité référentielle, ...). Db4o par contre n'offre pas pour l'instant tous les avantages d'un SGBDR. Mais pourquoi comparer ? Un SGBDO répond à une problématique, propre pour l'instant aux applicatins d'ingénierie (mécanique, électronique, aéronotique), aux applications bureautiques, aux applications embarquées (exemple de BMW).

    Je ne crois pas pour l'instant dans un produit unique qui sache résoudre les problématiques solutionnées par les SGBDR et les SGBDOs, et ne crois pas non plus qu'un SGBDO remplacera un jour un SGBDR dans le domaine des applications de gestion classique.


    Pas de mauvaise critique, pas de soucis, mais un bon topic permettant de confronter les idées de chacun et de lever certaines idées reçus aussi

  17. #17
    Expert Confirmé Sénior
    Avatar de fsmrel
    Homme Profil pro François de Sainte Marie
    Spécialiste en bases de données
    Inscrit en
    septembre 2006
    Messages
    4 662
    Détails du profil
    Informations personnelles :
    Nom : Homme François de Sainte Marie
    Localisation : Autre

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : septembre 2006
    Messages : 4 662
    Points : 12 439
    Points
    12 439

    Par défaut

    Un SGBDR restera toujours (je pense) bien plus performant qu'un SGBDO en terme de traitement de transactions courtes et rapides.
    Pour des transactions lourdes correctement réglées (par exemple impliquant un parcours récursif de nomenclatures de centaines de milliers de lignes), un SGBDR comme Oracle ou DB2 peut aussi être redoutable. Même chose pour les batchs exploitant des tables dont la volumétrie dépasse les cent millions de lignes.

    Quant au dysfonctionnement des langages, parce que les applications de gestion manipulent des structures simples, sous forme de tuples, la conversion ne coûte pas cher : personnellement se sont les entrées/sorties qui ont toujours sollicité mon attention (en relation avec ce que j’ai écrit dans le précédent paragraphe). Mes collègues DBA devraient confirmer.
    Faites simple, mais pas plus simple ! (A. Einstein)
    E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)


    De grâce, pas de questions techniques par MP, ma boîte de réception explose !
    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale (Bonne lecture !)

  18. #18
    Membre du Club
    Profil pro
    Inscrit en
    septembre 2005
    Messages
    73
    Détails du profil
    Informations personnelles :
    Âge : 37
    Localisation : France, Nord (Nord Pas de Calais)

    Informations forums :
    Inscription : septembre 2005
    Messages : 73
    Points : 50
    Points
    50

    Par défaut

    La conversion entre les deux mondes Relationnel / Objet coûte très cher. Les mappeurs comme Hibernate consomme un temps de traitement non négligeable (problématique de l'impedance mismatch).

    Je ne parle naturellement pas des batchs de traitements directement exécutés sur le serveur de données par exemple, mais bien des applications avec interface utilisateur interrogeant la base de données. Nombre d'applications utilisent aujourd'hui des langages objets (Java, .Net, ...) avec une base de données relationnelle. La conversion entre ces deux mondes passent par un mappeur comme hibernate. C'est ici qu'intervient une partie de perte de performance.

    Le SGBDO intègre directement le langage de programmation natif (pas de modification du langage hôte, C, Java, .Net) et les concepts de bases de données. Pas de problème de dysfonctionnement des langages, pas de problématique d'impedance mismatch.

    Pour revenir sur l'optimisation des SGBDOs, le SGBDO offre deux moyens d'accéder aux données de la base. Via un langage de manipulation de données (OML selon la norme ODMG), ou via un langage de requêtes non procédurale OQL.

    OQL est capable de réaliser l'équivalent de la jointure relationnelle. Les valeurs de jointures (valeurs de champs) sont remplacées par des pointeurs. Le principe reste cependant le même.

    L'optimiseur d'un SGBDO est par contre bien plus complexe que l'optimiseur d'un SGBDR. Il doit prendre en compte les nouveaux types créés par l'utilisateur, les nouvelles opérations de comparaison propre aux types de données nouvellement définis, des méthodes spécifiques, ... sans compter les nombreuses possibilités d'accéder à la même données via le parcours de chemins, il faut aussi prendre en compte les collections, les structures de données.

    Plusieurs mécanismes permettent l'optimisation des SGBDOS:
    - Index classiques
    - Regroupement d'objets
    - Objets liés ou encastrés
    - Index de chemins
    - Index de collections
    - Modèle d'évaluation des méthodes utilisateurs

    L'optimiseur se base sur le même principe qu'un optimiseur en relationnel:
    1. Générations de plans équivalents utilisant des statistiques
    2. Stratégie de recherche du meilleur plan (algorithme combinatoire itérative, du recuit simulé, optimisation en deux phases, recherche taboue, algorithme génétique ...


    Ci-dessous un petit lien sur les résultats donnés par Polepos, le framework de benchmark pour les bases de données.
    http://polepos.sourceforge.net/results/html/index.html

    Les résultats permettent de comparer les actions de création, suppression et de lecture d'objets non structurés, structurés, en arbre, ....

    Les SGBDOs restent dans la course, ils ont leur marché de niche. Un petit lien sur les success stories de Objectivity, pour ne citer que celui ci:
    http://www.objectivity.com/pages/dow...essstories.asp

  19. #19
    Membre du Club
    Profil pro
    Inscrit en
    septembre 2005
    Messages
    73
    Détails du profil
    Informations personnelles :
    Âge : 37
    Localisation : France, Nord (Nord Pas de Calais)

    Informations forums :
    Inscription : septembre 2005
    Messages : 73
    Points : 50
    Points
    50

    Par défaut

    Un petit lien sur le site de Caché Expert concernant une étude de KLAS sur les bases de données utilisées dans le milieu médical:

    http://www.cache-expert.com/docs/klas-intersystems.pdf

  20. #20
    Expert Confirmé Sénior
    Avatar de fsmrel
    Homme Profil pro François de Sainte Marie
    Spécialiste en bases de données
    Inscrit en
    septembre 2006
    Messages
    4 662
    Détails du profil
    Informations personnelles :
    Nom : Homme François de Sainte Marie
    Localisation : Autre

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : septembre 2006
    Messages : 4 662
    Points : 12 439
    Points
    12 439

    Par défaut

    Un petit lien sur le site de Caché Expert concernant une étude de KLAS sur les bases de données utilisées dans le milieu médical
    J'ai déjà assisté à ce genre de film. Que voulez-vous que je pense de la pertinence d'un article mettant en comparaison deux systèmes, signé par le fournisseur de l'un d'eux, qui s'avère comme par hasard le meilleur ? Je suis un technicien, pas un commercial.

    Le sondeur ne compare pas des SGBD mais des applications, puisqu'il s'adresse aux utilisateurs. Ceux-ci connaissent le domaine de la santé, point barre. Quand ils disent que leur base de données est tombée en panne, ils parlent en réalité de leur application, puisqu'ils n'ont pas la connaissance de ce qui se trouve sous le capot. Que les applications soient à mettre au point, certes, mais si Oracle tombait aussi souvent en panne, ça se saurait.

    Selon l'article : "Le sondage de KLAS comportait plusieurs questions destinées à mesurer la complexité de l’utilisation des applications sur les sites de gestion des dossiers médicaux".

    Sont-ce les programmes ou les SGBD qui sont en cause ? Et même s'il s'agissait des SGBD, étaient-ils correctement réglés, les tables normalisées ? Etc.

    On amalgame et on file vers le sophisme.

    Ces gens auraient fait leur sondage chez des utilisateurs exclusivement d'un des deux SGBD, en les répartissant en deux groupes, je suppose que les points auraient été attribués dans les mêmes proportions et donc que le SGBD serait meilleur que lui-même.
    Faites simple, mais pas plus simple ! (A. Einstein)
    E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)


    De grâce, pas de questions techniques par MP, ma boîte de réception explose !
    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale (Bonne lecture !)

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •