Come impaginare i dati locali e remoti?

3

La mia squadra sta attualmente affrontando un problema che non sappiamo come affrontare.

Alcuni dettagli tecnici: utilizziamo Java 8, Hibernate, Spring, MySQL e AngularJS per il front-end.

Dobbiamo impaginare su un insieme combinato di dati locali e remoti. L'approccio che stiamo prendendo è il seguente:

  1. Esamina il nostro database locale poiché supportiamo la paginazione con Hibernate e recuperiamo i record impaginati.
  2. Prepara i record precedenti per richiamare un servizio REST per recuperare dettagli extra.
  3. Unisci tutti i dettagli e rendi i dati in una pagina web.

Questo approccio funziona bene quando stiamo facendo una ricerca per recuperare semplicemente più dettagli dal servizio remoto nei nostri dati locali.

Il problema sta nell'impossibilità di utilizzare i nostri dati locali come riferimento per la paginazione.

Esempio:
Diciamo che stiamo cercando tutte le auto SuperBrand in magazzino che usano il latte come carburante e hanno le ruote quadrate. Nel nostro DB locale disponiamo di auto da 10k da cui 2k sono SuperBrand. Quindi abbiamo questo volume iniziale di record 2k di dati locali che Hibernate riesce a impaginare in 20 pagine di 100 record ciascuna. Tuttavia, il cliente desidera solo i modelli di latte e ruote quadrate. In questo caso, abbiamo bisogno di invocare una terza parte che possa dirci di quelle 2k auto che soddisfano i criteri di ricerca. Il fatto è che non tutte le macchine funzionano con il latte e hanno ruote quadrate che potrebbero interrompere l'impaginazione. Inoltre, la terza parte non supporta la paginazione.

Per questo motivo, abbiamo scartato la possibilità di inviare a terzi i dati per pagina, cioè inviare i 100 record della pagina 1 e verificare con la terza parte, e quando il cliente seleziona la pagina 2, inviare il corrispondente 100 record e ricontrollare con la terza parte. Questo non è l'ideale perché dai 100 record della pagina 1 forse solo 10 seguono i criteri. Di conseguenza, mostreremmo solo 10 record a pagina 1. Forse i 100 record della pagina 2 soddisfano i criteri e potrebbero essere effettivamente visualizzati. Tuttavia, l'impaginazione è già interrotta dalla pagina 1.

L'altra possibilità è quella di inviare l'intero record 2k, invocare la terza parte, ridurre il volume di dati al numero rilevante di record che soddisfano i criteri di ricerca e creare un meccanismo di paginazione nel server per gestire e conservare i dati. Anche se concettualmente questo funzionerebbe, sono ancora preoccupato per le prestazioni di enormi volumi di dati.

Domande sull'argomento:

  • L'opzione precedente è un approccio valido?
  • Esiste la possibilità di trasmettere i dati anche con un servizio remoto, invece di eseguire l'impaginazione (tenere presente che le ricerche vengono avviate in AngularJS tramite le chiamate REST ai nostri server)?
  • Qualcuno potrebbe raccomandare un altro approccio?
posta pgs 02.02.2016 - 15:40
fonte

1 risposta

1

Questo è un problema difficile. Forse possiamo semplificarlo?

Il problema con il paging standard è che in genere devi sapere quanti risultati ci sono in totale - in modo che tu possa visualizzare i link alla pagina 1, pagina 2 ... pagina X. Forse puoi semplificare l'interfaccia utente in modo che tu possa solo avere il link "successivo" alla pagina successiva - il cliente non vede il numero totale di risultati (perché non è noto). Questo ci consente di non chiamare il servizio di terze parti per tutti i risultati del DB.

Ora, come funziona. La dimensione della pagina è diciamo 20. Otteniamo la richiesta per la pagina 1 - carichiamo diciamo i primi 100 risultati dal database che soddisfa il filtro DB - più del necessario, perché ci aspettiamo che il filtro di terze parti riduca significativamente questo numero. Inviamo questi 100 al servizio di terze parti, ci dice che 12 di questi soddisfano il filtro, quindi abbiamo bisogno di altri 8. Carichiamo altri 100 risultati (con offset corretto) dal database e richiamiamo di nuovo il servizio di terzi, ci dice che 15 di questi soddisfano il filtro. Questo è più del necessario: ne prendiamo solo 8 e li visualizziamo.

Ora dobbiamo visualizzare il link "next" per la seconda pagina, ma il trucco è che non indicizziamo la pagina nella richiesta URL (come? page = 2 "), ma indicizziamo l'ultimo record visualizzato (ad esempio" ? offset = 155 "). In questo caso particolare, l'offset deve essere l'offset del 20esimo elemento che soddisfa la condizione (quindi qualcosa tra 100 e 200).

Questo ovviamente non è perfetto - ha ancora peggiori prestazioni nei peggiori dei casi, ma almeno non sono lineari rispetto al numero di elementi nel database.

    
risposta data 02.02.2016 - 16:50
fonte

Leggi altre domande sui tag