Комментарии 21
Это же не работает. Точнее работает, но выдает неверный результат.
По фильтру нашлось три страницы объектов из первого хранилища и четыре страницы из второй. Пользователю нужны сортированные данные, четвертая страница.
Да, вы правы, сортировка не будет работать, в предпоследнем абзаце это было указано:
Серьёзный минус - это невозможность использовать сортировку агрегированного списка объектов
Это не минус. Это неработа программы. Пользователи очень расстраиваются когда вместо сортировки получают ерунду какую-то.
может там ее и не было, сортировки этой
Несортированный список с пагинацией не имеет смысла. Даже в теории. БД может возвращать данные в любом порядке в этом случае.
это правда. Но это не значит, что сортировка была)
По факту позиции PostgreSQL будет выдавать те-же до апдейта записей или вакуума. Подозреваю, в остальных так-же, иначе это странно
Ну и гарантии, что пока мы кликаем не добавилось записей, и у нас стало больше/меньше записей, соответсвенно страницы изменились все-равно нет.
Т.е. пагинация работать будет нормально, если это редко обновляемые данные.
Надеюсь что вы это только в академических целях пишите.
Любой вывод данных пользователю без сортировки должен зарубаться на ревью. Ну или на тестировании. Въедливые ручные тестировщики новых фич полезны. Автотесты такое не видят.
В задаче не написали по чему сортировать? Сортируй по имени. Нет имени? Сортируй по номеру. Номера тоже нет? Сортируй по ID объектов. Его тоже нет? Тут пора что-то править глобально. Без PK жить совсем нельзя.
Да, сортировка по произвольному полю не требуется в моём кейсе. Сортировки объектов в рамках отдельной схемы по PK (используется UUID) достаточно, чтобы данные выводились стабильно.
Если требуется сортировка по произвольному полю, то, как уже упоминали в комментариях, без миграции данных в одну БД или других вариантов аггрегации (эластик) не обойтись.
Мне кажется, что в таком случае логично все просто лить в эластик/сфинкс (pgsync или похожим софтом для ваших БД)?
Ну и count это очень больно для БД. Все от количества данных, конечно, зависит. Но база вынуждена отсканировать всю-всю таблицу/таблицы для получения в целом бесполезного параметра.
Оно надо? Обычно достаточно знать, что есть сл. страница, или еще 2,3,n страниц.
Всегда было интересно, почему не делать пагинацию на клиенте? Неужели так сложно выгрузить 1000 товаров сразу, каждая запись меньше килобайта, а дальше браузер тянет картинки для отображаемых карточек. Это если интернет-магазин, например
А если товаров миллион?
Для типичного маркетплейса миллион позиций это реально вполне.
эээ .. ну по тому-что фронту не нужно 1000 записей?
А по факту там будет не тысяча, а как указали, миллион.
И сразу у вас задохнётся БД, а потом сеть. А потом и браузер клиента, но это уже не бэкендерские пробоемы)
Самому бэку создать 1000 обьектов на каждый запрос тоже накладно.
100 запросов в секунду считай 100 000 объектов в памяти одной ноды по одному апи.
А в сервисе еще и другие апи есть, которые тоже создают нагрузку.
Только ваш кейс с пажинацией создаёт в сто раз больше запросов к БД и на сети. При этом накладные расходы составляют большую часть нагрузки
И пользователю приходится ждать, пока его запрос обрабатывается при каждом перещёлкивании страницы результатов
Не факт что мне нужно увидеть 1000 товаров.
Я могу останоаиться на 10 и провалиться в него. Пойму что не подходит, вернусь обратно и запрошу снова 1000 товаров.
И так может повторяться много раз. И каждый раз буду запрашивать по 1000... Это оверхед. И по статистике человек редко проходит дальше определенного числа результатов выдачи...
Так в яндекс поиске большая часть людей не проходит дальше 1 стр. И нужно ли было им отдавать 1000 результатов? Только бд, сервис, сеть нагрузили бы.
это не правда, откуда большая нагрузка?
Более того, "вам не даст без фильтра вывести все позиции".
А когда окажется, что есть фильтр, покрывающий 99% позиций?
Будем городить костыли?
Ваша схема не работоспособна. Просто попробуйте применить ее на хоть сколько-нибудь большой базе
А в чем суть статьи? Мне кажется, решение не выглядит каким то неординарным или таким, до которого сложно дойти самому.
Плюс проблема с сортировкой - вот её решение было бы интересно
Подход к пагинации записей из разных источников