Tutto si riduce al costo della memoria veloce.
Se consideri quanto sia costosa la RAM, inizia ad avere senso utilizzarla per una piccola quantità di dati di cui hai bisogno in questo momento e mantenere tutto il resto non necessario su un mezzo più economico. Spesso, ci sono anche più livelli di questo:
- RAM per un piccolo sottoinsieme di dati che devi leggere il più velocemente possibile,
- SSD locale per un sottoinsieme di dati più ampio che vorresti essere in grado di leggere abbastanza velocemente,
- Dischi rigidi locali, archiviazione direttamente collegata o NAS per i dati che potresti dover leggere in un tempo ragionevole,
- I nastri per i dati che ci si aspetta di leggere solo in circostanze eccezionali.
Questo si applica ugualmente bene ai PC di casa, ai data closet e persino al cloud storage. Confronta il prezzo di un server AWS con cento gigabyte di RAM con un centinaio di gigabyte di storage S3 e un centinaio di gigabyte di storage Glacier. Se si desidera l'affidabilità S3 ma alla velocità di una RAM locale, è necessario aspettarsi che il prezzo sia di conseguenza elevato.
La cosa buona è che ci sono schemi specifici che sono progettati per funzionare con questa topologia (cioè un mezzo dati piccolo ma estremamente veloce non persistente combinato con mezzi sempre più grandi, persistenti e lenti). La cache è uno di questi: invece di dover manipolare i dati, cercando di indovinare quale deve essere inserito nella RAM, è sufficiente delegare questo lavoro a una soluzione di caching, scegliendo il giusto approccio di caching. E quando si tratta di approcci di memorizzazione nella cache, hai un'ampia scelta .
A parte i casi gestiti da una corretta memorizzazione nella cache, ci sono situazioni in cui è necessario un accesso ad alta velocità per eseguire un'attività (un esempio che viene in mente è il ripristino di un repository SVN da un backup, che è estremamente dipendente dalla velocità di supporto di memorizzazione). Nella maggior parte di queste situazioni, l'aspetto persistente è benvenuto, ma non richiesto: ad esempio, se il server si riavvia mentre stavo recuperando un repository SVN, posso sempre ripetere l'operazione (o farlo in parallelo su più server se ne vale la pena denaro).
Infine, ci sono situazioni (analisi scientifica, elaborazione statistica dei dati) in cui sarebbe bello avere enormi quantità di media di dati molto veloci. In questi casi, l'aspetto persistente è in genere irrilevante (con la riduzione della mappa, basta rifare il lavoro di una macchina che si è interrotta in modo imprevisto) e gli enormi costi di qualsiasi supporto veloce di solito si traducono in soluzioni SAN ordinarie.