Velocità di accesso ai file rispetto alla velocità di accesso al database

Question

Il sito che sto sviluppando in php rende molte richieste di database MySQL per pagina visualizzate. Anche se molte sono piccole richieste con indici progettati correttamente. Non so se valga la pena di sviluppare uno script di cache per queste pagine.

1) I file I/O sono generalmente più veloci delle richieste del database? Questo dipende dal server? C'è un modo per testare quanti dei tuoi server possono gestire?

2) Una delle pagine controlla il database per un nome file, quindi controlla il server per vedere se esiste, quindi decide cosa visualizzare. Questo presumerebbe trarrebbe beneficio da una visualizzazione di pagina in cache?

Anche se ci sono altre informazioni su questo argomento che potreste inoltrarmi, sarebbe molto apprezzato.

Grazie

Answer 1

Se si sta effettuando un accesso di tipo read-heavy (ricerca di nomi di file, ecc.) Si potrebbe beneficiare di memcached. È possibile memorizzare i dati "più caldi" (creati di recente, usati di recente, in base alla propria app) in memoria, quindi interrogare il DB (e possibilmente i file) quando la cache non riesce. L'accesso alla memoria è molto, molto più veloce del database o dei file.

Se è necessario l'accesso in scrittura, un database è la strada da percorrere. Se utilizzi MySQL, utilizza le tabelle InnoDB o un altro motore che supporta il blocco a livello di riga.Ciò eviterà che le persone si blocchino mentre qualcun altro scrive (o peggio, scrivendo comunque).

Ma in ultima analisi, dipende dai dati.

Answer 2

Questo dipende molto da molti fattori. Se si dispone di un database veloce con molti dati memorizzati nella RAM o un sistema RAID veloce, è molto probabile che si ottenga molto dalla memorizzazione semplice del caching del file system sul server web. Pensa anche alla scalabilità. Sotto carico di lavoro elevato un semplice meccanismo di memorizzazione nella cache potrebbe facilmente diventare un collo di bottiglia mentre un database è ben progettato per gestire carichi di lavoro elevati.
Se non ci sono così tante richieste e voi (o il sistema operativo) siete in grado di mantenere la cache nella RAM, potreste essere in grado di ottenere delle prestazioni. Ma ora sorge la domanda, se è davvero necessario eseguire il caching a basso carico di lavoro.

Answer 3

Dipende da come sono strutturati i dati, quanto c'è e con quale frequenza cambia.

Se si dispone di importi relativamente piccoli, di dati relativamente statici con relazioni relativamente semplici, i file flat sono lo strumento giusto per il lavoro.

I database relazionali si presentano quando le connessioni tra i dati sono più complesse. Per i 'look up tables' di base possono essere un po 'eccessivo.

Tuttavia, se i dati cambiano continuamente, può essere più semplice utilizzare un database anziché gestire la gestione della configurazione a mano e per grandi quantità di dati, con i file flat hai il problema aggiuntivo di come trovi quello che ti serve, in modo efficiente.

Answer 4

Dal punto di vista delle prestazioni, è più saggio ottimizzare il server di database e non complicare la logica di accesso ai dati con cache di file intermedie. Un buon server di database farebbe la cache da solo se i risultati sono memorizzabili nella cache. (Non sono sicuro di cosa sia il caso con mysql).

Se si verificano problemi di prestazioni, è necessario creare un profilo delle pagine per vedere i veri colli di bottiglia. Anche quando sei - come me - un fan dei codici ottimizzati, mettere un hardware più forte/più nell'equazione è più economico a lungo termine.

Se è ancora necessario utilizzare le cache, è consigliabile utilizzare una soluzione esistente, come memcached.