Toto je problém bez dokonale uspokojivého řešení, protože se snažíte kombinovat v podstatě nekompatibilní požadavky:
-
Odesílejte klientovi na vyžádání pouze požadované množství dat, to znamená, že nemůžete stáhnout celou datovou sadu a poté ji stránkovat na straně klienta.
-
Minimalizujte množství stavu na klienta, které musí server sledovat, aby byla škálovatelnost s velkým počtem klientů.
-
Udržujte pro každého klienta jiný stav
Toto je situace typu „vyberte si ze dvou“. Musíte udělat kompromis; akceptujte, že nemůžete udržovat stav stránkování každého klienta přesně správný, akceptujte, že musíte do klienta stáhnout velkou sadu dat, nebo akceptujte, že k udržení stavu klienta musíte použít obrovské množství serverových prostředků.
Mezi nimi existují variace, které kombinují různé kompromisy, ale to je to, na čem se to všechno scvrkává.
Někteří lidé například pošlou klientovi nějaké data navíc, dostačující k uspokojení většiny požadavků klientů. Pokud to klient překročí, dostane přerušené stránkování.
Některé systémy uloží stav klienta na krátkou dobu do mezipaměti (s krátkými nezaprotokolovanými tabulkami, tempfiles nebo cokoli jiného), ale jeho platnost rychle vyprší, takže pokud klient neustále nepožaduje čerstvá data, přeruší se stránkování.
atd.
Viz také:
- Jak poskytnout klientovi API 1 000 000 výsledků databáze?
- Používání "kurzorů" pro stránkování v PostgreSQL
- Iterujte přes velkou externí postgres db, manipulujte s řádky, zapisujte výstup do rails postgres db
- optimalizace/omezení výkonu
- Pokud je PostgreSQL count(*) vždy pomalý, jak stránkovat složité dotazy?
- Jak vrátit ukázkový řádek z databáze jeden po druhém
Pravděpodobně bych implementoval hybridní řešení nějaké formy, jako:
-
Pomocí kurzoru načtěte a ihned odešlete první část dat klientovi.
-
Okamžitě načtěte z kurzoru dostatek dat navíc, abyste uspokojili 99 % požadavků klientů. Uložte to do rychlé, nebezpečné mezipaměti, jako je memcached, Redis, BigMemory, EHCache, cokoliv pod klíčem, který mi umožní načíst to pro pozdější požadavky stejného klienta. Poté zavřete kurzor, abyste uvolnili prostředky DB.
-
Vyprší platnost mezipaměti na nejméně používaném základě, takže pokud klient nečte dostatečně rychle, musí získat novou sadu dat z DB a stránkování se změní.
-
Pokud klient chce více výsledků než naprostá většina jeho kolegů, stránkování se v určitém okamžiku změní, když přepnete na čtení přímo z DB místo z mezipaměti nebo vygenerujete novou větší datovou sadu uloženou v mezipaměti.
Tímto způsobem si většina klientů nevšimne problémů se stránkováním a vy nemusíte většině klientů posílat obrovské množství dat, ale nezničíte svůj DB server. K tomu však potřebujete velkou nafoukanou mezipaměť. Praktické to závisí na tom, zda se vaši klienti dokážou vyrovnat s přerušením stránkování – pokud je prostě nepřijatelné přerušit stránkování, pak to musíte udělat na straně DB s kurzory, dočasnými tabulkami, zvládnout celou sadu výsledků na první žádost atd. Záleží také na velikosti datové sady a na tom, kolik dat každý klient obvykle vyžaduje.