Tre livelli di cache tra Select e Disk

Quando la tua applicazione attiva un'istruzione SELECT, la query non tocca quasi mai un disco rotante o addirittura una memoria flash non elaborata: passa attraverso tre distinti livelli di cache che determinano silenziosamente se la tua risposta arriva in microsecondi o millisecondi. Comprendere questi livelli fa la differenza tra una piattaforma aziendale che si adatta facilmente e una che cede sotto il carico del mondo reale.

Cosa succede nel momento in cui una query SELECT lascia la tua applicazione?

Nel momento in cui la tua applicazione invia una query SELECT, entra in una pipeline che la maggior parte degli sviluppatori non ispeziona mai. Il motore del database intercetta la richiesta prima che si verifichi qualsiasi I/O, analizzando l'SQL in un piano di esecuzione interno e consultando immediatamente la sua prima linea di difesa: la cache dei risultati della query. Se di recente è stata eseguita una query identica con parametri identici, il motore può restituire un set di risultati memorizzato nella cache senza toccare una singola pagina di dati. Questa viene talvolta chiamata cache delle query o cache dei risultati e su carichi di lavoro ad alta lettura e bassa scrittura, come dashboard di analisi e moduli di reporting, può eliminare completamente la stragrande maggioranza delle letture del disco.

L'aspetto fondamentale qui è che la cache delle query è altamente sensibile alle mutazioni dei dati. Qualsiasi INSERT, UPDATE o DELETE sulla tabella sottostante invalida i risultati rilevanti memorizzati nella cache. Questo è il motivo per cui i sistemi transazionali che richiedono molte scritture spesso disabilitano completamente la cache delle query e si affidano invece agli strati più profondi.

Cos'è il buffer pool e perché è importante più di quanto pensi?

Il secondo livello di cache, e probabilmente il più importante nei sistemi di produzione, è il buffer pool (chiamato buffer condiviso in PostgreSQL, buffer pool InnoDB in MySQL). Si tratta di un'area di RAM utilizzata dal motore di database per conservare le pagine di dati a cui si è avuto accesso di recente. Quando una query non può essere fornita dalla cache dei risultati, il motore controlla se le pagine di dati richieste sono già residenti nel pool di buffer prima di eseguire qualsiasi lettura del disco.

Il buffer pool funziona in base al principio della località temporale e spaziale: è probabile che i dati a cui si accede di recente vengano consultati di nuovo, mentre è probabile che i dati archiviati vicino ai dati a cui si accede vengano accessibili presto. Gli amministratori del database ottimizzano la dimensione del pool di buffer come una delle decisioni di configurazione con il massimo effetto che prendono. Un pool di buffer troppo piccolo causa una costante eliminazione delle pagine, producendo un fenomeno chiamato thrashing, in cui il sistema dedica più tempo alla gestione degli errori di cache che all'esecuzione delle query.

Approfondimento chiave: nella maggior parte dei carichi di lavoro OLTP, un pool di buffer di buone dimensioni significa che il 95-99% di tutte le letture dei dati viene servito dalla RAM. Il working set, ovvero il sottoinsieme dei dati che le query effettivamente toccano frequentemente, è spesso molto più piccolo della dimensione totale del database. Dimensionare il pool di buffer per adattarlo al tuo set di lavoro, non all'intero set di dati, è l'unica azione di ottimizzazione con il rendimento più elevato che puoi intraprendere.

In che modo la cache del sistema operativo colma il divario tra RAM e disco?

Anche quando manca il pool di buffer del database, una query non è ancora destinata a una vera lettura del disco. Il sistema operativo mantiene una cache di pagina (chiamata anche cache del filesystem), una regione di RAM gestita dal kernel che memorizza nel buffer le letture e le scritture sui dispositivi a blocchi. Quando il motore del database richiede una pagina assente dal pool di buffer, il kernel del sistema operativo controlla la propria cache della pagina prima di inviare un comando I/O fisico al controller di archiviazione.

Questo terzo livello è in gran parte invisibile agli sviluppatori di applicazioni ma estremamente importante sui sistemi in cui il pool di buffer del database è sottoprovisionato. La cache della pagina del sistema operativo è condivisa tra tutti i processi, quindi compete con il server delle applicazioni, il server Web e qualsiasi altro software in esecuzione sullo stesso host. Sui server di database dedicati, questa competizione è minima e la cache del sistema operativo fornisce un significativo buffer di seconda possibilità. Su host condivisi o contenitori con limiti di memoria ristretti, la cache del sistema operativo è spesso troppo piccola per essere d'aiuto.

Quale livello di cache è responsabile del maggior numero di vantaggi in termini di prestazioni nella pratica?

Nei sistemi di produzione del mondo reale, il buffer pool domi

Related Posts

• CXMT offre chip DDR4 a circa la metà del prezzo di mercato prevalente
• Lo Strumento di Sandboxing da Riga di Comando Poco Conosciuto di macOS (2025)
• Mostra HN: DSCI – CI Dead Simple
• Padlet (YC W13) sta assumendo a San Francisco e Singapore