Quali sono le best practice per memorizzare nella cache i risultati impaginati i cui ordini / proprietà possono cambiare?

Naviga le tue risposte
9

Qual è la procedura migliore per memorizzare nella cache i risultati di ricerca impaginati i cui ordini / proprietà possono essere modificati?

Dì, nella mia domanda, qualcuno vuole vedere gli ultimi 20 thread di discussione (su 10.000). Una richiesta verrebbe inviata al database, tramite servlet , per recuperare i primi 20 record dalla tabella dei thread di discussione come XML / JSON. Se poi vogliono vedere i prossimi 20, passano alla pagina successiva dei risultati e questo spara un'altra richiesta per ottenere il lotto successivo (limite e offset = 20, ecc.).

Per ridurre il carico del server e l'attesa del client, vorrei memorizzare nella cache le pagine precedenti dei risultati. Tuttavia, ho due domande:

  1. La tabella in cui sono mostrati i risultati può essere ordinata da più di un attributo (ad esempio, data di creazione del thread, autore di thread, data di ultimo post). Ciò significa che un'affermazione come "primi 20 risultati" non ha senso senza contesto (vale a dire, cosa ordiniamo). In che modo il front-end, quindi, comunica al back-end ciò che ha già caricato? Il mio primo pensiero è stato quello di utilizzare gli ID per ogni risultato, ma inviarli di nuovo al server sulle richieste successive (e filtrare i risultati basati su di essi) richiederebbe altrettanto tempo che inviare tutto alla cieca. Come posso fare questo?
  2. Cosa succede se un attributo di un risultato precedentemente restituito (vale a dire, la più recente-post-data) è cambiato? Abbiamo quindi bisogno di un modo per controllare ogni risultato per vedere se è stato modificato sul lato server dal momento che è stato effettuato il paging. Come posso fare questo?
posta goodsquishy 11.03.2013 - 17:04
fonte

3 risposte

7

Sembra che ciò di cui hai bisogno è un wrapper per tutti i parametri che definiscono una pagina (ad esempio, pageNumber , pageSize , sortType , totalCount , ecc.) e utilizzare questo oggetto DataRequest come chiave per il tuo meccanismo di caching. Da questo punto hai una serie di opzioni per gestire la cache:

  • Implementa una sorta di meccanismo di timeout per aggiornare la cache (in base alla frequenza con cui i dati cambiano).
  • Avere un listener che controlli le modifiche al database e aggiorna la cache basandosi sui parametri precedenti.
  • Se le modifiche vengono eseguite con lo stesso processo, puoi sempre contrassegnare la cache come obsoleta ad ogni modifica e controllare questo flag quando viene richiesta una pagina.

I primi due potrebbero coinvolgere un meccanismo dello scheduler da attivare su un intervallo o basato su un evento. L'ultimo potrebbe essere il più semplice se si dispone di un singolo punto di accesso ai dati.

Infine, come menzionato @DanPichelman, può rapidamente diventare un algoritmo eccessivamente complicato che supera i benefici, quindi assicurati che il guadagno di prestazioni giustifichi la complessità dell'algoritmo.

    
risposta data 11.03.2013 - 23:16
fonte
2

Solo un pensiero: nella tua chiamata al server, passa i soliti parametri più una serie di hash MD5 che rappresentano attualmente le pagine di dati precedentemente memorizzate nella cache.

La chiamata di ritorno conterrà tutti i dati consueti per la nuova pagina corrente, più gli aggiornamenti per eventuali pagine obsolete visualizzate in precedenza. Puoi usare il vecchio hash come chiave.

Consiglierei un sacco di prestazioni e amp; prima i test di temporizzazione - il tuo codice client sarà molto più complicato di quanto sarebbe se colpissi semplicemente il server per ogni pagina di dati. Assicurati che la complessità extra si traduca in un miglioramento significativo.

    
risposta data 11.03.2013 - 17:31
fonte
2

Probabilmente lo gestirò in questo modo:

  1. Tratta diversi ordini come sequenze diverse tutte insieme. Non valuterà la contabilità extra per tenere traccia di ciò che ogni cliente ha (o lo rimanda più e più volte).
  2. Ogni volta che le pagine utente, vengono visualizzate immediatamente dalla cache e allo stesso tempo inviano un GET al server che include un hash o un ultimo accesso. Il server invia solo una pagina intera se qualcosa è cambiato.
  3. Recupera dal server più di una pagina dell'interfaccia utente alla volta. Ad esempio, se l'interfaccia utente visualizza 20 voci, la query 60. Ho bisogno di testare questo, ma la mia aspettativa è che la dimensione di ritorno più efficiente sarà di solito più grande della quantità media di dati mostrati su una pagina. Ciò rende anche l'interfaccia utente molto reattiva per alcuni turni di pagina.
  4. Prefetch reslts quando sei vicino a un confine. Questo aiuta a mantenere quei tempi di caricamento veloci dalla cache.
risposta data 12.03.2013 - 05:09
fonte

Leggi altre domande sui tag

Dare una presentazione su "stile codice e motivi di progettazione" [chiuso] Qual è il problema con i letterali XML di Scala?