La soluzione migliore per migliorare la scalabilità è concentrarsi sulla rimozione delle chiamate al database, piuttosto che sulla rimozione dei dati dal database. (sebbene ciò possa accadere con cose come i dati di sessione)
Se la tua applicazione web è come la maggior parte che ho visto, un caricamento di una sola pagina attiva più richieste HTTP. Ciascuna di queste richieste è in grado di attivare il recupero dei dati di sessione, il recupero dei dettagli dell'utente e quindi anche il database per i dati per le informazioni che rispondono alla richiesta.
Ci sono alcune cose ovvie che possono essere fatte qui.
- I dati di sessione sono una cosa ovvia da spostare in un database NoSQL. È un'operazione Key / Value semplice e qualcosa come Riak è un buon posto dove archiviare questi dati.
- I dati del database come i dettagli dell'utente che vengono letti spesso, ma modificati raramente, sono anche una buona combinazione per l'archiviazione in Riak. Il modo in cui gestisci le condizioni di gara in caso di aggiornamenti varierà in base alla tua capacità di tollerare l'utilizzo di dati obsoleti.
- Allo stesso modo, probabilmente il tuo sito web ha molti altri dati che elabora in sezioni HTML che non variano da utente a utente. L'implementazione di un meccanismo di memorizzazione nella cache per archiviare il risultato di questa elaborazione può anche ridurre sostanzialmente gli accessi sul tuo database.
Alla fine però, scoprirai che alcune tabelle conterranno alcune informazioni critiche che non possono essere memorizzate nella cache. Quando raggiungi questo punto, le tue scelte sono di ridisegnare la struttura dei tuoi dati principali (che probabilmente non è possibile, l'avresti già fatto) o di buttare soldi (e hardware) per consentire al database di continuare a funzionare. In un ambiente con cui ho lavorato, questo significava un server MS SQL con 128 core con il disco più veloce e la massima quantità di memoria che poteva comprare.