Discussion :

[Robert A.]

La je m'adresse aux veterans...

----------------------------

Moi aussi a l'epoque de DOS, je voulais creer un systeme de gestion de bases de donnees jusqu'a ce que je tombe sur Rapid File cree en MSSForth (publie pr Ashton Tate vers 1986)

Et la mon envie de creer un SGBDD a disparu a jamais!

A ce jour je n'ai jamais trouve un seul SGBDD qui aille a une telle vitesse!

Qq'un a-t-il deja reussi a percer le secret de la rapidite phenomenale de Rapid File d'Ashton Tate (une BDD non-relationnelle)?

Etait-ce le langage utilise (MSS Forth)?

Etait-ce l'algorithme de recherche et de stockage des donnees?

Etait-ce le fait que les records etaient places en RAM?

----------------------------

Soit dit en passant il y a des tas de programmes en DOS qui ont disparu et qui etaient fabuleux: Lotus Agenda, Grandview (qui faisait de plans de textes), le chiffrier Lucid... et ce fameux Rapid File..

C'etait le temps des fleurs...

[Pomalaix]

Personnellement je n'ai jamais fréquenté RapidFile de près ou de loin, mais il me paraît utile, comme on le rappelle souvent sur ces forums, de comparer ce qui est comparable.

Un SGBD, au sens où en l'entend de nos jours, est un système relationnel capable de gérer plusieurs centaines de Go de données et de supporter en simultané plusieurs centaines ou milliers d'utilisateurs, avec une garantie d'intégrité des données, de non interférence entre les transactions, etc. A ce sujet, vous pouvez consulter notamment la rubrique de SQLPro (sur ce site) qui s'appelle plus ou moins textuellement "ce qu'il faut attendre d'un vrai SGBD".
Je doute que RapidFile soit dans cette catégorie de systèmes.

Il est certain que des algorithmes spécialement astucieux peuvent fournir des gains de performances notables, mais je ne crois pas que les SGBD, actuellement, se distinguent vraiment les uns des autres sur ce point.

Quant au fait de maintenir les données en mémoire, il y a belle lurette qu'on n'y pense plus guère, pour au moins 2 raisons : la RAM continue à être plus chère que les disques durs, et les systèmes avec 200 Go de RAM ne courent quand même pas les salles machines. Et même si la RAM était disponible à volonté pour pas un rond, elle garde toujours le fâcheux inconvénient d'être volatile. Un système avec toutes les données en RAM ne serait adapté qu'à une application en lecture seule.

Donc retrouver tous les secrets de cuisine de RapidFile, hormis le plaisir intellectuel, aurait un intérêt assez limité à mon sens, sauf si on a besoin d'un produit qui fasse "la même chose", mais pas plus.

[Robert A.]

Merci pour votre reponse, Pomalaix..

Donc, selon vous, les gros SGBDD actuels (Oracle, MYSQL, etc.) lisent les donnees directement sur le disque dur sans rien charger en memoire RAM?

Difficile a concevoir puisque comme le dit Barbibulle, la vitesse de lecture en RAM est 100 fois plus rapide que la vitesse d'acces au disque dur...

J'aurais pense que les SGBDD chargeaient une partie des donnees en RAM, faisaient la lecture, dechargeaient le bloc et chargeaient le prochain bloc jusqu'a ce qu'ils trouvent l'information demandee...

Ce n'est donc pas le cas... Etrange.....

[woodwai]

La méthode de lecture des données d'un SGBD est trés complexe, de nombreux méchanismes insoupconné entres en jeux, mais je te rasure, un SGBD utilise bien sur la RAM pour mettre en tampon les donnés, il charge une partie des bloc en mémoire, puis de là effectue les traitements, mais ce que voulait dire Pomalaix c'est que de toute façon tout SGBD stocke les données sur le disque et va chercher les données uniquement au moment où il en a besion, aprés la vitesse d'un SGBD va dépendre de la puissance du processeur, de la RAM dispo, du nombre de données présente dans le SGBD, de l'optimisation mis en place sur le SGBD, ... et les sytème actuel sont de vrai bombe par rapport à ce qui se fesait avant et gérent à une vitesse étonnante des volumes de données monstrueux.

[Pomalaix]

Comme l'a expliqué Woodwai, les SGBD actuels utilisent bien évidemment la RAM, mais n'y stockent pas l'intégralité de la base de données. Pour avoir un ordre d'idée (très à la louche), ce serait du genre 1Mo de mémoire pour 100 Mo de données.

Par ailleurs, un accès RAM n'est pas 100 fois plus rapide qu'un accès disque, mais plutôt 100 000 à 1 000 000 de fois plus rapide ! (On est en nanosecondes pour la RAM, et en millisecondes pour le disque).
Cette différence qui est phénoménale à la base est cependant atténuée par les techniques de cache et de lecture anticipée.

Ce que je voulais dire dans mon précédent message, c'est qu'on ne demande plus la même chose à un SGBD aujourd'hui qu'il y a 20 ans, et que de ce fait les produits ne sont plus comparables. Le stockage des données reste certes une fonctionnalité majeure, mais ne suffit plus, puisqu'on exige en outre le support transactionnel multiutilisateur, etc.
Pour faire un parallèle, une automobile, de nos jours, n'est plus seulement une machine qui roule, mais un véhicule qui fournit en plus une sécurité renforcée et des assistances à la conduite : air bag, ABS, correction de trajectoire et j'en passe. Alors après, on trouvera toujours un mécano amateur pour dire qu'une bonne 2CV, c'était quand même vachement plus simple à réparer, et que ça servait aussi à se déplacer...

[Robert A.]

Merci Pomalaix et Woodwai pour vos excellentes analyses et analogies.

Les SGBDD actuels sont donc des gros bolides et bien peu de gens regrettent le temps des 2 CV... A part quelques nostalgiques qui vivent un peu trop dans le passe...

-------------------------

Cependant j'aimerais voir si par hasard qq'un pourrait me dire s'il/elle a deja utilise Rapid File qui etait fait en MMS Forth .. Et s'il/elle connait l'algorithme d'optimisation de la recherche de donnees...

Simple curiosite de ma part...