Десятки млн. записей с фасетным фильтром по пару десятку полей, с сортировкой по нескольким цифровым полям с номерной пагинацией.

[Yoskaldyr]

120000000, 10, то мы будем ждать (10 total, Query took 61.6894 seconds).

ну абсолютно ожидаемое время, исходя из количества строк.

Но если делать те выборки что надо, там выходит по 0.5-1 секунде на выбор. Просто так пагинировать такие объемы данных имхо редко когда надо, кто долистает до 100500 страницы?

А пользователям и не надо чтобы они листали до 100500 страницы И важно чтобы ответ рандомной страницы был в пределах заданного интервала. Все вопросы к сеошникам.

Мне кажется что у @Yoskaldyr нет полного ТЗ

В том то и дело что есть.

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

А где я писал что это товарный каталог? Проблема в том что в неделю обновляется/добавляется около 100К записей, да немного, но если обновляется, то это рааавномерно по всему списку.
.

 

[grigori]

мне-то что, когда у меня были такие задачи - я их решал, тебе хочется потолочь воду в ступе - ну, не решай )))

 

[Yoskaldyr]

мне-то что, когда у меня были такие задачи - я их решал, тебе хочется потолочь воду в ступе - ну, не решай )))

Просто все "решения" предложенные здесь здесь это не точные решения, а очень приблизительные и с большим количеством компромиссов. И все эти варианты - просто бояны, которые были известны давно (разве что не в курсе был насчет скорости постгре+jsonb+gin). Вопрос был задан довольно точно и было озвучено в чем основные проблемы. Но главное написать, что железо сейчас все супер и все переварит. Но могу расстроить - НЕТ не переварит.

Единственный обходной вариант, который может и прокатит, это уболтать сеошников на полный список страниц для очень ограниченного (основного/популярного) набора сортировок/фильтров (чтобы сохранять идшники в сортед сете в редисе и извлекать по позиции), а все остальные варианты лимитировать до 500 страниц и не более. Тогда все прекрасно отработает и на обычной базе. Но еще раз повторюсь - это не решение проблемы, а обходной костыль и компромисс.

 

[grigori]

судя по описанию, задача решается обычными средствами, но сходу у тебя не получилось, и ты зачем-то ушел в поиски серебрянной пули

да, кроме функциональных есть еще и нефункциональные требования - например, структура данных, по которым надо делать запросы, их количество, но ты их не описал

получается, что ты хочешь чтобы кто-то нашел решение задачи, нефункциональные требования которой ты не описал вообще, а функциональные частично - как настоящий эффективный менеджер!

новых инструментов не появилось потому что они не нужны
clickhouse, монга, индексы по json, redis - все это требует очень больших компромиссов

 

[Yoskaldyr]

@grigori в первом посте описаны абсолютно все требования (придумал не я а сеошники).

Не умничай плиз, я знаю что многие в клубе д`Артаньяны. Просто расскажи как на обычной базе сделать номерную пагинацию для любой страницы в постоянно обновляющейся таблице хотя бы в 20 лямов строк и сортировкой хотя-бы по паре полей (т.е. минимальное количество количество полей равно 3-м) чтобы это работало приемлемое время (0.1сек и меньше) для любой страницы? И понятно что без редиса (при минимальном количестве вариантов сортировок и на редисе элементарно). Можешь юзать любые хаки (размещение в памяти и т.д.)

 

[WMix]

Просто расскажи как на обычной базе сделать номерную пагинацию для любой страницы

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

 

[Yoskaldyr]

пагинация для ляма записей это не то что нужно человечеству

А кто говорил о человечестве? Это нужно роботам и они это любят (все вопросы к очень "умным" алгоритмам гугла и яндекса)

 

[WMix]

Это нужно роботам

так тем более, дели по дате/часу, зная что в каждом фасете ~1k и циклом, работает на ура. лопать

 

[Yoskaldyr]

@WMix Приходилось хоть раз общаться с альтернативно одаренными сеошниками-аутистами?
Если бы была такая простая задача была то я бы ничего здесь на форуме не спрашивал ибо примитивно и не стоит внимания.

 

[WMix]

@WMix Приходилось хоть раз общаться с альтернативно одаренными сеошниками-аутистами?

ну смотри, они просто хотят все строки, как будто поисковик сам нашел проиндексировать (это предположение).
им нужен инструмент.
а вот как он внутри работает им на самом деле все равно, тут как раз твои скилы проявить можно.
конструктивные предложения приветствуются

 

[AmdY]

1. Можно попробовать эластик
2. Постгрес с миллионами записей, пагинацией вкупе с поиском по лайку работает очень очень быстро (из моего опыта).
3. Если проблема в каунтах, их можно рассчитывать отдельно в асинхронном скрипте или повесить тригер и перещитывать при вставках для каждого набора фасетов.
4. Задача очень мутная, зачем столько данных выплёвывать поисковику. Он всё равно их не переварит, не говоря уже о пользователе листающим сотню тысяч страниц.

 

[Yoskaldyr]

ну смотри, они просто хотят все строки,

Не, если бы все так было просто. Я в курсе насчет необходимости существования всех ссылок на конкретные конечные страницы, но они дибилы, они мыслят успешными/неуспешными кейсами. У них конкретный тип ротинга навигации обычно разок стрельнет и вот они хотят его во всех остальных случаях - любое отклонение от заданного - говорят, ну это уже не наши проблемы, сами не сделали, значит не можем гарантировать результата (хотя какая гарантия результата в сео).

3. Если проблема в каунтах, их можно рассчитывать отдельно в асинхронном скрипте или повесить тригер и перещитывать при вставках для каждого набора фасетов.

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

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

Задача очень мутная, зачем столько данных выплёвывать поисковику. Он всё равно их не переварит, не говоря уже о пользователе листающим сотню тысяч страниц.

А разве бывают в сео не мутные задачи? лично я считаю что 99% сеошников это лютые дибилы с короной на голове.
Юзеры на сайте пролистают максимум 10 страниц и может пару раз тыкнут на последние, больше поиском пользуются.

Пока единственное что приходит в голову генерить такой полный список только всего списка и пары самых важных фильтров (т.к. в сумме комбинаций не много и можно запихнуть в редис), а все остальное лимитировать по количеству страниц.

 

[grigori]

@Yoskaldyr
1. я не выделываюсь, и пытаюсь быть доброжелательным
2. задача интересная
дай структуру своей "обычной" базы, пример запроса и количество измененных строк в сутки,
для абстрактного коня в вакуууме решения не бывает, а для реальной базы - вполне

 

[Yoskaldyr]

пример запроса

пример какого запроса?

Я выше давал пример запроса из подобной по размерам таблицы (количество полей +/- такое же, т.е. размер строки тоже +/- такой же)
Просто время выполнения на таких размерах всегда +/- одинаковое. Поэтому рассказы что у тебя все летало - ну не верю (при тупой пагинации при скипе на овердохера , ибо это тормоз по определению)

 

[grigori]

уговаривать и спорить не буду

 

[Yoskaldyr]

уговаривать и спорить не буду

просто ты так и не ответил как сделать чтобы запрос в таблице с 3-4 целочисленными полями с

LIMIT 15000000, 10

был быстрее 0.1 сек (даже без сортировки, хотя она там тоже нужна будет).

 

[weregod]

Такое пробовал: Why Order By With Limit and Offset is Slow - Faster Pagination in Mysql (eversql.com)?

 

[Yoskaldyr]

@weregod ну это же известное решение, если бы можно было применить, то я бы не стал даже задавать вопрос.

Еще раз повторюсь, я знаю что на обычных базах это НЕ сделать (физику чтения / копирования данных обмануть ну никак нельзя).
А спрашивал потому, что может кто-то юзал что-то экзотичное, и это можно сделать на какой-то экзотике типа редис сортед сет и подобной.

 

[fixxxer]

Магии не бывает.
Либо мириться со скоростью чтения-копирования (она вполне может быть приемлемой), либо кэшировать, либо менять постановку задачи.

Если это SEO, возможно, подойдет вообще прегенерация или разогрев кэша.

 

[Yoskaldyr]

Магии не бывает.

Я то в курсе, Но как пример подобной "магии" это сортед сет у редиса (частично решает, но не полностью)