Скорость получения данных через ORM, как быстрее?

Question

[Иван]

Есть довольно крупный проект на Kohana3. ORM используется Jam. Но это не столь важно.

На сайте имеются различные списки с фильтрациями-пагинациями, для генерации которых требуются 5 и более ассоциаций с другими таблицами (все настроено на уровне ORM). Все это дело очень удобно сделано и хорошо работает средствами CMF. Естественно, списки получаются чем-то вроде findAll(), потом результат в цикле перебирается, в цикле же происходят обращения к ассоциациям и генерация каждого элемента списка. Благодаря lazy load в итоге получаем по запросу на каждое обращение к данным. И в конечном итоге вместо одного большого запроса имеем сотни мелких, что по скорости генерации страницы гораздо медленнее.
Вообще, похоже, что такие сложные запросы (с ассоциациями) выполнить средствами ORM в один запрос невозможно. Поправьте, если ошибаюсь. Можно пример на других ORM, все равно, думаю, что они примерно одинаково все работают.
Так вот, остро стоит вопрос об оптимизации скорости генерации страницы. Я вижу несколько путей решения:
1) Писать руками большие и толстые SQL-запросы. Плюсы: они будут быстрее выполняться; меньше нагрузка на БД. Минусы: это будет занимать много времени, т.к. я не очень хорошо знаю SQL; это плохо выглядит в коде; это не очень удобно при наличии фильтрации и пагинации.
2) Использовать Redis. Плюсы: опять же, это быстро; нагрузки на БД почти нет; есть множества, которые можно объединять для использования при фильтрации; вроде как множества можно использовать и для пагинации. Минусы: про redis я только слышал/читал; надо понимать, как обновлять в нем данные при обновлении БД, а обновляться она будет часто.
3) Тупо кешировать (Memcache) все списки, включая все фильтры и страницы. Но это как-то слишком в лоб.

Какой подход наиболее оптимален в плане трудозатраты/результат? Может быть, еще есть какой-то вариант?
P.S.: мне лично больше приглянулся вариант 2. В связи с этим вопрос, если со мной кто-то согласится: как лучше реализовывать пагинацию? Каждую страницу отдельно хранить, или получать по частям из общего списка объектов? Извините, если вопрос не корректен, повторюсь, Redis я никогда не трогал.

Answer 1

[MegaMufa]

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

Тут нет серебряной пули. Берете профилировщик, находите самые медленные места и думаете, какой из этих подходов подходит тут чуше всего. Реализуете его. И так дальше по списку.

Answer 2

[Mikhail]

Если не знаете что такое join(а лучше понимать inner left right) лучше пока не браться за разработку(если не пишите на Mongodb)...
Скорость как правило наоборот не нужна особо. Нужно прежде всего делать код читабельным.

Comments

[Иван]

Не уловил, к чему тут намек про join, но я знаю, что это такое. Говоря про "не очень хорошо знаю SQL" я не совсем это имел в виду.
Кому не нужна скорость? Разработчикам? Согласен полностью. Клиентам? У них пробовали спросить? Если страница рендерится на бэкенде более 10 секунд, я считаю, что это повод задуматься об оптимизации скорости. Вы не согласны?

[Mikhail]

Попробуй тогда посмотреть count запросы innodb, я слышал что есть такой косяк. Но я честно говоря не знаю как это написать код который рендерится больше 10 секунд. Хотя я не когда почти не смотрю на скорость запросов. Всё и так как то быстро работает и никогда не было более 1 сек.

[Иван]

Не код и не сами запросы. Просто когда количество запросов на странице переваливает за 500 средствами ORM, начинаются проблемы. А в коде все красиво и понятно.