Usa la cache delle query integrata in MySQL invece di cercare di mantenerla tu stesso. Cancellerà automaticamente le query memorizzate nella cache nelle tabelle quando vengono scritte. Inoltre, funziona in memoria, quindi dovrebbe essere molto efficiente...
Inoltre, non solo memorizzare nella cache le query. Prova a memorizzare nella cache interi segmenti dell'applicazione in diverse fasi del ciclo di rendering. Quindi puoi consentire a MySQL di memorizzare nella cache le query, quindi memorizzare nella cache ogni singola vista (renderizzata), ogni singolo blocco e ogni pagina. Quindi, puoi scegliere se eseguire o meno il pull dalla cache in base alla richiesta.
Ad esempio, un utente che non ha effettuato l'accesso può ottenere l'intera pagina direttamente dalla cache. Ma un utente che ha effettuato l'accesso potrebbe non essere in grado di farlo (a causa del nome utente, ecc.). Quindi, per lui, potresti essere in grado di visualizzare 1/2 delle tue visualizzazioni sulla pagina dalla cache (poiché non dipendono dall'oggetto utente). Hai ancora il vantaggio della memorizzazione nella cache, ma sarà suddiviso in livelli in base alle necessità.
Se ti aspetti davvero molto traffico, vale sicuramente la pena esaminare Memcached
. Consenti a MySQL di archiviare le tue query per te, quindi archivia tutti gli elementi della cache della terra dell'utente in memcache...
Modifica: Per rispondere alla tua modifica:
I filesystem possono diventare lenti se una singola directory diventa grande. Finché stai "spaziando i nomi" per directory (quindi ogni directory ha solo una piccola parte di file di cache), dovresti andare bene da quel punto di vista. Per quanto riguarda la soglia esatta, dipenderà davvero dall'hardware e dal filesystem più di ogni altra cosa. So che EXT3 diventa piuttosto lento se c'è un carico di file in una singola directory (ho directory con letteralmente centinaia di migliaia di file e può volerci fino a mezzo secondo semplicemente per stat() uno dei file, per non parlare di qualsiasi tipo di elenco di directory)...
Ma renditi conto che se aggiungi un altro server, avrai una duplicazione della cache (che non è una buona cosa) o dovrai riscrivere l'intero livello della cache. C'è un motivo per non utilizzare Memcached fin dall'inizio?
EDIT 2: Per rispondere alla tua ultima modifica:
È ancora troppo difficile da chiamare. Ho un'applicazione che ha un database con circa 1,5 miliardi di righe (con una crescita di circa 500.000 al giorno). Non utilizziamo alcuna memorizzazione nella cache perché non abbiamo problemi di concorrenza. E anche se lo facessimo, sarebbe meglio inserire più server MySQL piuttosto che aggiungere la memorizzazione nella cache poiché qualsiasi forma di cache avrebbe un tasso di successo così basso che non varrebbe la pena il tempo di sviluppo per aggiungerlo.
E questo è il motivo per cui sono così irremovibile sul non memorizzare nella cache per la velocità. Ci sarà sempre un oggetto che non è nella cache. Quindi, se colpisci una pagina con uno di quegli oggetti, deve comunque essere veloce. Come regola generale, provo a memorizzare nella cache tutto ciò a cui si accederà nuovamente nei prossimi minuti (riservo comunque un tempo di vita di circa 5 minuti in produzione su altre applicazioni). Quindi, se gli elementi non ottengono più di qualche hit in quell'intervallo di tempo, o la percentuale di hit è molto bassa (meno del 90%), non mi preoccupo di memorizzare nella cache quell'elemento....
