Implementazione del paging con più origini dati

Question

Implementazione del paging con più origini dati

#1 da (3 voti)
#2 da (1 voti)

2

Ho più origini dati che devo cercare e tornare al client (app web).

Ad esempio le fonti sono:

un indice di ricerca elastico
un database SQL

Esiste un modo efficace per eseguire il paging su due origini? Al momento sto cercando su uno, e quindi riducendo gli elementi ricercabili sul secondo, quindi solo il paging.

Opzioni alternative:

Idealmente, mi piacerebbe spostare una sorgente nell'altra, ma per vari motivi (ad esempio vincoli di spazio, prezzi, ecc.) questa non sembra un'opzione praticabile.
Disabilitare la ricerca fino a quando non viene inserito un criterio più raffinato, quindi il set di risultati restituito è garantito essere più piccolo e quindi il paging ha un'importanza minore.

Senza il paging, le prestazioni di questo aspetto dell'applicazione non sono grandi se i criteri di ricerca sono più aperti.

Esistono approcci per questa natura della ricerca?

design architecture pagination

posta Prabu 17.12.2017 - 20:40

fonte

2 risposte

Leggi altre domande sui tag design architecture pagination

Test di una classe che utilizza l'interfaccia esterna Creazione di campi interfaccia per iniettare vs Oggetti?

score 3 · Answer 1

Non penso che tu possa trovare qualcosa di meglio qui - fondamentalmente, stai cercando di risolvere un problema matematico irrisolvibile, che si unisce a due set ... senza unirsi a loro.

Tecnologie come ElasticSearch sono state progettate per affrontare questo problema disponendo di un singolo set di dati su cui lavorare.

Quindi, per come la vedo io, devo unirmi alle tue fonti di dati alimentando (almeno parzialmente) i dati in qualche terza cache o vivendo con dove sei ...

score 1 · Answer 2

Ottieni i dati in un singolo indice

La soluzione più semplice, senza problemi, senza problemi.

Ma poi di nuovo, perché qualsiasi Enterprise essere semplice?

Fornisci due set di risultati

Il meglio che puoi fare è fornire la prima pagina della risposta di ciascuna fonte. Se una delle due fonti si asciuga, è sufficiente restituire il set come vuoto. Non essere tentato di fornire più risultati dall'altra fonte, perché se la fonte secca si riempie improvvisamente, avrai un utente confuso sul motivo per cui alcuni risultati vengono ripetuti.

Unisci al client

In alternativa, se hai qualche misura di controllo sul client, puoi elencare le pagine dall'api da entrambe le fonti e utilizzare la metrica di qualità per ordinare i dati restituiti in pagine per l'utente. Dovrai assicurarti di avere l'elemento successivo (o la fine dei dati) da entrambe le fonti per assicurare una buona unione per quella pagina. Ciò imporrà un po 'di peso al computer degli utenti, quindi assicurati che il loro sistema sia all'altezza del carico previsto.

Hack disordinato - Qui per completezza evita se possibile.

C'è un brutto attacco che potresti fare. Fornirebbe l'illusione quasi di un'origine dati unificata. È comunque penosamente inefficiente e rompe l'incapsulamento di base . Aggiungi un parametro per origine dati per agire come offset dell'elemento. Per produrre una Pagina di N elementi, eseguire una query su ogni origine dati per gli elementi + N di offset. Unisci questi nell'API e restituisci i primi N elementi, insieme agli offset aggiornati per la pagina successiva.

Scelte

Combatti per un singolo indice e usa i due set di risultati come alternativa. Nascondere seriamente il fatto che potresti unire i dati al client o all'API. Non vorrai doverli annullare più tardi, e il team aziendale si aspetterà che tu possa farlo ora per ogni fonte di dati, e lamentarti amaramente quando non è più reattivo, e quali sono i costi nell'orario di lavoro da risolvere esso. È semplicemente meglio negarli ora e portare a termine il lavoro per supportare questo aspetto.