Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Avenir des bases de données relationnelles ?
Bonjour a tous,
Je viens de lire un article : ""La fin des bases de données relationnelles"" en page 26 du 01 Informatique N°1821 du 30 Juin 2005 qui expliquer en fait que les bases de données relationnelles était le point faible des architectures à plusieurs niveaux et que donc, elle devrait dans une futur proche disparaitre pour laisser place aux serveurs d'applications.
Voila j'aimerais savoir ce que vous en pensiez ?
Bob
Un serveur d'applications pour remplacer une base de données ?
Il y a quelque chose que je ne comprends pas.
bah ecoute c'est pourtant ce que j'ai lu hier dans un magazine plutot réputé !
je te cite un passage du magazine:
Mais alors, si la base de données disparaît, qui prend le relais? Les serveurs d'applications bien sûr.
Et ce magazine expliquerait-il de quelle manière il compte s'y prendre par hasard ?
Pour info : base de données = conteneur de données et serveur d'application = interpréteur centraliser pour applications distribuées qui accédent aux données... j'ai du mal à voir comment le 2° peut remplacer le 1°
Mon doyen disait toujours : "les bons infomaticiens n'ont pas le temps d'écrire de bons livres..."
Un + pour lui !
... ce genre d'article, c'est tout juste bon à se faire mousser... d'ailleurs la preuve : on mousse tous
Le jour ou l'on transférera le SGBDR dans le serveur applicatif, on se retrouvera en architecture 2 couches, qui ressemblera étrangement à ... du client-serveur, celle-là même que l'on a quittée.
Tout cela n'est qu'une question de pouvoir : on voulait se départir des édieurs SGBDR avec le modèle à 3 couches, on se retrouve lié à l'éditeur du 2e tiers maintenant, et celui-ci essaie de tout réintégrer ???
Ou bien celà ne sous entend -t-il pas une structure particulière ?
Bon en faite cet article fait parti de la rubrique "Idée", ce ne sont que la pensée d'un directeur informatique, qui à l'air de connaitre son truc, mais en aucun cas le discours d'un ténor du milieu.
Il explique juste que pour l'instant les données s'interface comme ceci :
Relationnelle (SGBDR) - Objet (couche applicative)
Objet (couche applicative) - Représentation tabulaire (couche IHM)
Et que la solution logique serait de supprimer la notion centrale, mais là on revient au C/S.
Lui propose plus ambitieux, la suppression du SGBD par le stockage des données dans des modèles objets.
Mais comme il le dit lui même "bien entendu, tout cela n'en est encore qu'au stade préhistorique"
donc effectivement le titre est raccoleur, mais le sujet intéressant.
Je suis l'auteur de l'article de 01
Bonjour à tous,
c'est un peu par hazard que je tombe sur ce thread.
Il ya comme une confusion dans l'interprétation que vous faites de ce papier.
En bref, je défend l'idée que les technologies de cache de données distribués tels que 'coherence' de la société tangosol, gigaspaces ou encore terracota vont - à terme - supplanter les traditionnels SGBD.
Il se trouve que ces middleware sont déployés de manière symétrique dans les conteneurs J2EE; c'est cela qui me permet de faire le raccourci en disant que le serveur d'application peut prétendre prendre le relais.
Si ce n'est toujours pas clair, n'hésitez pas à me le dire...et je veux bien défendre le titre de "ténor" avec qui vous voudrez
Laurent.
J'ai lu cet article au chiotte il y a quelques temps. Ca valait moins que les chiottes sur lesquels j'étais posé. Ce genre d'article est commis régulièrement par de jeunes rigolos qui n'ont aucun background en informatique et qui pensent que les "modes" informatique et en particulier celles très pointues techniquement, vont s'imposer et bouffer tout le reste.
C'est ce que l'on disait en 1980 de Cobol avec l'apparition des premiers SGBDR stables du genre IBM Db2, Oracle ou Sybase....
Force est de constater que les applications Cobols et les fichiers de données associées n'ont pas disparues et restent encore avec FORTRAN dans le calcul scientifique le moyen encore le plus rapide d'accès aux données !
En 1990, c'est sûr les SGBDR devait mourrir rapidement devant les SGBD objet (o² par exemple). Curieusement les SGBDOO sont agonisants et les SGBDR sont encore plus vivants que jamais. Ils ont simplement sût évolué et intégrent aujourd'hui une couche objet.
En 2000, c'est sûr, le stockage des données relationnelles était mort : le XML permetait mieux, plus et bien plus standard !!!
Sauf qu'encore une fois les SGBDR ont évolués et intègrent maintenant une couche XML. Les SGBD purement XML sont plus que confidentiels (tamino par exemple).
Si je n'avais qu'un seul argument contre les inepties de cet article c'est le suivant : que faires des bases de données de plusieurs téra octets qui sont organiqées sous formes de tables ?
passer tout cela à la moulinette pendant 200 jours pour alimenter les objets du serveur applicatifs ? Si une banque fait cela il lui faudra prévoir de fermer 9 mois pour faire la transition !!!
D'autant que les SGBDR actuels intègrent une couche applicative de plus en plus forte. Il n'est qu'à voir MS SQL Server 2005 et ses outils de communications applicatives qui s'effectuent à l'aide de documents XML validés par des schéma XML échangés dans des transaction entres serveurs. De même l'exposition des procédures sous forme SOAP permet de faire de MS SQL Server un fournisseur de services web. Mais les données sont toujours stockées de manière relationelles (y compris les docuements XML) et cela restera longtemps encore le cas.
Il faut toujours penser que les données d'une entreprise c'est DU VOLUME et donc de l'inertie, et que l'on ne change pas de modèle de stockage par le simple fait d'une mode dictée par des élucubration farfelues, surtout si l'outils actuel (les SGBDR) donnent pleine satisfaction notamment en terme de performance et de sécurité. Et croyez moi sur ces sujets rien ne vaut un bon SGBDR, sauf à avoir le temps devant soit de réaliser cela en pur cobol, avec gestion des droits et tout le toutim !!!
Au fait désolé pour ton amour propre, Laurent, mais les chiens abois, la caravanne passe !
A +
je persiste...
Bonjour,
en effet une nouvelle techno n'en remplace jamais vraiment une autre.
Je comprends votre vive réaction dans la mesure où vous pensez que je veux mettre à la poubelle les SGBDR et les DBA avec.
Même si le ton et le titre de l'article sont provocateurs, et visiblement cela fonctionne assez bien avec vous, je maintiens le fond et
persiste à dire que les SQBDR ne sont pas clusterisables comme peuvent l'être des serveurs d'application.
A l'EASDAQ (émanation Anglaise du NASDAQ US), le volume de transactions dépasse de très loin ce que le meilleur SQGBDR du marché peut traiter.
Leur archi repose sur un cluster d'une trentaine de machines SOLARIS qui gèrent en RAM et dans des files d'attente de messages, des transactions temps réel sur 8TO de datas.
Oracle n'est qu'un accéssoire vers lequel sont flushées à intervalles réguliers ces 8TO, et le SGBD ne sert qu'à des fins de consultations épisodiques pour régler des litiges.
Si Oracle tombe, le système continue de fonctionner de manière transparente. En revanche, si un des solaris tombe, le système est conçu pour que les 29 autres se répartissent la charge sans broncher et sans pertes d'infos.
L'EASDAQ comme d'autres bourses sont effectivement très en avance par rapport à ce que l'on peut trouver ailleurs et leur architecture est un assemblage de middleware plutôt sophistiqués comme Tibco pour la messagérie asynchrone publish/subscribe et un data grid propriétaire.
Les SGBDR traditionnels continueront encore longtemps d'être le SPOF de nos architectures sauf dans les cas (comme celui que je viens de décrire) où l'on ne peut pas s'arrêter de travailler.
Ni Oracle, ni IBM, ni Microsoft ne savent proposer des clusters à plus de 4 machines (et encore, en pratique on en trouve rarement plus de deux).
Pour enfoncer le clou, un cluster de SGBDR aussi solide soit-il est toujours soumis aux I/O physiques et mêmes les baies de disques les plus performantes du type EMC montrent leur limites en forte charge.¨Et je pourrais ajouter que les techno de clustering SGBDR limitent la distance physique entre deux noeuds à quelques centaines de mètres tout au plus en mode de réplication synchrone.
Aucune de ces limites n'existent avec du cache transactionnel distribué : le nombre de noeuds, leur distance sont illimités (toutes proportions gardées) et quant au I/O, ils ne sont plus disques mais RAM.
Il y à donc de la place pour le genre de techno que je décris, ne vous en déplaise.
Au fait, à votre connaissance quel est le plus gros cluster SQLServer en prod ?
Cordialement,
Laurent.
Je comprends pas pourquoi mettre ce genre de titre... Vous faites de la presse sensation? vous etes paparazzi ou journaliste informatique?
Effectivement, y a peut etre de la place pour ce type d'architecture bien que j'ai un mal fou à voir où est l'interet à part pour l'exploit technique. Parce que etre obligé d'avoir 30 machines pour gérer 8To de données, ca me semble pas être une avancée.
Excusez moi également mais vous dites que les SGBDR sont les points faibles car si ils tombent, ca s'arrete. C'est peut etre vrai que si ils s'arretent, le SI s'arrete mais j'ai très rarement vu une base Oracle sur Unix crasher complétement ou un système DB2 tomber sur z/OS alors que des serveurs d'applications se bloquer, se vautrer lamentablement , j'en vois quand même plus souvent !!!
Si IBM, Oracle ne font pas de clusters à plus de 4 machines c'est qu'étant donné la puissance des machines actuelles et l'évolution rapide de cette puissance, le besoin est certainement contournable : au lieu de mettre 20 petites machines et bien on en achete 4 grosses (cf également la remarque juste apres)...
sur Oracle, le cluster SGBD (RAC) peut s'appuyer sur des clusters de machines, ce qui rend la limite de 4 peu significative, cf lien ci dessous pour comprendre ce que Large RAC veut dire :
http://www.oracle.com/technology/products/database/clustering/pdf/project_megagrid_capacity-planning-for-large-commodity-clusters.pdf
De même, il existe avec DB2 sur MVS les notions de Sysplex qui permettent à partir de n partitions (32 max) de créer une grosse machine logique sur lequel vont tourner nos DB2 et être capable d'aller chercher les ressources de toutes les machines. Magique... Et en plus ca existe depuis....1994! et encore plus magique, si une machine physique tombe, les autres encaissent la charge et le DB2 tourne encore...
http://search390.techtarget.com/sDefinition/0,,sid10_gci497625,00.html
http://www.oracle.com/solutions/performance_scalability/hplinuxtpcc.html
Quand je vois ce type d'articles, j'ai tout de même l'impression que les limites des SGBD comme vous dites n'en sont pas vraiment et qu'elles s'éloignent chaque jour davantage :
Autre chose, la réplication synchrone en cluster SGBD n'est plus au gout du jour sous Oracle, on utilise la technique Shared Disks and Fusion Cache (Partage des données et des ressources)...
Derniere chose, nous utilisons encore massivement IMS où je travaille. Mon dieu, une base de données hiérarchique... Sommes nous des hommes des cavernes? Je ne pense pas étant donné qu'IBM continue le développement d'IMS, c'est qu'il doit y avoir encore beaucoup de clients (en tout cas , beaucoup de banques l'utilisent sur les systèmes centraux).
Ou peut être allez vous tout manger avec votre nouvelle techno et auriez du titrer votre article comme ceci: "La fin des SGBDR et enfin la fin des SGBD hiérarchiques!"
Ou être encore plus audacieux si c'est le sensationnel qui vous intéresse et non le factuel...
Nous sommes d'accord pour dire qu'il y a de la place pour tout le monde comme vous le dites dans votre post alors je ne comprends pas l'interet de faire des titres comme ca! Si votre mag se met au niveau titre racoleur qu'on trouve abondamment dans les presses people, alors peut être pourrions nous dire que le point faible de l'informatique, ce sont les magazines....
J'en reste d'autant plus décu que je lis régulièrement votre mag et qu'on trouve des articles intéressants notamment au niveau des témoignages d'entreprises mais là, c'est digne de la presse people..
Cordialement,
Grégory
nous sommes -presque- d'accord
Bonjour,
une petite remarque préliminaire :
le titre et le ton du papier sont bcp moins provocateurs et raccoleurs que les accroches commerciales et les white papers de vendeurs de soft en général et d'Oracle en particulier; on se souvient encore de Oracle 9i, la base Internet !, ou encore de la 10g Unbreakable !!!...et pour la 11 ça va être qque chose du genre 11soa ou 11u pour ultimate, uranus ?
Bref, à la différence d'un vendeur de soft (et l'on peut remercier 01 de laisser qqun les égratigner gentiement, sachant qu'Oracle en particulier achète régulièrement de l'espace publicitaire dans ce canard), je n'ai rien à vendre, juste des expériences très, très concrêtes que je synthétise en quelques centaines de mots.
Revenons maintenant à votre 'post'.
D'abord, sans exploit, il n'y à pas d'avancées technologiques (et d'avancées tout court); ensuite les ingénieurs de l'EASDAQ ou ceux de la bourse de Chicago ne sont pas - a priori - une bande de rigolos juste soucieux de faire briller leur CV en mettant en oeuvre des architectures inutiles.
Ce ne sont pas tant les 8To de données (volumétrie moyenne pour un SGBDR) qui les ont poussés à immaginer leur infra, mais bien la charge transactionnelle d'une part et l'absolue necessité de ne pas avoir de SPOF d'aute part.
Bien sûr qu'un serveur d'app 'plante' plus souvent qu'une base, sauf qu'il est prévu pour et une grille (ou un cluster) de serveurs d'app est - je suis navré de le redire - plus resistant qu'une base installée sur une machine unique, voire deux.
Oracle ne s'engage jamais sur une dispo de 100% sur 8 heures de suite, tout simplement parcequ'ils ne maitrisent pas le hardware et que ni SUN, ni HP, ni IBM ne s'engagent non plus sur la panne 0.
La société pour laquelle je travaille, exploite plusieurs milliers de machines UNIX et statistiquement, il y en a toujours au moins une qui 'tombe' tous les mois et lorsqu'il s'agit d'une machine qui héberge une base (Oracle, DB2, Sybase, SQLserver...) il y a toujours une interrruption de service. C'est un fait indiscutable.
La plupart du temps, l'interruption de service est tolérée par le business et c'est pourquoi les SGBDR ont 'encore' de beaux jours devant eux.
Mais lorsque que l'on se rapproche de la zone des 1 ou 2 minutes maximum d'interruption, il ne reste plus grand monde pour s'engager.
C'est là qu'il faut faire preuve d'immagination et sortir du cadre.
Concernant la capacité des SGBDR à soutenir une forte charge, il est interressant de noter qu'Oracle suggère que l'on peut aussi adresser la perf en diminuant le nombre de hits sur le moteur en utilisant Toplink et en mettant en oeuvre le cache au niveau du serveur d'app...ah bon ?
Si vous êtes un fan d'Oracle, je vous invite à faire un détour par la doc de toplink d'ailleurs inclu dans l'offre CacheFusion à laquelle vous faites référence.
Toplink est un très bon outil, ancien (plus de 10 ans d'existence) et s'inscrit parfaitement dans la catégorie des archi alternatives que je défends.
Soit! Oracle, n'ira jamais dire que TopLink peut remplacer la base (on les comprend !), mais Tangosol qui eux adressent le cache distribué transactionnel, ne s'en privent pas et à Londres dans notre salle de marché, leur produit Coherence couplé à Hibernate fait des étincelles. C'est factuel non ?
Les nouvelles technos ne vont 'manger' personne et je n'aurai pas pris le risque de publier ce papier si je n'avais pas de retours d'experience très réels sur lesquels m'appuyer.
Enfin, je suis amusé de voire les réactions (relativement nombreuses) à ce papier.
J'ai noté deux camps : les experts SGBDR qui y voient une atteinte directe à leur savoir faire et une remise en question de leur raison d'être.
De l'autre, les vendeurs de solutions alternatives content que qqun ose donner un modeste coup de pied dans l'ordre établi.
J'ai beaucoup de respect pour les personnes qui se revendiquent du premier camp; ils sont les garants de la cohérence, de la performance des bases de données et sont totalement indispensables pour 'rattraper' les innombrables erreurs de conception et/ou de requêtes codées par des développeurs chez qui, malheureusement, la culture SQL se perd au profit de l'apprentissage de design patterns toujours plus abstraits.
Je n'espère pas vous convaincre, et demande juste un minimum de courtoisie.
Cordialement,
Laurent.
Dans la pratique les serveurs d'applications peuvent aussi utiliser les SGBD traditionnels.
Donc ca reviens à avoir une couche en plus, le serveur d'applications entre l'appli et le SGBD, et ceci pour les grandes applications d'entreprise.
Mais en aucun cas la disparition des SGBD.
Non les base de données relationnelles ne risquent pas de disparaitre, ce débat à déjà eu lieu ici à plusieurs reprises.
Dans la pratique le marché bouge peux, c'est toujours majoritairement les mêmes éditeurs de SGBD qui ont le marché (Oracle, IBM, Microsoft, etc...), et ces mêmes éditeurs font évoluer leurs produits pour être à la mode. Ici même , la rubrique Oracle n'à jamais été aussi active, et le nombre de lecteurs que nous avons sur Oracle est très élevé, et de plus en plus élevé chaque jour, et les rubriques sur les autres SGBD tels que SQL-Server, MySQL, PostgreSQL, InterBase/firebird n'ont jamais été aussi animées.
C'est toujours les mêmes SGBD des éditeurs traditionnels qui sont toujours massivement utilisés.
Mais bon les nouvelles technologies on peut en discuter, le titre de l'article est très provocateurs, comme le précise l'auteur de l'article lui même.
???
Bonjour,
pour que les choses soient bien claires :
Je ne suis pas journaliste, et c'est moi qui suit à l'origine de ce papier; il n'a pas été modifié par 01, juste mis page.
Vous pouvez rester 'scotchés' sur le titre de l'article et ne pas lire ni l'article lui-même, ni les compléments d'explications donnés sur ce forum, c'est votre droit.
Je ne vais pas vous étaler mon CV, je préfere continuer à tenter de discuter sereinement.
Commencer votre 'post', par 'la vérité c'est que...' témoigne d'une généralisation assez peu prudente.
Je re-affrime que certaines archi, sont obligées de faire sans SGBD pour les raisons que j'ai déjà expliquées; ce qui ne veut pas dire que c'est le cas de toutes les archi.
Les SGBDR répondent à bcp de besoins, mais pas à tous. point.
Je réfute cette vision étroite entretenue par les éditeurs traditionnels et relayée par la presse que tout ne peut se faire qu'avec des SGBDR et que le reste n'est que pure invention.
Encore une fois, je n'ai rien à vendre, je travaille pour un groupe bancaire de plus de 100000 personnes avec plus de 10000 informaticiens et la diversisté de notre SI et des besoins fonctionnels nous amènent de temps en temps à concevoir des architectures non classiques.
Cordialement,
Laurent.
superbe débat en vue !
ce qui m'intéresserait de savoir c'est le pourcentage approximatif des "solutions" exotiques du genre exploité chez privatelab, comparée aux "traditionnels" SGBDR. Je suppose que les "traditionnels" SGBDR sont le plus répandus, mais que pour certaines utilisations évoquées, ils ne peuvent pas répondre à tous les besoins.
Je n'ai pas lu l'article, mais il ne faut quand même pas oublier qu'on ne sait pas du tout ce que nous réserve l'avenir. Les solutions de l'article peuvent très bien évoluées comme les SGBR classiques peuvent évoluées dans le même sens pour s'adapter à ce "futur" marché. L'avenir seul nous le dira.
En outre, c'est quand même très intéressant de connaître les autres systèmes "exotiques"
Pour ma part, j'ai de la difficulté à saisir comment les serveurs d'applications peuvent géré les transactions sans utilisé un SGBD comme IMS ou DB2.
Dans la boite où je travail, ça fait plus de 8 ans que j'y travail et le système n'est jamais tombé et on parle de plus d'un millions de transactions par jour.
Le principle est simple, plusieurs petits serveurs de type Tandem Non-Stop (qui a été racheté par Compaq puis par HP), ces serveurs ont un minimum d'informations pour approuvé une transaction et la mettre en file pour être traité sur un mainframe IBM (z/OS) sur une BD IMS.
Lors des monté en charge la file augmente (ex.: le 24 décembre), la file augmente tout simplement. Si le mainframe tombe les Tandems prennent le relais. Si un Tandem tombe les autres prennent le relais (malgré que j'ai jamais entendu d'histoire qu'un tandem avait tombé).
Le tout utilisé depuis 1983, donc fiable. J'ai de la misère à vois l'avantage où est le gain d'utilisé des serveurs en clusters? À part peut-être le coût d'acquisition mais bon pour ma part, quand on parle du core business y'a pas de risque à prendre faut une architecture éprouvé!
Research
Bonjour,
Si à un quelconque moment dans mes remarques, j'ai pu vous sembler manquer de courtoisie,je vous prie de bien vouloir m'en excuser. En outre, l'ensemble de mes attaques n'étaient pas ciblées vers le journaliste ou la qualité/véracité des propos mais bien contre le titre que je continue à considérer comme déplacé.
Je vous accorde bien entendu le fait que les fournisseurs de soft sont de grands provocateurs dans leurs présentations. J'ajouterai même l'excellent IBM lors de la sortie du z/OS remplacant l'OS/390 qui était présenté comme Z comme Zero Down Time !
Je mettrai un bémol sur ce que vous dites par rapport aux editeurs qui ne s'engagent pas sur la disponibilité. Effectivement, lorsque le hardware n'est pas maitrisé par l'éditeur, ce qui est le cas de quasiment tous les softs sur Unix, on ne peut pas vraiment s'engager sur la dispo. mais IBM qui construit ses serveurs, annonce en Parallel Sysplex z/OS une dispo de 99.9999%, ce qui reste à mon avis une annonce forte.
http://www.banknet.com/eisindex.html
Là, ou je vous rejoins complétement, c'est sur certains besoins spécifiques à certains applicatifs qui fait qu'effectivement parfois il faut sortir des clous.
Travaillant chez le second constructeur automobile européen, nous avons nous mêmes des applications légèrement hors normes.
C'est pourquoi je ne remets pas du tout en cause le choix technique fait. Je suis d'accord avec vous que les gens de EASDAQ ont choisi la solution technique la plus adaptée à leurs besoins, simplement j'ai du mal à la conceptualiser et donc à la comprendre du fait que pour moi jusqu'à votre intervention, j'étais comme Research Am, je pensais que seul IMS pouvait répondre aux forts besoins transactionnels.
Certains de vos arguments contre les SGBD ne me semblaient pas vraiment pertinents, c'est pourquoi j'ai répondu. Je rajoute meme sur la distance limités qu'IBM met à dispo des utilisateurs de sysplex des architectures de type GDPS (Geographically Dispersed Parallel Sysplex): http://www-03.ibm.com/servers/eserver/zseries/gdps/
J'ai beaucoup travaillé sur les SGBDR que ce soit Oracle Unix ou DB2 Host , mais je me rapproche maintenant des serveurs d'applications par volonté mais aussi par la force des choses (car c'est très à la mode en ce moment) et je trouve que ce sont des technos très intéressantes et prometteuses (encore davantage aux vues de vos présentations) mais qui manquent à mon sens encore un petit peu de maturité (notamment par rapport à ces technos éprouvés que sont les SGBD)
Enfin, je vous rejoins enfin sur 2 points (comme quoi finalement on est d'accord sur pas mal de choses quand meme
1/ La diversité des SI et des besoins dans lesquels nous évoluons certainement tous 2 fait qu'il y a de la place tout le monde. base de données hiérarchiques, Relationnels, Serveurs d'applications, moniteurs transactionnels comme CICS et solutions plus exotiques au besoin.
2/ Votre remarque sur les développeurs, je suis totalement d'accord. Ah ca , de l'UML, des design patterns, ils savent en faire mais alors écrire du SQL performant, c'est 0 !
En effet..
Bonjour,
en effet, j'ai été un peu surpris par l'agressivité de certains 'post', mais disons que cela fait partie du jeu (quoique) et que la provocation est une de mes marques de fabrique; je l'assume donc.
Concernant vos remarques sur des archi basées mainframe, je dois avouer ne pas en avoir d'experience concrête.
Cela dit, chez nous le sysplex est promu par IBM depuis des années, mais aucune mise en oeuvre pratique n'en a jamais été faite.
Je reste donc relativement sceptique, mais je reconnais volontiers que si un seul éditeur pouvait proposer une tolérance de panne au SGBD, alors il ne resterait qu'IBM en compétition.
Ensuite si l'on ajoute la dimension économique, vous serez d'accord pour dire que si l'on peut immaginer qque chose d'alternatif basé sur des technos plus ouvertes et donc une puissance de 10 moins chère, cela vaut le coup d'investiguer....
Pour mieux comprendre comment on peut se passer d'un moteur de persistance classique ou au moins rendre son abscence moins critique, je vous invite à consulter cette page du produit Coherence et notamment le mode write-behind : http://www.tangosol.com/coherence-uses-c.jsp ou encore http://www.tangosol.com/implguide.jsp
A londres, comme je l'ai déjà mentioné, nous utilisons Coherence couplé à Hibernate et même si la base de données reste encore indispensable, elle est 'sortie' du chemin critique.
Je ne fais pas de pub pour ce produit, mais ils sont au coeur du type de technos dont je parle et sur lesquelles mon papier extrapole.
Cordialement,
Laurent.
Merci pour la solution, mais quel était le problème ?
Bonjour,
Si j'ai bien tout suivi, il est plus performant de gérer des données en RAM que sur disque
Et pour gérer les données il est possible de développer des fonctionnalités soit via une couche objet, soit via un logiciel dédié, soit en reprenant l'algèbre relationnelle d'un SGBDR fonctionnant en RAM.
Dans ce cas, les fonctions développées sont équivalentes.
Maintenant il reste à déterminer si certaines fonctions ne le sont pas (équivalentes), ou bénéficient d'un gain de performance suffisant pour justifier l'abandon d'une architecture de type classique: en bref, dans votre domaine, en quoi a t-il été intéressant ou novateur de mettre en place une architecture O-O distribuée ? Pour répondre à quel besoin ?
J'imagine bien sûr que la diagonalisation d'une matrice, la triangulation de points, le recuit simulé, la détection de contours, l'analyse factorielle, la recherche du chemin optimal, l'analyse combinatoire, la reconstruction d'images 3D à partir de coupes 2D, ou la transformée de Fourier, ne sont pas vraiment des opérations optimalement traitées si on s'impose de ne le faire qu'avec l'algèbre relationnelle.
Mais de quelle nature était votre problème ?
C'est possible de gérer un SGBDR en RAM, il suffit que la taille RAM libre du système soit supérieure à la taille de la base.
D'ailleurs c'est exactement comme ca que ce forum est géré, et c'est pourquoi pourquoi vous pouvez naviguer sur le forum presque instantanément, même en étant très nombreux connectés. Plus de 99% des "reads" se font dans le cache RAM.
Il n'y à guère que les insert et les updates qui génèrent un accès disque, et c'est plutot une bonne chose que ca soit écrit sur disque, si on reboot le système la base est toujours la.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager