Memorizzazione nella cache a livello aziendale vs Memorizzazione nella cache a livello dati

33

Ho sempre lavorato su progetti in cui la memorizzazione nella cache è stata eseguita su DAL, in pratica proprio quando si sta per effettuare la chiamata al database, si verifica se i dati sono già presenti nella cache e, in caso affermativo, semplicemente non lo fanno la chiamata e invece restituisce quei dati.

Recentemente ho letto sulla memorizzazione nella cache a livello aziendale, quindi fondamentalmente la memorizzazione nella cache di tutti gli oggetti di business. Un vantaggio che posso vedere immediatamente sono tempi di risposta molto migliori.

Quando preferiresti uno rispetto all'altro? e la memorizzazione nella cache di Business Layer è una pratica comune?

    
posta Emma 05.02.2015 - 13:57
fonte

3 risposte

28

Probabilmente è troppo generico per una risposta definitiva. Personalmente, ritengo che un livello di accesso ai dati sia il posto migliore per il caching, semplicemente perché dovrebbe essere molto semplice: i record vanno e vengono e questo è quanto.

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

(Naturalmente, ho raggiunto questa intuizione solo dopo che le mie classi di servizio erano diventate una complessità ingestibile quando hanno provato a eseguire contemporaneamente la memorizzazione nella cache e la configurazione. Non esiste insegnante migliore dell'esperienza, ma il prezzo è sicuro.) p>     

risposta data 05.02.2015 - 14:01
fonte
24

I livelli di accesso ai dati e di persistenza / archiviazione sono luoghi naturali irresistibilmente per il caching. Stanno facendo gli I / O, rendendoli pratici e facili da inserire nella cache. Immagino che quasi ogni livello DAL o di persistenza, dato che maturi, abbia una funzione di caching - se non è progettato in questo modo sin dall'inizio.

Il problema è intent . I livelli DAL e di persistenza trattano con costrutti di livello relativamente basso, ad esempio record, tabelle, righe e blocchi. Non vedono gli oggetti "business" o layer di livello applicativo o hanno una visione approfondita di come vengono utilizzati a livelli più alti. Quando vedono una manciata di righe o una dozzina di blocchi letti o scritti, non è chiaro che rappresentino. "L'account Jones che stiamo analizzando al momento" non sembra molto diverso da "alcuni dati di riferimento sulla tassazione di base di cui l'app ha bisogno solo una volta e ai quali non farà più riferimento". A questo livello, i dati sono dati sono dati.

La memorizzazione nella cache del livello del livello DAL / persistenza presenta i dati di riferimento fiscali "freddi" che si trovano lì, occupano inutilmente 12,2 MB di cache e sostituiscono alcune informazioni sull'account che verranno utilizzate in modo intensivo in appena un minuto. Persino i migliori gestori di cache hanno a che fare con scarse conoscenze delle strutture e delle connessioni dati di livello superiore e non si capiscono le operazioni in arrivo, quindi ritornano a algoritmi di congestione .

Al contrario, il caching a livello di applicazione o di business non è così semplice. Richiede l'inserimento di operazioni di gestione della cache o suggerimenti nel mezzo di altre logiche di business, 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 caching ottimale ("chiaroveggente" o "Bélády Min").

Se l'inserimento della responsabilità di gestione della cache nel codice business / dell'applicazione ha senso è un giudizio, e varierà in base alle applicazioni. In molti casi, anche se è risaputo che i livelli DAL / persistenza non riescono ad avere "perfettamente ragione", il compromesso è che possono fare un buon lavoro, che lo fanno in modo architettonicamente "pulito" e molto più intensamente testabile e questa cattura a basso livello evita l'aumento della 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 ottimo compromesso: meno cache perfetta, ma un codice aziendale di migliore qualità e più tempestivo.

    
risposta data 05.02.2015 - 16:38
fonte
14

La memorizzazione nella cache del DAL è semplice e intuitiva

Il tuo DAL è il livello di accesso ai dati centrale, il che significa che tutti gli accessi ai dati possono essere controllati attraverso le classi lì. Poiché sia la lettura che la persistenza avvengono su questi livelli, è altrettanto facile cancellare o aggiornare le voci della cache man mano che si verificano cambiamenti.

La memorizzazione nella cache dell'azienda è flessibile

Il caching sul business offre agli sviluppatori la flessibilità di determinare se l'utilizzo concreto di un oggetto trarrà vantaggio dalla memorizzazione nella cache. A seconda della struttura dei servizi back-end dell'applicazione o dei processi automatizzati, i dati possono essere modificati in altre parti. Con la memorizzazione nella cache del business uno sviluppatore può determinare se un determinato oggetto business può avere dati obsoleti e ottenere prestazioni, o avere lo stato più aggiornato di un oggetto business a scapito delle prestazioni.

    
risposta data 05.02.2015 - 15:41
fonte

Leggi altre domande sui tag