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
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.
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.
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 ;) ... je m'en doutais un peu.
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 ?