AE
Прикинь сколько времени щелкает каунт для вашего любимого пагинатора?)
Size: a a a
2021 March 24
AE
если он есть. Есть такой в твиттере? Кроме как сохранить ссылку на конкретный твит?
Забудь про социалки уже
AE
самая тупая идея для пагинатора: сделать нечисловой и непорядковый ид
Вау, спросить забыли, да)
AG
Забудь про социалки уже
если мы говорим про реальную работу, там всегда есть и количество записей на странице, и пагинатор. любая CRM, ERP система идёт с ними
AE
если мы говорим про реальную работу, там всегда есть и количество записей на странице, и пагинатор. любая CRM, ERP система идёт с ними
С натяжкой, да. И оно люто тормозит
AG
С натяжкой, да. И оно люто тормозит
насколько люто?
AG
если не забуду, прогоню тесты завтра у себя, гляну числа, чтобы было о чем предметно говорить.
AE
select * from news, where id > N*10 где N номер страницы в пагинаторе
Кстати, нюанс. Наложи сюда сортировку и фильтрацию)
AG
Кстати, нюанс. Наложи сюда сортировку и фильтрацию)
мне кажется, или это не спортивно?)
AE
мне кажется, или это не спортивно?)
Почему это?) Ну не будет же пользователь тупо пялиться в экран и листать до посинения) ему нужна конкретная инфа) он возьмёт фильтр) отсортирует по полю с датой и временем, которое не совпадает по хронологии с датой и временем создания записи в бд)
Это реальность, никаких хаков)
Это реальность, никаких хаков)
AG
Почему это?) Ну не будет же пользователь тупо пялиться в экран и листать до посинения) ему нужна конкретная инфа) он возьмёт фильтр) отсортирует по полю с датой и временем, которое не совпадает по хронологии с датой и временем создания записи в бд)
Это реальность, никаких хаков)
Это реальность, никаких хаков)
окей
2021 March 25
S
с чего бы вдруг?
ну ... там смотря как реализовано =)
чтобы не росло надо вместо номера страницы передавать id элемента
и все элементы "после" должны монотонно возрастать
тогда IMHO можно вполне оптимизированно получить
чтобы не росло надо вместо номера страницы передавать id элемента
и все элементы "после" должны монотонно возрастать
тогда IMHO можно вполне оптимизированно получить
WHERE id>XXX LIMIT $page_sizeдаже на миллионах записей
AE
ну ... там смотря как реализовано =)
чтобы не росло надо вместо номера страницы передавать id элемента
и все элементы "после" должны монотонно возрастать
тогда IMHO можно вполне оптимизированно получить
чтобы не росло надо вместо номера страницы передавать id элемента
и все элементы "после" должны монотонно возрастать
тогда IMHO можно вполне оптимизированно получить
WHERE id>XXX LIMIT $page_sizeдаже на миллионах записей
Этот случай разобрали дальше)
S
Удачи с не числовыми или не порядковыми ид)
ну так это ж прошлый век везде GUID и прочую левоту вставлять =)
snowflake, sonyflake и прочие time based increment счетчики спасают
snowflake, sonyflake и прочие time based increment счетчики спасают
S
насколько люто?
ну, от RPS зависит, но в целом чтобы сделать тупой LIMIT X,Y
надо сначала прочитать X записей и потом отдать юзеру следующие Y
если у вас там реально десятки тысяч записей по WHERE фильтруется и хотя бы 200+ rps, вы начнете упираться в диски достаточно быстро, даже в NVMe ;)
но это IMHO
я давно уже MySQL \ Postgres на таких кейсах не мерял на современном железе... может и все ОК будет =)
особенно с NVMe
надо сначала прочитать X записей и потом отдать юзеру следующие Y
если у вас там реально десятки тысяч записей по WHERE фильтруется и хотя бы 200+ rps, вы начнете упираться в диски достаточно быстро, даже в NVMe ;)
но это IMHO
я давно уже MySQL \ Postgres на таких кейсах не мерял на современном железе... может и все ОК будет =)
особенно с NVMe
S
Кстати, нюанс. Наложи сюда сортировку и фильтрацию)
ну так фильтрация то по WHERE будет применена либо после id > N
если у вас других ключей нет
а сортировка она в ЛЮБЫХ раскладах после WHERE ;) то есть увеличит время конечно
но не настолько
если вам надо ORDER BY id DESC то может проще id < N сделать тогда?
если у вас других ключей нет
а сортировка она в ЛЮБЫХ раскладах после WHERE ;) то есть увеличит время конечно
но не настолько
если вам надо ORDER BY id DESC то может проще id < N сделать тогда?
S
Почему это?) Ну не будет же пользователь тупо пялиться в экран и листать до посинения) ему нужна конкретная инфа) он возьмёт фильтр) отсортирует по полю с датой и временем, которое не совпадает по хронологии с датой и временем создания записи в бд)
Это реальность, никаких хаков)
Это реальность, никаких хаков)
если есть индекс по полю с датой, то там в MySQL \ PostgreSQL вроде есть оптимизация как раз для такого случая
AE
ну, от RPS зависит, но в целом чтобы сделать тупой LIMIT X,Y
надо сначала прочитать X записей и потом отдать юзеру следующие Y
если у вас там реально десятки тысяч записей по WHERE фильтруется и хотя бы 200+ rps, вы начнете упираться в диски достаточно быстро, даже в NVMe ;)
но это IMHO
я давно уже MySQL \ Postgres на таких кейсах не мерял на современном железе... может и все ОК будет =)
особенно с NVMe
надо сначала прочитать X записей и потом отдать юзеру следующие Y
если у вас там реально десятки тысяч записей по WHERE фильтруется и хотя бы 200+ rps, вы начнете упираться в диски достаточно быстро, даже в NVMe ;)
но это IMHO
я давно уже MySQL \ Postgres на таких кейсах не мерял на современном железе... может и все ОК будет =)
особенно с NVMe
На 20 лямах с nvme начинает проседать
AE
ну так это ж прошлый век везде GUID и прочую левоту вставлять =)
snowflake, sonyflake и прочие time based increment счетчики спасают
snowflake, sonyflake и прочие time based increment счетчики спасают
Почему же прошлый век то?)
AE
ну так фильтрация то по WHERE будет применена либо после id > N
если у вас других ключей нет
а сортировка она в ЛЮБЫХ раскладах после WHERE ;) то есть увеличит время конечно
но не настолько
если вам надо ORDER BY id DESC то может проще id < N сделать тогда?
если у вас других ключей нет
а сортировка она в ЛЮБЫХ раскладах после WHERE ;) то есть увеличит время конечно
но не настолько
если вам надо ORDER BY id DESC то может проще id < N сделать тогда?
Речь не о времени, если говорим что отдавай нам после такого то ид, то ок, если передаешь страницу и говоришь id > x*n то все фильтры эту схему ломают ибо после фильтрации предыдущие страницы в 99.99999% случаев будут содержать меньше чем x*n записей
А теперь сортировка. Кто сказал что после сортировки порядок ид сохранится?)
Так что смысла от порядкового ид на пшик
А теперь сортировка. Кто сказал что после сортировки порядок ид сохранится?)
Так что смысла от порядкового ид на пшик