Dette er et problem uden en helt tilfredsstillende løsning, fordi du forsøger at kombinere i det væsentlige inkompatible krav:
-
Send kun den påkrævede mængde data til klienten on-demand, dvs. du kan ikke downloade hele datasættet og derefter paginere det på klientsiden.
-
Minimer mængden af tilstand pr. klient, som serveren skal holde styr på, for skalerbarhed med et stort antal klienter.
-
Oprethold forskellig tilstand for hver klient
Dette er en "vælg en hvilken som helst to" situation. Du skal gå på kompromis; accepter, at du ikke kan holde hver klients pagineringstilstand helt korrekt, accepter, at du skal downloade et stort datasæt til klienten, eller accepter, at du skal bruge en enorm mængde serverressourcer for at opretholde klienttilstand.
Der er variationer inden for dem, der blander de forskellige kompromiser, men det er det, det hele bunder i.
For eksempel vil nogle personer sende nogle til klienten ekstra data, nok til at tilfredsstille de fleste kundekrav. Hvis klienten overskrider det, så får den brudt paginering.
Nogle systemer vil cache klienttilstand i en kort periode (med kortvarige uloggede tabeller, midlertidige filer eller hvad som helst), men udløber den hurtigt, så hvis klienten ikke konstant beder om nye data, bliver den ødelagt paginering.
osv.
Se også:
- Hvordan giver man en API-klient 1.000.000 databaseresultater?
- Brug af "Markører" til at søge i PostgreSQL
- Iterér over store eksterne postgres db, manipuler rækker, skriv output til rails postgres db
- offset/limit performance optimization
- Hvis PostgreSQL-antal(*) altid er langsom, hvordan sideinddeles komplekse forespørgsler?
- Sådan returnerer du prøverækken fra databasen én efter én
Jeg ville sandsynligvis implementere en hybridløsning af en eller anden form, såsom:
-
Brug en markør, læs og send straks den første del af dataene til klienten.
-
Hent straks nok ekstra data fra markøren til at tilfredsstille 99 % af kundernes krav. Gem det i en hurtig, usikker cache som memcached, Redis, BigMemory, EHCache, hvad som helst under en nøgle, der lader mig hente den til senere anmodninger fra den samme klient. Luk derefter markøren for at frigøre DB-ressourcerne.
-
Udløb cachen på en basis, der er brugt mindst for nylig, så hvis klienten ikke bliver ved med at læse hurtigt nok, skal de hente et nyt sæt data fra DB'en, og pagineringen ændres.
-
Hvis klienten ønsker flere resultater end det store flertal af sine peers, vil paginering ændre sig på et tidspunkt, når du skifter til at læse direkte fra DB'en i stedet for cachen eller genererer et nyt større cachedatasæt.
På den måde vil de fleste klienter ikke bemærke pagineringsproblemer, og du behøver ikke sende enorme mængder data til de fleste klienter, men du vil ikke smelte din DB-server. Du har dog brug for en stor boofy cache for at slippe afsted med dette. Dets praktiske afhænger af, om dine klienter kan klare pagineringsbrud - hvis det simpelthen ikke er acceptabelt at bryde paginering, så sidder du fast med at gøre det på DB-siden med markører, midlertidige tabeller, klare hele resultatsættet ved første anmodning osv. Det afhænger også af datasættets størrelse og hvor meget data hver klient normalt kræver.