Questo è un problema senza una soluzione perfettamente soddisfacente perché stai cercando di combinare requisiti essenzialmente incompatibili:
-
Invia solo la quantità di dati richiesta al client su richiesta, ovvero non puoi scaricare l'intero set di dati quindi impaginarlo lato client.
-
Riduci al minimo la quantità di stato per client di cui il server deve tenere traccia, per la scalabilità con un numero elevato di client.
-
Mantieni uno stato diverso per ogni cliente
Questo è un tipo di situazione "scegli due qualsiasi". Devi scendere a compromessi; accetta di non poter mantenere esattamente lo stato di impaginazione di ogni client, accetta di dover scaricare un grande set di dati sul client o accetta di dover utilizzare un'enorme quantità di risorse del server per mantenere lo stato del client.
Ci sono variazioni all'interno di quelli che mescolano i vari compromessi, ma è tutto a questo si riduce.
Ad esempio, alcune persone invieranno al cliente alcuni dati extra, sufficienti per soddisfare la maggior parte delle esigenze dei clienti. Se il client lo supera, l'impaginazione viene interrotta.
Alcuni sistemi memorizzano nella cache lo stato del client per un breve periodo (con tabelle non registrate di breve durata, file temporanei o altro), ma lo scadono rapidamente, quindi se il client non richiede costantemente nuovi dati, l'impaginazione viene interrotta.
ecc.
Vedi anche:
- Come fornire a un client API 1.000.000 di risultati di database?
- Uso dei "Cursori" per il paging in PostgreSQL
- Esegui l'iterazione su grandi db postgres esterni, manipola righe, scrivi output su rails db postgres
- ottimizzazione delle prestazioni offset/limite
- Se il conteggio di PostgreSQL (*) è sempre lento, come impaginare query complesse?
- Come restituire una riga di esempio dal database una per una
Probabilmente implementerei una soluzione ibrida di qualche forma, come:
-
Utilizzando un cursore, leggi e invia immediatamente la prima parte dei dati al cliente.
-
Recupera immediatamente abbastanza dati extra dal cursore per soddisfare il 99% dei requisiti dei clienti. Memorizzalo in una cache veloce e non sicura come memcached, Redis, BigMemory, EHCache, qualunque cosa sotto una chiave che mi permetta di recuperarlo per richieste successive dallo stesso client. Quindi chiudi il cursore per liberare le risorse del DB.
-
Fai scadere la cache su una base utilizzata meno di recente, quindi se il client non continua a leggere abbastanza velocemente deve recuperare un nuovo set di dati dal DB e l'impaginazione cambia.
-
Se il client desidera più risultati rispetto alla stragrande maggioranza dei suoi peer, l'impaginazione cambierà a un certo punto quando si passa alla lettura diretta dal DB anziché dalla cache o si genera un nuovo set di dati memorizzato nella cache più grande.
In questo modo la maggior parte dei client non noterà problemi di impaginazione e non dovrai inviare grandi quantità di dati alla maggior parte dei client, ma non scioglierai il tuo server DB. Tuttavia, hai bisogno di una grande cache boofy per farla franca. La sua praticità dipende dal fatto che i tuoi clienti siano in grado di far fronte all'interruzione dell'impaginazione:se semplicemente non è accettabile interrompere l'impaginazione, sei bloccato a farlo lato DB con cursori, tabelle temporanee, affrontando l'intero set di risultati alla prima richiesta, ecc. Dipende anche dalle dimensioni del set di dati e dalla quantità di dati solitamente richiesta da ciascun client.
