-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
Пагинация и производительность LIMIT на больших списках.
- Автор темы Yoskaldyr
- Дата начала
Ну если запись добавляется на первой странице, то надо перестроить кеш до последней, т.к. сдвигается все вниз и все страницы соотвественно будут другими
Не кеш, а именно индекс. Просто в качестве индекса используется редис, где есть выборка записи по порядковому номеру.
Значит у меня абсолютное решение
Или почти абсолютное в рамках 2млн записей, но все равно не нравится на все 100%
Можно сделать и чисто на mysql - вариант с кроном и расчетом номеров страниц пакетно, в отдельную таблицу снепшотов, а при отображении просто работать с последним снепшотом. Но этот подход мне нравится еще меньше, т.к. сильно усложняет логику приложения. А все должно быть по возможности просто.
Причем здесь кеш??? Вы или не поняли вообще как работает, или Вы с редисом не работали или если и работали, то похоже не использовали расширенный функционал (хеши, сортированные списки, pubsub и т.д.), а не только в качестве key value хранилища.
Решение на чисто mysql с генерацией таблицы-снимка можно назвать решением с использованием кеша, при работе с сортированными списками редиса - однозначно НЕТ! Тогда уже и mysql и postgresql сразу надо называть кешами на все случаи жизни.
я думаю, что здесь спор исключительно о терминологии.
Я тоже считаю, что для дублирования имеющихся данных на ресурсе с меньшим временем доступа лучше всего подходит слово "кэш".
Но если автору оно по каким-то причинам не нравится, он имеет право называть как угодно. Главное не спорить из-за названия.
Я тоже считаю, что для дублирования имеющихся данных на ресурсе с меньшим временем доступа лучше всего подходит слово "кэш".
Но если автору оно по каким-то причинам не нравится, он имеет право называть как угодно. Главное не спорить из-за названия.
Фанат
В данной ситуации проблема не с временем доступа. Проблема в функционале.
И редис используется потому что тот же мемкеш (классика key-value хранилищ и классика кеширующего бекэнда) этого не умеет.
Mysql почти умеет (т.е. limit это не совсем выборка по конкретному номеру, а просто пропуск первых значений, поэтому медленно при больших лимитах).
Просто лично я считаю что неправильно считать что-то кешем потому что это быстрее другой технологии. Точно также можно считать что таблицы myisam кеш по сравнению с таблицами innodb в одних ситуациях и наоборот innodb кеш для myisam в других.
Да в общем кеш - это память/хранилище с более быстрым доступом и если говорить обобщенно, то согласен (но тогда и сам mysql кеш тоже)
Но обычно под кешем в вебе понимают key-value кеш с временем жизни (если упрощенно)
В данной ситуации проблема не с временем доступа. Проблема в функционале.
И редис используется потому что тот же мемкеш (классика key-value хранилищ и классика кеширующего бекэнда) этого не умеет.
Mysql почти умеет (т.е. limit это не совсем выборка по конкретному номеру, а просто пропуск первых значений, поэтому медленно при больших лимитах).
Просто лично я считаю что неправильно считать что-то кешем потому что это быстрее другой технологии. Точно также можно считать что таблицы myisam кеш по сравнению с таблицами innodb в одних ситуациях и наоборот innodb кеш для myisam в других.
Да в общем кеш - это память/хранилище с более быстрым доступом и если говорить обобщенно, то согласен (но тогда и сам mysql кеш тоже)
Но обычно под кешем в вебе понимают key-value кеш с временем жизни (если упрощенно)
Несогласен!ты, когда ешь суп, используешь ложку.
значит ты - ложка.
Логическая ошибочка у Вас
Если бы я написал так:
то да - тогда Ваше утверждение было бы верным
MiksIr
miksir@home:~$
Если мы дублируем данные и их используем - то кеш. Если мы где-то храним не данные, указатели на другие данные - то индекс =) Ну в какой-то мере индекс может являться кешом, если нужны только те данные, что в индексе... и то не всегда. Но индекс все же подразумевает... монолитность, т.е. построен по заранее определенном участку данных. А если, например, на каждый запрос сохранять какой id соответствует какая страница - то все же кеш =)
А по теме - то вариант с таким кешированием мне и нравится. Т.е. после запроса сохранять для данного запроса соответствие страница - id. Если сразу полезут на 1000-ую страницу - оно не спасет, а если пойдут сверху вниз - то будет работать.
А по теме - то вариант с таким кешированием мне и нравится. Т.е. после запроса сохранять для данного запроса соответствие страница - id. Если сразу полезут на 1000-ую страницу - оно не спасет, а если пойдут сверху вниз - то будет работать.
в редисе как раз и сохраняются указатели на данные, а все данные в mysql, т.е. индекс. В редисе не хранится ни страница ни что-то еще, а только id поля в mysql таблице, т.е. указатели. Сортировку и выборку по номеру (не по ключу) делает сам редис, на стороне пхп или Mysql никаких расчетов страниц нет - только выбор по номеру в списке (т.е. если обобщенно быстрый вариант limit-а).
Ситуация с хранением номера страницы - типичный кеш, если использовать систему снепшотов. Т.е. неспеша генерируем номера страниц в одну таблицу, в этот момент выбирая из предыдущей ревизии, а после генерации работаем с новой и так далее. Но я же сказал что так можно сделать, но не говорил что именно так и сделано - ведь это значительное усложнение кода.
P.S. Всетаки кажется что большинство участников обсуждения не работали с сортированными списками редиса - отсюда и все непонимание...
Вот именно поэтому я и написал:
.
что конечно же довольно странно звучит, хотя все рамках определения кеша - раз одно хранилище более быстрое, то его можно назвать кешем по отношению к другому.
Ладно если в данном решении считать, что данные полностью в редисе (mysql не используется вообще) Вы тоже будете говорить что это кеш, учитывая что в таком случае нет более быстрого и более медленного хранилища?
P.S. В моем случае все данные можно было кидать в редис, а не только индекс, но с точки зрения расхода памяти эффективнее было использование Mysql.
alekciy
Новичок
Проблема да, известная. В контексте Postgresql можно почитать тут: Постраничный вывод больших объемов данных. Вообще рекомендую этот блог полистать.
Знаю что проблема известная и все решения известны, но все обходят проблему, а не решают
Подумал просто что может кроме редиса есть еще хоть какое-то полноценное решение (знаю что есть у оракла выборка по порядковому номеру, но помедленнее чем редис будет, зато быстрее чем limit-ы mysql и postgre)
alekciy
Новичок
Чисто на правах варианта. Не было ли попытки использовать sphinx? RT индексы, sql-подобный синтаксис позволяющий в том числе и insert и select. На вскидку, может и взлететь.
alekciy
Новичок
Проблема решена, если удовлетворены все изначальные требования. Не важно, как это реализовано технически, это вполне может быть и костыль (инженерное дело это всегда компромисс), главное, что задача была решена и работает. Поэтому это не обход, а именно решение. Поэтому может просто стоит немного изменить свое мировоззрение?Знаю что проблема известная и все решения известны, но все обходят проблему, а не решают
Это сразу все поставить на места и вернет покой в уставшую душу разработчика 
ну а что с фултекст индекс пихать? мне то искать не надо - мне сортировать и считать позицию надо
Типичный пример - любой рейтинг где может быть много участников. Типичная задача найти страницу с участником рейтинга, что-бы пользователь увидел конкурентов рядом.
И почему если пагинация - это сразу поиск и сразу уточнение запроса. Ну надо как бы догадаться что если кто-то начал использовать редис с его сортированными списками, то значит по какой-то причине не подошли все готовые решения (и все решения с уточнением выборки не подошли) и что человек в курсе как работает оптимизатор запроса при limit-е.
И почему все сразу говорят, что гугл тоже не показывает полностью - не показывает, потому что пользователю это не нужно. Если бы было нужно показывал бы - куда бы он делся (просто в случае поиска пользователю объективно больше не нужно).
Почему все говорят что это невозможно и можно идти только обходным путем?
Насчет пагинации, кстати именно так и обстоит дело - все объясняют что это нафиг никому не надо и пишут чем это можно заменить.
А как же спортивный интерес, а как же решение трудной задачи хотя бы в целях саморазвития и не задумываясь что все кричат на каждом углу, и дойти свим умом? Или проще тупо копипастить?