Memorizzazione nella cache a livello aziendale e memorizzazione nella cache a livello dati

Ho sempre lavorato su progetti in cui la cache è stata eseguita su DAL, in pratica proprio quando stai per effettuare la chiamata al database, controlla se i dati sono già presenti nella cache e, se lo è, semplicemente non effettua la chiamata e restituisce invece quei dati.

Di recente ho letto della memorizzazione nella cache a livello aziendale, quindi sostanzialmente la memorizzazione nella cache dell'intero oggetto aziendale. Un vantaggio che vedo subito è rappresentato dai tempi di risposta molto migliori.

Quando preferiresti l'uno all'altro? e la memorizzazione nella cache a livello aziendale è una pratica comune?

c# design design-patterns caching

— Emma
fonte

Le prestazioni delle tue applicazioni sono così critiche che la memorizzazione nella cache nel livello aziendale è preferibile rispetto alla chiarezza di una chiamata aggiuntiva a un repository o al livello DAL?

— JDT,

No non lo è e dopo aver letto le risposte, penso che mi limiterei a memorizzare nella cache solo dal DAL. Saluti.

— Emma,

Dovresti prendere in considerazione la memorizzazione nella cache sopra il tuo livello aziendale e pensare anche al ridimensionamento.

— AK_

Risposte:

Questo è probabilmente troppo ampio per una risposta definitiva. Personalmente, ritengo che un livello di accesso ai dati sia il posto migliore per la memorizzazione nella cache, semplicemente perché dovrebbe essere molto semplice: i record vanno e vengono e il gioco è fatto.

Un livello aziendale implementa molte regole aggiuntive di maggiore complessità, quindi è meglio se non deve anche gestire problemi di disponibilità per oggetto oltre a problemi di coerenza di più oggetti nella stessa classe (o anche lo stesso metodo) - che sarebbe essere una palese violazione dell'SRP.

(Certo, ho raggiunto quell'intuizione solo dopo che le mie lezioni di servizio erano diventate una complessità ingestibile quando hanno cercato di eseguire contemporaneamente la memorizzazione nella cache e la configurazione. Non esiste insegnante migliore dell'esperienza, ma il prezzo è decisamente elevato.)

— Kilian Foth
fonte

perché la memorizzazione nella cache deve essere complessa? può essere fatto con AOP e un paio di annotazioni. È ancora una violazione di SRP? perché non è quando fatto in DAL? anche IMHE non ho mai visto classi di servizio "troppo complesse" per essere memorizzate nella cache; indipendentemente dalla sua complessità, un servizio può essere visto come una scatola nera e il suo risultato può essere memorizzato nella cache

— user1075613

L'accesso ai dati e i livelli di persistenza / archiviazione sono luoghi irresistibilmente naturali per la memorizzazione nella cache. Stanno facendo gli I / O, rendendoli a portata di mano, un posto facile per inserire la cache. Oserei dire che quasi ogni strato di DAL o di persistenza, man mano che matura, riceverà una funzione di memorizzazione nella cache, se non è stato progettato fin dall'inizio.

Il problema è intento . I livelli DAL e di persistenza gestiscono costrutti di livello relativamente basso, ad esempio record, tabelle, righe e blocchi. Non vedono gli oggetti "business" o a livello di applicazione, o hanno molte informazioni su come vengono utilizzati a livelli più alti. Quando vedono una manciata di righe o una dozzina di blocchi che vengono letti o scritti, non è chiaro che rappresentino. "L'account Jones che stiamo attualmente analizzando" non sembra molto diverso da "alcuni dati di riferimento del tasso di imposizione di base di cui l'app ha bisogno una sola volta e a cui non farà riferimento di nuovo". A questo livello, i dati sono dati sono dati.

La memorizzazione nella cache a livello di DAL / persistenza rischia di avere i dati di riferimento fiscale "freddi" che si trovano lì, occupando inutilmente 12,2 MB di cache e spostando alcune informazioni sull'account che, di fatto, verranno utilizzate intensamente in un minuto. Anche i migliori gestori di cache hanno a che fare con scarse conoscenze delle strutture e connessioni dei dati di livello superiore e poca conoscenza di quali operazioni saranno presto disponibili, quindi ricadono negli algoritmi di stima .

Al contrario, la memorizzazione nella cache a livello di applicazione o di business non è così accurata. Richiede l'inserimento di operazioni di gestione della cache o suggerimenti nel mezzo di altre logiche aziendali, il che rende il codice aziendale più complesso. Ma il compromesso è: avere una maggiore conoscenza di come sono strutturati i dati a livello macro e quali operazioni stanno arrivando, ha un'opportunità molto migliore per approssimare l'efficienza di memorizzazione nella cache ottimale ("chiaroveggente" o "Bélády Min").

Indicare se inserire la responsabilità della gestione della cache nel codice aziendale / applicativo ha senso è una richiesta di giudizio e varia in base alle applicazioni. In molti casi, mentre è noto che i livelli DAL / persistenza non lo ottengono "perfettamente giusto", il compromesso è che possono fare un buon lavoro, che lo fanno in un modo architettonicamente "pulito" e molto più intensamente testabile e che la cattura di basso livello evita di aumentare la complessità del codice business / app.

Una minore complessità incoraggia una maggiore correttezza e affidabilità e un time-to-market più rapido. Questo è spesso considerato un grande compromesso: memorizzazione nella cache meno perfetta, ma codice aziendale più tempestivo e di migliore qualità.

— Jonathan Eunice
fonte

Grazie per la risposta. Dopo aver letto le tue risposte e quelle degli altri, penso che sicuramente non ho bisogno di memorizzare nella cache il livello aziendale. Aggiungerà semplicemente alla complessità complessiva del prodotto.

— Emma,

Un problema con il modello "layer" è che i meccanismi di memorizzazione nella cache efficienti devono spesso utilizzare informazioni che non sono disponibili su un singolo layer. Cosa penseresti, tuttavia, di avere un livello aziendale che trasmetta "suggerimenti" al livello dati sul suo "piano" generale? Il livello dati potrebbe inizialmente ignorare la maggior parte di tali suggerimenti, ma se si rilevasse un collo di bottiglia, si potrebbe aggiungere una logica che, se forniti alcuni suggerimenti, altererebbe le strategie di memorizzazione nella cache in un modo specifico per l'azienda.

— supercat

Ottimo punto, @supercat. Stavo per menzionare una strategia di suggerimento / pragma, ma la risposta era già lunga. Ma hai esattamente ragione. Il livello aziendale suggerisce livelli inferiori su come assegnare priorità alle cache, o "cosa aggiungere", è un modo abbastanza comune / utile per ottenere la memorizzazione nella cache di livello superiore senza fare in modo che il codice aziendale faccia tutto o sia troppo impigliato nella gestione del proprio archivio gerarchia.

— Jonathan Eunice,

@JonathanEunice: Una cosa bella dei suggerimenti è che il codice non deve fare molto con loro inizialmente. Molti sistemi presentano alcuni ovvi colli di bottiglia che dominano le loro prestazioni, ma può essere difficile prevedere se quali saranno abbastanza cattivi da importare. L'aggiunta di una piccola quantità di brutta logica di memorizzazione nella cache in alcuni punti critici può essere meglio che creare molta logica di memorizzazione nella cache in luoghi che non contano davvero.

— supercat

Esattamente. Soprattutto se si dispone già di una cache di basso livello "abbastanza buona" a livello di persistenza / accesso. Potresti aver bisogno solo di un po 'di informazioni aggiuntive sulle priorità per passare da "abbastanza buono" a "davvero buono".

— Jonathan Eunice,

La memorizzazione nella cache sul DAL è semplice e intuitiva

Il DAL è il livello centrale di accesso ai dati, il che significa che qualsiasi accesso a tutti i dati può essere controllato attraverso le classi lì. Poiché sia la lettura che la persistenza avvengono su quei livelli, è altrettanto facile cancellare o aggiornare le voci della cache in caso di modifiche.

La memorizzazione nella cache dell'attività è flessibile

La memorizzazione nella cache dell'azienda offre agli sviluppatori la flessibilità di determinare se l'utilizzo concreto di un oggetto trarrà beneficio dalla memorizzazione nella cache. A seconda della struttura dei servizi di back-end dell'applicazione o dei processi automatizzati potrebbero cambiare i dati memorizzati nella cache in altre parti. Con la memorizzazione nella cache di un'azienda, uno sviluppatore può determinare se un determinato oggetto business avrà possibili dati non aggiornati e otterrà prestazioni o se avrà lo stato più aggiornato di un oggetto business a scapito delle prestazioni.

— JDT
fonte