Riduci l'hit del server per i report memorizzando nella cache le risorse REST

1

Abbiamo un'applicazione convenzionale creata utilizzando moduli Web ASP.Net che utilizza SQL Server per il database. I report sono generati usando SSRS. Abbiamo una tabella principale denominata ManifestContainerDetails: questa tabella è destinata alla segnalazione. Quando la spedizione viene effettuata per un manifest, i dettagli dei componenti verranno memorizzati in questa tabella. Questi dati non vengono modificati dal sistema una volta effettuata la spedizione.

Ci sono molti rapporti basati su questa tabella. E molti utenti accedono allo stesso report. La tabella è enorme, ma la maggior parte delle volte gli utenti saranno interessati ai report per i manifesti inviati entro una settimana. Quindi, la maggior parte delle volte gli utenti richiedono la stessa risorsa con più rappresentazioni.

Questa sembra una buona opportunità per memorizzare la risorsa nella cache. E REST promette il caching utilizzando le capacità di http intermediaries . Cose Cache fanno - Ryan Tomayko e Cosa e dove sono le cache HTTP intermedie

Ho trovato un articolo Segnalazione REST - Eric Gropp che dice sulla creazione di un report da più risorse utilizzando XSLT.

Ora ho le seguenti domande, mentre sono di fronte a una lavagna nera, per progettare uno studio di fattibilità: -

  1. È un'idea fattibile creare il mio scenario sopra come servizio REST e creare rapporti basati su questo?
  2. Il caching è possibile in questo scenario?
  3. Sono disponibili strumenti per generare report avanzati basati su più risorse REST?
posta Lijo 14.07.2016 - 15:07
fonte

2 risposte

1

Now I have following questions, while I am in front of a black board, to design a feasibility study:-

Is it a feasible idea to make my above scenario as a REST service and create reports based on that? Is caching possible in such scenario? Is tools available to generate advanced reports based on multiple REST Resources?

Sembra che tu abbia bisogno di un data warehouse. Il caching è un'arma a doppio taglio e tende a lasciarti meravigliare più dell'implementazione. Se i clienti acquisiscono rapporti, non vogliono che i dati influenzino la tua applicazione tirando i dati del rapporto.

The table is huge – but most of the time users will be interested in reports for manifests that are shipped within last one week

Se si suddividono i dati in un'esportazione personalizzata, SSIS (ETL), ci si troverà a scrivere report su una singola origine dati e doverli modificare con la propria applicazione. È più semplice interrogare una tabella FACT con tutti i dati FACT e interrogare i record che vengono ancora pompati nel sistema con una pletora di bit flag.

    
risposta data 14.07.2016 - 16:07
fonte
-2

Potresti creare una vista nel server SQL che mostra solo i dati della scorsa settimana? Quindi i report sarebbero contro una visualizzazione sempre aggiornata di un set di dati più piccolo. Non è necessaria alcuna memorizzazione nella cache oltre al caching SQL di base del server SQL.

    
risposta data 14.11.2016 - 00:56
fonte

Leggi altre domande sui tag