Trois couches de cache entre la sélection et le disque

Lorsque votre application déclenche une instruction SELECT, cette requête ne touche presque jamais un disque en rotation ni même un stockage flash brut : elle passe par trois couches de cache distinctes qui déterminent silencieusement si votre réponse arrive en microsecondes ou en millisecondes. Comprendre ces couches fait la différence entre une plate-forme commerciale qui évolue sans effort et une plate-forme qui s'effondre sous la charge du monde réel.

Que se passe-t-il au moment où une requête SELECT quitte votre application ?

Au moment où votre application envoie une requête SELECT, elle entre dans un pipeline que la plupart des développeurs n'inspectent jamais. Le moteur de base de données intercepte la requête avant toute E/S, analysant le SQL dans un plan d'exécution interne et consultant immédiatement sa première ligne de défense : le cache des résultats de la requête. Si une requête identique avec des paramètres identiques a été exécutée récemment, le moteur peut renvoyer un ensemble de résultats mis en cache sans toucher à une seule page de données. Ceci est parfois appelé cache de requêtes ou cache de résultats, et sur les charges de travail à lecture élevée et à faible écriture, comme les tableaux de bord d'analyse et les modules de reporting, il peut éliminer entièrement la grande majorité des lectures de disque.

L’essentiel ici est que le cache de requêtes est très sensible aux mutations de données. Tout INSERT, UPDATE ou DELETE sur la table sous-jacente invalide les résultats pertinents mis en cache. C'est pourquoi les systèmes transactionnels gourmands en écriture désactivent souvent entièrement le cache de requêtes et s'appuient plutôt sur les couches plus profondes.

Qu'est-ce que le pool de tampons et pourquoi est-il plus important que vous ne le pensez ?

La deuxième couche de cache — et sans doute la plus importante dans les systèmes de production — est le pool de tampons (appelé tampon partagé dans PostgreSQL, pool de tampons InnoDB dans MySQL). Il s'agit d'une région de RAM que le moteur de base de données utilise pour contenir les pages de données récemment consultées. Lorsqu'une requête ne peut pas être servie à partir du cache de résultats, le moteur vérifie si les pages de données requises résident déjà dans le pool de mémoire tampon avant d'émettre une lecture sur disque.

Le pool tampon fonctionne sur le principe de localité temporelle et spatiale : les données consultées récemment sont susceptibles d'être consultées à nouveau, et les données stockées à proximité des données consultées sont susceptibles d'être consultées prochainement. Les administrateurs de bases de données ajustent la taille du pool de mémoire tampon comme l'une des décisions de configuration les plus importantes qu'ils prennent. Un pool de mémoire tampon trop petit provoque une expulsion constante de pages, produisant un phénomène appelé thrashing, dans lequel le système passe plus de temps à gérer les échecs de cache qu'à exécuter des requêtes.

Aperçu clé : dans la plupart des charges de travail OLTP, un pool de mémoire tampon de bonne taille signifie que 95 à 99 % de toutes les lectures de données sont effectuées à partir de la RAM. L'ensemble de travail (le sous-ensemble de vos données que les requêtes touchent fréquemment) est souvent bien plus petit que la taille totale de la base de données. Dimensionner votre pool de mémoire tampon pour qu'il s'adapte à votre ensemble de travail, et non à l'intégralité de votre ensemble de données, est l'action de réglage la plus rentable que vous puissiez entreprendre.

Comment le cache du système d’exploitation comble-t-il l’écart entre la RAM et le disque ?

Même lorsque le pool de mémoire tampon de la base de données manque, une requête n'est pas encore destinée à une véritable lecture sur disque. Le système d'exploitation gère un cache de pages (également appelé cache du système de fichiers), une région de RAM gérée par le noyau qui met en mémoire tampon les lectures et les écritures sur les périphériques de blocage. Lorsque le moteur de base de données demande une page absente de son pool de mémoire tampon, le noyau du système d'exploitation vérifie son propre cache de pages avant d'émettre une commande d'E/S physique au contrôleur de stockage.

Cette troisième couche est largement invisible pour les développeurs d'applications mais extrêmement importante sur les systèmes où le pool de mémoire tampon de base de données est sous-approvisionné. Le cache des pages du système d'exploitation est partagé entre tous les processus, il entre donc en concurrence avec votre serveur d'applications, votre serveur Web et tout autre logiciel exécuté sur le même hôte. Sur les serveurs de bases de données dédiés, cette concurrence est minime et le cache du système d'exploitation fournit un tampon de seconde chance significatif. Sur les hôtes partagés ou les conteneurs avec des limites de mémoire strictes, le cache du système d'exploitation est souvent trop petit pour être utile.

Quelle couche de cache est responsable du plus grand nombre de gains de performances dans la pratique ?

Dans les systèmes de production réels, le pool tampon domine

Related Posts

• LCM : Gestion du contexte sans perte [pdf]
• Outil de sandboxing en ligne de commande peu connu de macOS (2025)
• CXMT propose des puces DDR4 à environ la moitié du prix du marché.
• L'IRS a perdu 40 % de son personnel informatique et 80 % de ses dirigeants technologiques lors d'une restructuration pour plus d'« efficacité »