Това е проблем без напълно задоволително решение, защото се опитвате да комбинирате по същество несъвместими изисквания:
-
Изпращайте само необходимото количество данни на клиента при поискване, т.е. не можете да изтеглите целия набор от данни, след което да го пагинирате от страна на клиента.
-
Минимизирайте количеството състояние на клиент, което сървърът трябва да следи, за мащабируемост с голям брой клиенти.
-
Поддържайте различно състояние за всеки клиент
Това е ситуация тип „избери произволни две“. Трябва да направите компромис; приемете, че не можете да поддържате правилно състоянието на пагинация на всеки клиент, приемете, че трябва да изтеглите голям набор от данни на клиента или приемете, че трябва да използвате огромно количество сървърни ресурси, за да поддържате състоянието на клиента.
Има вариации в тези, които смесват различните компромиси, но всичко се свежда до това.
Например някои хора ще изпратят на клиента някои допълнителни данни, достатъчни, за да задоволят повечето изисквания на клиента. Ако клиентът надхвърли това, тогава получава неправилна пагинация.
Някои системи ще кешират състоянието на клиента за кратък период от време (с краткотрайни нерегистрирани таблици, временни файлове или каквото и да е), но изтичат бързо, така че ако клиентът не иска постоянно нови данни, той получава повредена пагинация.
И т.н.
Вижте също:
- Как да предоставим на API клиент с 1 000 000 резултата от база данни?
- Използване на „Курсори“ за страниране в PostgreSQL
- Итериране на голяма външна postgres db, манипулиране на редове, запис на изход в rails postgres db
- офсет/лимит оптимизация на производителността
- Ако PostgreSQL count(*) винаги е бавен, как да пагинирате сложни заявки?
- Как да върна примерен ред от база данни един по един
Вероятно бих приложил хибридно решение под някаква форма, като:
-
С помощта на курсор прочетете и незабавно изпратете първата част от данните на клиента.
-
Незабавно извличайте достатъчно допълнителни данни от курсора, за да удовлетворите 99% от изискванията на клиентите. Съхранявайте го в бърз, опасен кеш като memcached, Redis, BigMemory, EHCache, каквото и да е под ключ, който ще ми позволи да го извлека за по-късни заявки от същия клиент. След това затворете курсора, за да освободите ресурсите на DB.
-
Изтеглете кеша на базата на най-малко използваните наскоро, така че ако клиентът не продължи да чете достатъчно бързо, трябва да отиде да получи нов набор от данни от DB и пагинирането се променя.
-
Ако клиентът иска повече резултати от огромното мнозинство от своите връстници, пагинирането ще се промени в даден момент, когато превключите към четене директно от DB, а не от кеша, или генерирате нов по-голям кеширан набор от данни.
По този начин повечето клиенти няма да забележат проблеми с пагинирането и не е необходимо да изпращате огромни количества данни на повечето клиенти, но няма да разтопите своя DB сървър. Въпреки това, имате нужда от голям кеш, за да се разминете с това. Практическият му ефект зависи от това дали вашите клиенти могат да се справят с прекъсването на пагинацията - ако просто не е приемливо да прекъсвате пагинацията, тогава вие сте принудени да го правите от страна на DB с курсори, временни таблици, справяне с целия набор от резултати при първа заявка и т.н. Зависи също от размера на набора от данни и колко данни обикновено изисква всеки клиент.
