(не)Правильная постраничность (pagination) / Пишем соцсеть на Ruby On Rails 6 #4

[@vladimiraksenov5548]

5:10 Сортировка по возрастанию - она обычно по умолчанию, но если уж писать явно, но наверное не ASK а ASC?

[@goludg]

отличное видео! подскажите на ваш взгляд какие преимущество руби перед пайтон, не могу определится что учить

[@OverEngineer]

зависит :) как язык мне больше нравится ruby, с точки зрения востребованности - наверное python лучше.

[@goludg]

@@OverEngineer спасибо

[@CryptoGenetic]

Спасибо! Интересно и доходчиво!!!

[@shortscute7857]

Рубисты всегда нужны. НО где взять пять лет бэкгрануда и опыта?

[@ДмитрийНормов-ю6ц]

А откуда вы взяли этот материал? Англоязычные блогеры ютуба?

[@vladimiraksenov5548]

пагинация по скроллу мышкой - уродская. Когда нужно посмотреть подальше назад, нельзя просто задать в URL 20 страниц назад от текущей, а промотать мышкой 200 страниц не получится т.к. при этом прогружается контент всех 200 страниц. В итоге, далеко назад путем просмотра никто зайти не сможет. В итоге получаем что модерновая пагинация от id работает как бы эффективно, но смысл имеет только в небольшом диапазоне, где бы и тупо skip/offset прекрасно бы сработал. Нахожу только один вариант когда это будет работать не очень - если количество постов увеличивается очень быстро, и при нажатии на "страницу назад" мы увидим не только тот же пост что был и на прошлой, но и более новые :) В livejournal классическая пагинация по offset, это естественно приводит к тому что при переходе назад довольно часто видишь и то что было, но это интуитивно понятно и не вызывает отторжения. В фейсбуке пагинация какая-то модерновая, бесконечная лента, и бесит неимоверно, ибо никогда не понимаешь где ты находишься в ленте и как вернуть назад то место где ты только что был. Это образец отвратительной идеологии бомбардирования пользователя потоком информации в котором пользователь не имеет никаких механизмов по управлению этим потоком. К сожалению, сейчас это типа модный тренд.

[@halforhalf-fo4fe]

100%

[@Edvard-Aliev]

Отлично! Спасибо :)

[@evgeniybudaev1690]

Добавьте к пагинации фильтр или сортировку

[@ЯрославМосцеев-р7л]

Умница

[@ЕвгенийФедоров-х6г]

Как открыть 5-ю станицу находясь на 2-й? Это не "правильная" пагинация а подходящая для конкретного случая. В комментарии от постгрес "might be" это прям попытка заранее оправдается, а еще и в куче с точными данными "large". Помимо постгрес есть еще куча других БД там тоже такая проблема? С точки зрения пагинации по офсет пусть лимит 100 страница 1000-я я не думаю что могут быть проблемы с 100 000 офсет, и я думаю вы понимаете что 1000 страница это из разряда невероятного.

[@OverEngineer]

оракл делает какие-то оптимизации, но в целом операция неэффективна и в других БД. Да, никак не попасть со 2-й на 5-ю. Если есть такое требование надо искать другие варианты, но лучше изменить требования :) Насчет 1000-я страница - из разряда невероятного я бы поспорила. Таким запросом запросто можно заддосить, так зачем давать возможность положить вам сервер? Проблема есть не только с offset 100000, но уже с OFFSET 1000 по моему опыту. Если вам ок, что страница открывается секунду, то делайте так :) А что значит оправдаться? Зачем им оправдываться и главное - перед кем?)) Перед людьми, которые пользуются качественным софтом забесплатно?

[@ЕвгенийФедоров-х6г]

@@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. А если нужен поиск по комментарием???? Еще раз у меня претензия к слову "правильная" пагинация.

[@OverEngineer]

>>По поводу неэффективности offset - обоснуйте. Я привела цитату из доков + из собственного опыта. Ваши "бенчмарки" как раз иллюстрируют то что я говорю, даже несмотря на то что они сферические в вакууме :D Так же можно прибегнуть к помощи гугла, который вам расскажет много веселых историй по запросам "postgresql offset performance" и "mysql offset performance". Хорошо, что у вас нет проблем с offset, но это ни о чем не говорит. >>ой, а как же ddos. ну, на кеш полагаться - такое себе. не знаю точно как mysql кеширует, но оффсет можно и поменять, данные в таблице могут измениться - тогда кэш сбрасывается. >>А если нужен поиск по комментарием???? а как это связано с пагинацией? >>Еще раз у меня претензия к слову "правильная" пагинация. Это ютуб :) вот у вас бомбануло от названия видео, вы его посмотрели и откомментили. Чего бы не произошло, если бы название было другим :)

[@ЕвгенийФедоров-х6г]

@@OverEngineer Надо было назвать видео "Идеальная пагинация, все кто делает офсет лохи" ))))) "бенчмарки" я привел только для того что бы показать какая маленькая задержка на 1000 страницах (там пофиг какая sql БД) Отсутствие проблем у меня с офсет, говорит о том что это можно, а иногда и нужно использовать Скоростью повторного (закешированого) запроса, я хотел показать что ddos-ить по offset не так уж и просто. Если будет поиск, то будет перебор всей таблицы, в таком случае скорость будет приблизительно одинаковая в обоих случаях.

[@OverEngineer]

Отличное было бы название, но момент упущен :D Я не имела в виду, что оффсетную пагинацию использовать нельзя, это до сих пор самый популярный способ. Возможно в видео мое утверждение прозвучало излишне догматично. Идея видео была в том, чтобы показать два разных подхода и реализовать тот, что используется сейчас в высоконагруженных проектах типа твиттера и менее тривиальный (как сделать оффсет думаю всем понятно)

[@СергейПанов-з3ц]

Мне не интересна бэкэнд и фронтэнд разработка и я в ней ничего не понимаю, так что при просмотре я просто проматываю часть, где объясняется код.

[@OverEngineer]

:D

[@Andriy063]

Ех, придется переписать где использовал offset :)

[@managerilya9810]

Я не программист и не понял о чем тут речь. НО дико бесит система фейсбука, где невозможно - как на нормальном форуме - сразу перейти на конкретный блок информации, как это сделано на форумах

[@mikhailmusofranov3943]

нуднее можно придумать. Старайтесь.