Пагинация - основные способы и подводные камни
Пагинация — это метод разделения большого набора данных на порции. С точки зрения Frontend это всего лишь способ постранично вывести информацию. С точки зрения Backend пагинация скорее обязательна к использованию. Вместо передачи всего набора данных, сервер отправляет только малую часть, снижая нагрузку на БД и сеть, а так же улучшая общую пропускную способность и время отклика.
Если говорить о реализации, то выделяются 2 базовых способа:
1️⃣ Limit + Offset. Это самый распространенный метод пагинации, где используются параметры LIMIT и OFFSET из SQL-запросов (или аналоги из NoSQL БД). Например,
2️⃣ Курсорная пагинация, в которой обычно используется уникальный идентификатор последней полученной записи (курсор). Например, если сообщения в чате имеют строго возрастающие id, то запрос следующей порции сообщений получается через фильтрацию по id больше последнего загруженного (или меньше). Такой способ не начинает тормозить про отдаче 100500-ой страницы, а также стабильнее работает при частом создании/удалении данных.
Но дьявол кроется в деталях:
❗️При любом типе пагинации нельзя забывать про ограничения и дефолтное значение для параметра LIMIT. Без указания LIMIT многие БД будут отдавать все доступные данные... Чего вы явно не планируете для реально больших табличек 🤯
❗️Нельзя забывать про индексы в БД. Без индексов какую пагинацию не делай, а фильтрация и/или сортировка убьет любую скорость.
Используйте проверенные практики при реализации пагинации 🙏
До связи 🤟
Пагинация — это метод разделения большого набора данных на порции. С точки зрения Frontend это всего лишь способ постранично вывести информацию. С точки зрения Backend пагинация скорее обязательна к использованию. Вместо передачи всего набора данных, сервер отправляет только малую часть, снижая нагрузку на БД и сеть, а так же улучшая общую пропускную способность и время отклика.
Если говорить о реализации, то выделяются 2 базовых способа:
1️⃣ Limit + Offset. Это самый распространенный метод пагинации, где используются параметры LIMIT и OFFSET из SQL-запросов (или аналоги из NoSQL БД). Например,
SELECT * FROM users LIMIT 10 OFFSET 20 вернет 10 записей, начиная с 21-й. Этот подход очень прост в реализации. Основными недостатками являются: стремительное увеличение времени ответа с возрастание OFFSET и дублирование/пропуск части данных при их частом добавлении/удалении.2️⃣ Курсорная пагинация, в которой обычно используется уникальный идентификатор последней полученной записи (курсор). Например, если сообщения в чате имеют строго возрастающие id, то запрос следующей порции сообщений получается через фильтрацию по id больше последнего загруженного (или меньше). Такой способ не начинает тормозить про отдаче 100500-ой страницы, а также стабильнее работает при частом создании/удалении данных.
Но дьявол кроется в деталях:
❗️При любом типе пагинации нельзя забывать про ограничения и дефолтное значение для параметра LIMIT. Без указания LIMIT многие БД будут отдавать все доступные данные... Чего вы явно не планируете для реально больших табличек 🤯
❗️Нельзя забывать про индексы в БД. Без индексов какую пагинацию не делай, а фильтрация и/или сортировка убьет любую скорость.
Используйте проверенные практики при реализации пагинации 🙏
До связи 🤟
👍6🔥4🤔1
Создатель Redis возвращется в проект!
Выложил на хабре перевод поста из блога Сальваторе Санфилиппо (оригинального автора in-memory db Redis). После 4.5 лет отсутствия Сальваторе решил вернуться к своему детищу и рассуждает о проблемах лицензирования, расколе в сообществе редис, нейронных сетят и LLM, RAG и векторном поиске и, конечно, о том, чем бы он мог быть полезен комьюнити и проекту в целом.
https://habr.com/ru/articles/878184/
Приятного чтения 😊
Выложил на хабре перевод поста из блога Сальваторе Санфилиппо (оригинального автора in-memory db Redis). После 4.5 лет отсутствия Сальваторе решил вернуться к своему детищу и рассуждает о проблемах лицензирования, расколе в сообществе редис, нейронных сетят и LLM, RAG и векторном поиске и, конечно, о том, чем бы он мог быть полезен комьюнити и проекту в целом.
https://habr.com/ru/articles/878184/
Приятного чтения 😊
Хабр
Сальваторе Санфилиппо возвращается в Redis
С того места, где я остановился… Я не из тех, кто сильно привязывается к своим собственным проектам. Когда я решил уйти из Redis, это было примерно 1620 дней назад (около 4,44 года), я напрочь...
👍6🔥2🎉1
Переходим на Redis v8.0
Кажется, это первый за многие годы значимый релиз редиски! И вот почему:
История с лицензированием завершилась возвращением к "нормальной" Open Source лицензии - AGPLv3.
Команда проделала большую работу по оптимизации. Подробнее читайте у них в блоге, но ускорены как конкретные операции, так и общий latency снижен, общая пропускная способность увеличена. В общем чудо, бесплатное ускорение всем и каждому.
Наконец-то самые популярные доп. модули - такие как Search, Json, Bloom Filter - поставляются вместе с редисом из коробки. Это явный сдвиг парадигмы, в сторону более удобного и зрелого решения в духе "batteries included".
До связи 🤟
Кажется, это первый за многие годы значимый релиз редиски! И вот почему:
История с лицензированием завершилась возвращением к "нормальной" Open Source лицензии - AGPLv3.
Команда проделала большую работу по оптимизации. Подробнее читайте у них в блоге, но ускорены как конкретные операции, так и общий latency снижен, общая пропускная способность увеличена. В общем чудо, бесплатное ускорение всем и каждому.
Наконец-то самые популярные доп. модули - такие как Search, Json, Bloom Filter - поставляются вместе с редисом из коробки. Это явный сдвиг парадигмы, в сторону более удобного и зрелого решения в духе "batteries included".
До связи 🤟
🔥8👍3🤯1