Mémoire virtuelle, persistance : faut-il des fichiers ?
Mmm j’admets ne pas avoir tout saisi et survolé ce texte très dense que je relirai, néanmoins déjà une question me vient ; vous écrivez "or dans un système classique tel Unix c’est le noyau qui décide des pages de mémoire virtuelle à garder en mémoire volatile ou à reléguer en mémoire auxiliaire, ce qui aboutit à des contradictions"
Mais je ne comprends pas comment il pourrait en être autrement quel que soit le type de gestion de la mémoire, puisque quel que soit l’OS qui est mis en place un algorithme définit dans le noyau au niveau de l’ordonnanceur ("scheduler") devra gérer l’utilisation de la mémoire par les processus non ?
A moins d’imaginer que le "hardware s’adapte lui même" (et je ne vois pas trop comment ce serait possible).
Merci pour ces textes très intéressants.
Justement, c’est bien là la question : comme l’allocation de mémoire est décidée en dernier recours par l’OS, toute tentative d’un logiciel, fût-il SGBD, pour avoir sa propre stratégie sera au mieux redondante avec l’OS, et sans doute contrariante. C’est bien pourquoi la gestion de la persistance doit être effectuée au niveau de l’OS, du noyau.
Oui, l’OS doit gérer un ensemble de processus qui demandent des accès simultanés aux ressources. C’est pour çà que Linux est une excellente solution (tous les OS open source en fait) puisqu’on peut réécrire le code source du noyau et par exemple l’optimiser pour la gestion d’un processus en particulier comme un SGBD. Pour le "NoSQL", il semble que le gros intérêt soit de ne pas avoir à gérer toutes les relations entre les tables (comme c’est le cas en SQL avec les multiples JOIN) et donc la grande flexibilité, ce qui est intéressant quand on gère de grandes quantités de données avec beaucoup de modifications. On pourra répondre que les INDEX sont là pour éviter les temps de réponses longs dans les SGBD.
Bien cordialement.