Здравствуйте, gandjustas, Вы писали:
EP>>>>Здесь под динамическими фильтрами и предикатами — подразумеваются выражения неизвестные во время сборки приложения. Их "специальность" в том, что для них нельзя построить индексы заранее, а не в том что у них какой-то особенный синтаксис.
G>>>Ты предполагаешь, что любой запрос равновероятен?
EP>>Необязательно.
G>Да или нет?
"Необязательно" означает что запросы могут быть как равновероятны, так и нет.
G>>>Тогда чем поможет кеш?
EP>>Закэширует равновероятные запросы (которые помечены например как "result cache").
G>То есть всетаки ручной кэш?
Да, смотри цитаты в предыдущем сообщении.
G>Тогда зачем его держать в базе? Sinclair наглядно показал бесполезность этого подхода.
Он этого не показывал. Он лишь показал что в некоторых конкретных случаях, при определённых условиях (типа expiration: never), целесообразно использовать внешний кэш.
G>>>А если не равновероятен, то в чем проблема построить индексы?
EP>>1. Например акцент распределения меняется со временем — индекс сегодня подходящий для 95%, завтра может подходить лишь для 5% запросов.
G>Ну ок, поменяй индексы. Это не проблема.
Пока будешь собирать статистику и менять их — распределение может опять измениться.
G>А вот поправить программу, которая говорит базе какие результаты кешировать, а какие нет — сложнее.
G>Так что кэш в базе и с точки зрения удобства использования оказывается хуже.
Опять же, зависит от.
Ставить внешний кэш и возможно следить за тем чтобы данные в нём не прокисли может быть неудобней чем просто поправить пару строчек кода
EP>>2. Другой пример: ок, выделили 80% типичных запросов, построили для них индексы — но под остальные запросы они никак не подходят, и паттерны доступа там меняются со временем. Так вот, кэши могут ускорить оставшиеся 20%, чтобы они повторно не грузили систему.
G>Ты говоришь об автокеше или о ручном? Если ты кешируешь все, то hit ratio низкий и кеш бесполезен.
Конкретно здесь про ручной и запросы с динамическими формулами.
G>Если ты кешируешь выборочно, то твой кеш будет ориентироваться на те же вероятности. Только когда паттерны доступа изменятся (что на практике не происходит само по себе), то твой выборочный кеш потребует пересборки приложения, а индексы в базу добавить проблем нет.
Здесь обсуждаются не просто паттерны и типичные запросы, а в контексте запросов с динамическими формулами.
EP>>3. Набор покрывающих индексов может оказаться слишком дорог. Причём даже если не брать в рассмотрение место на дисках, то они отнимают RAM, что увеличивает чтения с диска — так как для разных "индексированных" запросов требуются разные индексы, и помимо этого требуется сама таблица для менее частых (но всё же актуальных) "не индексированных" запросов.
G>Ты всетаки считаешь что запросы равновероятны?
Конкретно в этой ветке мы обсуждаем не равновероятные:
http://rsdn.ru/forum/flame.comp/6022150.1Автор: Evgeny.Panasyuk
Дата: 20.04.15
G>А если не равновероятен, то в чем проблема построить индексы?
G>Если нет, то зачем делать много индексов?
Тут даже не важно много их или нет. Важно то, что нам всё равно нужны и индексы (причём возможно с лишними колонками) и сама таблица (для тех редких запросов), что забивает память.
