Toujours non....Il faudra quand même aller chercher les données sur le disque, il me semble ...
Si votre mémoire a été correctement dimensionnée, moins de 1% du volume des données doit être lu depuis le disque, le reste étant déjà en mémoire...
reprenons ma démo puisque vous ne l'avez pas comprise (je la simplifie volontairement en ne parlant pas des actions entreprises sur le journal de transaction)...
Un utilisateur fait un INSERT via un port réseau. L'insert vient donc bien directement en RAM. La ligne est insérée dans une des pages mémoire de la table. Si la table (ou au moins une de ses pages avec un peu d'espace vide) n'est pas déjà en RAM alors il faudra lire depuis le disque une page ou mettre la ligne... C'est ce fameux 1%...
Au bout d'un certains temps (quelques minutes au maximum) on ira écrire la page dans le fichier contenant les données. Cette technique d'écriture retardée permet deux avantages :
1) faire des salves d'écriture soit par dépassement du temps impartit, soit on iddle du proc
2) regrouper les écritures dans l'ordre de contiguïté physique des pages par rapport au disque et non pas écrire séquentiellement les pages dans leur ordre d'arrivée (Michael Stonebraker avit prévu cela dès les années 70)...
Et donc ainsi de passer le minimum de temps en opérations d'IO disque !
Maintenant je voit que vous avez peu car la donnée n'est présente qu'en mémoire pendant un certains temps... C'est là qu'intervient le journal qui consiste à écrire tout simplement la demande SQL brute de fonderie dans le fichier de journalisation. Mais écrire un fichier "writeAhead" basiquement binaire est quelques chose de très rapide en regard de l'effort à faire pour insérer une ligne d'une table au bon endroit.
Il faut ainsi remarquer que le jorunal est l'un des tout premier point de contention d'un SGBDR.
Vous constaterez donc que les données sont préalablement mises en mémoire et non mise en mémoire suite à la lecture d'un disque !
Mais cette technologie est la conséquence de plus de 30 années de R&D
A +
Partager