Задача классическая - есть обычная пагинация отсортированного списка (сортируется по полю с индексом), за небольшим исключением список который надо обрабатывать состоит из 300К и более записей. Задача отобразить любую страницу из списка за вменяемое время.
Обычный LIMIT очень хорошо подходит для пагинации, но его основная проблема - с ростом числа пропускаемых полей увеличивается время запроса, даже когда идет выборка по индексу. И увеличивается ощутимо. Если к примеру запрос с LIMIT 10,20 выполнится практически моментально, то LIMIT 300000,300010 уже займет порядка секунды (даже если используются memory таблицы). А если список будет больше например 1млн записей????
А сейчас в вебе генерация всей страницы должна занимать значительно меньше 1 сек и неприемлемо когда sql-запрос будет занимать больше 1 сек.
Да все зависит от мощностей процессора, можно уменьшить время за счет наращивания мощностей. Но это не спортивно как-то.
Так же есть еще один момент - значения по которым сортируется список постоянно обновляются, не все сразу конечно, а 3-4 записи в сек. Поэтому делать расчет позиции по крону (раз минуту например), а потом использовать обычный where для выбора элементов конкретной страницы тоже не представляется возможным.
Кто сталкивался с такой проблемой и если сталкивался то как решал ее?
Вопрос навеян этой темой. Но т.к. проблема не создании пагинации, а в решении проблем производительности, то создаю новую тему. Да у меня используется mysql, но насколько я знаю такая проблема есть и у постгреса, поэтому пишу здесь, а не в разделе чисто mysql.
P.S. Вообще-то я уже решил как это сделать, и в продакшене уже больше года, но решение все еще не совсем нравится и кажется немного велосипедным, поэтому и спрашиваю может есть какие стандартные решения.
Обычный LIMIT очень хорошо подходит для пагинации, но его основная проблема - с ростом числа пропускаемых полей увеличивается время запроса, даже когда идет выборка по индексу. И увеличивается ощутимо. Если к примеру запрос с LIMIT 10,20 выполнится практически моментально, то LIMIT 300000,300010 уже займет порядка секунды (даже если используются memory таблицы). А если список будет больше например 1млн записей????
А сейчас в вебе генерация всей страницы должна занимать значительно меньше 1 сек и неприемлемо когда sql-запрос будет занимать больше 1 сек.
Да все зависит от мощностей процессора, можно уменьшить время за счет наращивания мощностей. Но это не спортивно как-то.
Так же есть еще один момент - значения по которым сортируется список постоянно обновляются, не все сразу конечно, а 3-4 записи в сек. Поэтому делать расчет позиции по крону (раз минуту например), а потом использовать обычный where для выбора элементов конкретной страницы тоже не представляется возможным.
Кто сталкивался с такой проблемой и если сталкивался то как решал ее?
Вопрос навеян этой темой. Но т.к. проблема не создании пагинации, а в решении проблем производительности, то создаю новую тему. Да у меня используется mysql, но насколько я знаю такая проблема есть и у постгреса, поэтому пишу здесь, а не в разделе чисто mysql.
P.S. Вообще-то я уже решил как это сделать, и в продакшене уже больше года, но решение все еще не совсем нравится и кажется немного велосипедным, поэтому и спрашиваю может есть какие стандартные решения.
