Re[46]: EntityFramework - тормоз
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 20.04.15 22:27
Оценка: +1
Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>Здравствуйте, gandjustas, Вы писали:


EP>>>Здесь под динамическими фильтрами и предикатами — подразумеваются выражения неизвестные во время сборки приложения. Их "специальность" в том, что для них нельзя построить индексы заранее, а не в том что у них какой-то особенный синтаксис.

G>>Ты предполагаешь, что любой запрос равновероятен?
EP>Необязательно.
Да или нет?
Если да, то кэш в базе не поможет. Если нет, то помогут в первую очередь индексы.

G>>Тогда чем поможет кеш?


EP>Закэширует равновероятные запросы (которые помечены например как "result cache").

То есть всетаки ручной кэш? Тогда зачем его держать в базе? Sinclair наглядно показал бесполезность этого подхода.


G>>А если не равновероятен, то в чем проблема построить индексы?


EP>1. Например акцент распределения меняется со временем — индекс сегодня подходящий для 95%, завтра может подходить лишь для 5% запросов.

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

EP>2. Другой пример: ок, выделили 80% типичных запросов, построили для них индексы — но под остальные запросы они никак не подходят, и паттерны доступа там меняются со временем. Так вот, кэши могут ускорить оставшиеся 20%, чтобы они повторно не грузили систему.

Ты говоришь об автокеше или о ручном? Если ты кешируешь все, то hit ratio низкий и кеш бесполезен. Если ты кешируешь выборочно, то твой кеш будет ориентироваться на те же вероятности. Только когда паттерны доступа изменятся (что на практике не происходит само по себе), то твой выборочный кеш потребует пересборки приложения, а индексы в базу добавить проблем нет.

EP>3. Набор покрывающих индексов может оказаться слишком дорог. Причём даже если не брать в рассмотрение место на дисках, то они отнимают RAM, что увеличивает чтения с диска — так как для разных "индексированных" запросов требуются разные индексы, и помимо этого требуется сама таблица для менее частых (но всё же актуальных) "не индексированных" запросов.

Ты всетаки считаешь что запросы равновероятны? Если нет, то зачем делать много индексов?

S>>>>Индексированное представление — один из хороших вариантов сделать "прикладное кэширование", показав базе, какие производные данные мы ожидаем часто видеть в запросах.

EP>>>Как создать индекс для динамических формул?
G>>Нету в SQL динамических формул, они все для СУБД одинаковые.
EP>С точки зрения зрения приложения они динамические, так как не известны на этапе компиляции.
Все равно для субд они все одинаковые.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.