Dit is een probleem zonder een perfect bevredigende oplossing, omdat u in wezen onverenigbare vereisten probeert te combineren:
-
Stuur alleen de vereiste hoeveelheid gegevens on-demand naar de klant, d.w.z. u kunt niet de hele gegevensset downloaden en deze vervolgens aan de clientzijde pagineren.
-
Minimaliseer de hoeveelheid status per client die de server moet bijhouden, voor schaalbaarheid met grote aantallen clients.
-
Voor elke klant een andere status behouden
Dit is een "kies twee willekeurige" situatie. Je moet compromissen sluiten; accepteer dat u de pagineringsstatus van elke client niet precies goed kunt houden, accepteer dat u een grote dataset naar de client moet downloaden of accepteer dat u een enorme hoeveelheid serverbronnen moet gebruiken om de clientstatus te behouden.
Er zijn variaties binnen die de verschillende compromissen vermengen, maar daar komt het allemaal op neer.
Sommige mensen sturen de klant bijvoorbeeld sommige extra gegevens, genoeg om aan de meeste eisen van de klant te voldoen. Als de client dat overschrijdt, wordt de paginering verbroken.
Sommige systemen slaan de clientstatus voor een korte periode op in de cache (met niet-gelogde tabellen, tijdelijke bestanden of wat dan ook), maar laten deze snel verlopen, dus als de client niet constant om nieuwe gegevens vraagt, wordt de paginering verbroken.
enz.
Zie ook:
- Hoe kan ik een API-client 1.000.000 databaseresultaten bieden?
- Cursors gebruiken voor paginering in PostgreSQL
- Itereren over grote externe postgres db, rijen manipuleren, output schrijven naar rails postgres db
- offset/limiet prestatie-optimalisatie
- Als PostgreSQL count(*) altijd traag is, hoe moet u dan complexe query's pagineren?
- Een voorbeeldrij één voor één uit de database retourneren
Ik zou waarschijnlijk een hybride oplossing in een of andere vorm implementeren, zoals:
-
Gebruik een cursor om het eerste deel van de gegevens te lezen en onmiddellijk naar de klant te verzenden.
-
Haal onmiddellijk voldoende extra gegevens van de cursor op om aan 99% van de eisen van de klant te voldoen. Sla het op in een snelle, onveilige cache zoals memcached, Redis, BigMemory, EHCache, wat dan ook onder een sleutel waarmee ik het kan ophalen voor latere verzoeken door dezelfde client. Sluit vervolgens de cursor om de DB-bronnen vrij te maken.
-
Laat de cache op de minst recent gebruikte basis verlopen, dus als de client niet snel genoeg blijft lezen, moeten ze een nieuwe set gegevens uit de database halen en verandert de paginering.
-
Als de client meer resultaten wil dan de overgrote meerderheid van zijn collega's, zal de paginering op een gegeven moment veranderen als u overschakelt naar rechtstreeks lezen uit de DB in plaats van de cache of een nieuwe, grotere gegevensset in de cache genereert.
Op die manier zullen de meeste clients geen pagineringsproblemen opmerken en hoeft u geen grote hoeveelheden gegevens naar de meeste clients te sturen, maar u zult uw DB-server niet smelten. Je hebt echter een grote boofy cache nodig om hiermee weg te komen. Het praktische hangt ervan af of uw klanten kunnen omgaan met het breken van paginering - als het gewoon niet acceptabel is om paginering te verbreken, dan zit je vast aan het doen van het DB-side met cursors, tijdelijke tabellen, de hele resultatenset op eerste verzoek verwerken, enz. Het hangt ook af van de grootte van de dataset en hoeveel data elke klant gewoonlijk nodig heeft.