Devo memorizzare nella cache i dati o accedere al database?

Non ho lavorato con alcun meccanismo di memorizzazione nella cache e mi chiedevo quali fossero le mie opzioni nel mondo .net per il seguente scenario.

Fondamentalmente abbiamo un servizio REST in cui l'utente passa un ID di una categoria (cartella think) e questa categoria può avere molte sottocategorie e ciascuna delle sottocategorie potrebbe avere 1000 di contenitori multimediali (oggetti di riferimento del file think) che contengono informazioni su un file che potrebbe trovarsi su un server NAS o SAN (in questo caso i file sono video). La relazione tra queste categorie è archiviata in un database insieme ad alcune regole di autorizzazione e metadati relativi alle sottocategorie.

Quindi dal punto di vista dell'interfaccia utente abbiamo un controllo ad albero caricato pigro che è guidato dall'utente facendo clic su ogni sottocartella (pensa a Windows Explorer). Una volta arrivati ​​a un URL del file video, possono quindi guardare il video.

Il numero di utenti potrebbe crescere fino ai 1000 e le sottocategorie e i video potrebbero essere nei 10000 man mano che il sistema cresce.

La domanda è: dovremmo continuare a lavorare al momento in cui ogni richiesta raggiunge il database o dovremmo pensare di memorizzare nella cache i dati?

Stiamo utilizzando IIS 6/7 e Asp.net.

Innanzitutto, assicurati che il codice sia partizionato in modo tale che il tuo fornitore di dati possa essere commutato facilmente. Stiamo parlando della segregazione delle interfacce e degli altri principi SOLID qui.

Successivamente è necessario conoscere la risposta a quanto segue:

1) I dati cambieranno frequentemente? 2) L'applicazione esegue il polling frequente del servizio REST per ottenere questi aggiornamenti? 3) Il database è utilizzato per altri scopi? 4) Sei a conoscenza di eventuali problemi di prestazioni attuali? 5) I dati vengono aggiornati dall'applicazione e tali aggiornamenti devono essere riflessi nell'app?

La cosa interessante è che usando il database, tecnicamente stai già memorizzando nella cache i dati. Questo è ciò che fa un database. Molta ricerca e sviluppo contribuisce a rendere il database il più veloce possibile nel recupero dei dati. Ad esempio, utilizza la propria cache di memoria per i dati utilizzati di frequente.

Quindi chiediti cosa speri di ottenere scambiando i provider di cache? E quali sono le attuali limitazioni che devono essere affrontate?

Se al momento non si verificano rallentamenti, direi semplicemente "no, non è necessario cambiare".

È un argomento davvero grande. Le cache tendono a fare davvero bene quando i dati devono essere distribuiti geograficamente, ma c'è un enorme sovraccarico in termini di gestione.

Sto realizzando un progetto nel momento in cui prendo esattamente lo stesso tipo di decisioni.

La mia soluzione finora è usare solo il database e colpirlo molto con richieste di polling da ciascun client. Sembra schifoso, ma scala (nei test) molto più di quanto avrò bisogno, il codice è molto semplice.

Detto questo, il mio codice utilizza una sorta di modello di repository che estrae il provider di dati dell'applicazione principale dal codice del database. Se volessi scambiare un provider di cache come GemFire, avrei bisogno di una piccola quantità di codice da fare.

In realtà non ci sono abbastanza informazioni, secondo i commenti di Thorbjørn.

La memorizzazione nella cache, se eseguita in modo errato, può causare molto dolore a te e ai tuoi utenti. Assicurati di doverti preoccupare della memorizzazione nella cache prima di complicare eccessivamente l'applicazione.

Quindi, in assenza di informazioni che indicano che è davvero necessario memorizzare nella cache, non memorizzare nella cache.

[Regola generale di ottimizzazione: se devi chiedere se devo fare qualcosa, la risposta è no] *
* Sarebbe una dichiarazione, non una domanda, nella maggior parte dei luoghi in cui la risposta è sì.