(не)Правильная постраничность (pagination) / Пишем соцсеть на Ruby On Rails 6 #4
Вставка
- Опубліковано 20 тра 2024
- Привет! В этом (очередном) выпуске мы продолжаем писать нашу соцсеть на Ruby On Rails 6, и в этот раз мы делаем pagination или постраничность для постов.
Исходники: github.com/overeng/rubysocial...
Видео о нагрузке на REST API, где я рассказываю о курсорной постраничности: • 4 способа снизить нагр...
Таймкоды
00:00 Почему OFFSET - плохо
02:35 Как работает курсорная пагинация (объяснение)
05:14 Объяснение кода
15:15 Некрасивые URL?
Спасибо! Интересно и доходчиво!!!
Отлично! Спасибо :)
5:10 Сортировка по возрастанию - она обычно по умолчанию, но если уж писать явно, но наверное не ASK а ASC?
Умница
отличное видео! подскажите на ваш взгляд какие преимущество руби перед пайтон, не могу определится что учить
зависит :) как язык мне больше нравится ruby, с точки зрения востребованности - наверное python лучше.
@@OverEngineer спасибо
А откуда вы взяли этот материал? Англоязычные блогеры ютуба?
Рубисты всегда нужны. НО где взять пять лет бэкгрануда и опыта?
Добавьте к пагинации фильтр или сортировку
Ех, придется переписать где использовал offset :)
Мне не интересна бэкэнд и фронтэнд разработка и я в ней ничего не понимаю, так что при просмотре я просто проматываю часть, где объясняется код.
:D
пагинация по скроллу мышкой - уродская. Когда нужно посмотреть подальше назад, нельзя просто задать в URL 20 страниц назад от текущей, а промотать мышкой 200 страниц не получится т.к. при этом прогружается контент всех 200 страниц. В итоге, далеко назад путем просмотра никто зайти не сможет. В итоге получаем что модерновая пагинация от id работает как бы эффективно, но смысл имеет только в небольшом диапазоне, где бы и тупо skip/offset прекрасно бы сработал. Нахожу только один вариант когда это будет работать не очень - если количество постов увеличивается очень быстро, и при нажатии на "страницу назад" мы увидим не только тот же пост что был и на прошлой, но и более новые :)
В livejournal классическая пагинация по offset, это естественно приводит к тому что при переходе назад довольно часто видишь и то что было, но это интуитивно понятно и не вызывает отторжения.
В фейсбуке пагинация какая-то модерновая, бесконечная лента, и бесит неимоверно, ибо никогда не понимаешь где ты находишься в ленте и как вернуть назад то место где ты только что был. Это образец отвратительной идеологии бомбардирования пользователя потоком информации в котором пользователь не имеет никаких механизмов по управлению этим потоком. К сожалению, сейчас это типа модный тренд.
100%
Как открыть 5-ю станицу находясь на 2-й? Это не "правильная" пагинация а подходящая для конкретного случая. В комментарии от постгрес "might be" это прям попытка заранее оправдается, а еще и в куче с точными данными "large". Помимо постгрес есть еще куча других БД там тоже такая проблема? С точки зрения пагинации по офсет пусть лимит 100 страница 1000-я я не думаю что могут быть проблемы с 100 000 офсет, и я думаю вы понимаете что 1000 страница это из разряда невероятного.
оракл делает какие-то оптимизации, но в целом операция неэффективна и в других БД.
Да, никак не попасть со 2-й на 5-ю. Если есть такое требование надо искать другие варианты, но лучше изменить требования :)
Насчет 1000-я страница - из разряда невероятного я бы поспорила. Таким запросом запросто можно заддосить, так зачем давать возможность положить вам сервер? Проблема есть не только с offset 100000, но уже с OFFSET 1000 по моему опыту. Если вам ок, что страница открывается секунду, то делайте так :)
А что значит оправдаться? Зачем им оправдываться и главное - перед кем?)) Перед людьми, которые пользуются качественным софтом забесплатно?
@@OverEngineer Ну изменить требования заказчика это не вариант, так как эти требования диктуют клиенты заказчика. Мне как пользователю тоже часто удобно работать с такой пагинацией ( список фильмов, и я просмотрел уже 6 страниц фильмов, и конечно когда есть возможность перехода с пропуском 2-3х страниц это удобно).
По поводу неэффективности offset - обоснуйте.
По поводу ddos тоже обоснуйте. А лучше хоть раз организуйте ddos (offset overload) на свой web проект.
"Проблема с оффсет 1000" - а точно проблема с офсет. Скажи размер таблицы x*y и количество запросов в секунду, я готов сейчас проверить. Я думаю проблема не в этом, да и вообще офсет это мелочь по сравнению 1000500 других проблем которые могут дать overload.
"Если вам ок, что страница открывается секунду, то делайте так :)" - у меня сейчас небольшой (в Ваших масштабах ) сервис с 2.2K запросов к БД (mysql ) в сек. Что то я не наблюдаю проблем с офсет
"А что значит оправдаться" - например тебе построили дом и говорят: может быть, если вы будете в доме танцевать, то дом обвалится.
Вот тайминги с сервера с 80% утилизации (эти данные не предназначены для пагинации, просто пример)
Отображение строк 0 - 29 (1106056 всего, Запрос занял 0.0030 сек.)
Отображение строк 2000 - 2019 (20 всего, Запрос занял 0.0071 сек.) 100 станица
Отображение строк 20000 - 20019 (20 всего, Запрос занял 0.0495 сек.) 1000 станица
Отображение строк 116020 - 116039 (20 всего, Запрос занял 0.2487 сек.) 5800 станица
Отображение строк 1106020 - 1106039 (20 всего, Запрос занял 3.6067 сек.)
(повтор ) Отображение строк 1106020 - 1106039 (20 всего, Запрос занял 0.0003 сек.) ой, а как же ddos.
А если нужен поиск по комментарием????
Еще раз у меня претензия к слову "правильная" пагинация.
>>По поводу неэффективности offset - обоснуйте.
Я привела цитату из доков + из собственного опыта. Ваши "бенчмарки" как раз иллюстрируют то что я говорю, даже несмотря на то что они сферические в вакууме :D Так же можно прибегнуть к помощи гугла, который вам расскажет много веселых историй по запросам "postgresql offset performance" и "mysql offset performance". Хорошо, что у вас нет проблем с offset, но это ни о чем не говорит.
>>ой, а как же ddos.
ну, на кеш полагаться - такое себе. не знаю точно как mysql кеширует, но оффсет можно и поменять, данные в таблице могут измениться - тогда кэш сбрасывается.
>>А если нужен поиск по комментарием????
а как это связано с пагинацией?
>>Еще раз у меня претензия к слову "правильная" пагинация.
Это ютуб :) вот у вас бомбануло от названия видео, вы его посмотрели и откомментили. Чего бы не произошло, если бы название было другим :)
@@OverEngineer Надо было назвать видео "Идеальная пагинация, все кто делает офсет лохи" )))))
"бенчмарки" я привел только для того что бы показать какая маленькая задержка на 1000 страницах (там пофиг какая sql БД)
Отсутствие проблем у меня с офсет, говорит о том что это можно, а иногда и нужно использовать
Скоростью повторного (закешированого) запроса, я хотел показать что ddos-ить по offset не так уж и просто.
Если будет поиск, то будет перебор всей таблицы, в таком случае скорость будет приблизительно одинаковая в обоих случаях.
Отличное было бы название, но момент упущен :D
Я не имела в виду, что оффсетную пагинацию использовать нельзя, это до сих пор самый популярный способ. Возможно в видео мое утверждение прозвучало излишне догматично. Идея видео была в том, чтобы показать два разных подхода и реализовать тот, что используется сейчас в высоконагруженных проектах типа твиттера и менее тривиальный (как сделать оффсет думаю всем понятно)
Я не программист и не понял о чем тут речь. НО дико бесит система фейсбука, где невозможно - как на нормальном форуме - сразу перейти на конкретный блок информации, как это сделано на форумах
нуднее можно придумать. Старайтесь.