|
Оптимизирует ли Firebird повторное обращение к результатам view?
|
|||
---|---|---|---|
#18+
Имеется view, которое в свою очередь рассчитывается на основе других view и процедур. Выполняется расчет несколько минут во время чего клиентские приложения (написанные на Delphi) при обращении к базе естественно тормозят. Нужно это обычно раз в день -в обед, когда формируется заявка. Но так как клиентские приложения находятся на кассах, то естественно кассиры ругаются на тормоза. Так вот вопрос: если сделать первый расчет принудительно утром, когда они только приходят на работу и запускают свои приложения и к обеду ситуация изменится очень незначительно, будет ли Firebird при вторичном обращении к этому же самому view пересчитывать все заново с нуля? Либо же это как-то оптимизировано и во второй и последующие разы уже не будет занимать по несколько минут? З.Ы. Речь идет об определении товаров-неликвидов - несколько сотен или тысяч наименований. С утра до обеда изменится от силы пара десятков наименований - что-то залежалое продадут и это уже не будет в обед неликвидом, хотя с утра было. З.З.Ы. Firebird 2.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
28.02.2017, 16:59 |
|
Оптимизирует ли Firebird повторное обращение к результатам view?
|
|||
---|---|---|---|
#18+
Сомневаюсь, что view имеет какой-либо кэш. Тут скорее проблема в решении: ощущение, что речь идет об остатках на начало суток и, соответственно, об индексе по дате. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.02.2017, 17:02 |
|
Оптимизирует ли Firebird повторное обращение к результатам view?
|
|||
---|---|---|---|
#18+
арт2010, копай в сторону хранимых агрегатов. view никогда не хранит вычисленные значения, это просто сохранённый текст запроса ... |
|||
:
Нравится:
Не нравится:
|
|||
28.02.2017, 17:02 |
|
Оптимизирует ли Firebird повторное обращение к результатам view?
|
|||
---|---|---|---|
#18+
арт2010, wadman дело говорит! Загони выборку из view в селективную ХП, которая будет сливать данные в обычную таблицу со штампом времени и проверять, имеются ли в этой таблице актуальные данные. Если есть актуальные данные, возвращаем клиенту данные из таблицы, если нет - формируем актуальные данные, заливаем в таблицу, попутно возвращая их клиенту. На эту процедуру вешаем view с тем же именем и клиент не видит разницы. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.02.2017, 17:10 |
|
Оптимизирует ли Firebird повторное обращение к результатам view?
|
|||
---|---|---|---|
#18+
Ок, всем спасибо за помощь, буду думать ... |
|||
:
Нравится:
Не нравится:
|
|||
28.02.2017, 17:14 |
|
Оптимизирует ли Firebird повторное обращение к результатам view?
|
|||
---|---|---|---|
#18+
1. Посмотреть на планы выполнения, есть ли возможность где-то оптимизировать, 2. Если кассирам мешает этот пересчет, его можно запускать в отдельном потоке или даже в отдельном приложении по таймеру, результат куда-то записывать. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.02.2017, 19:20 |
|
Оптимизирует ли Firebird повторное обращение к результатам view?
|
|||
---|---|---|---|
#18+
S.G., какой план? какой поток? Остатки считаются либо джобом каждые сутки/неделю/месяц, либо триггером на каждый чих. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.02.2017, 19:39 |
|
Оптимизирует ли Firebird повторное обращение к результатам view?
|
|||
---|---|---|---|
#18+
wadmanS.G., какой план? какой поток? Остатки считаются либо джобом каждые сутки/неделю/месяц, либо триггером на каждый чих.Я так понял, что в данном случае считается в клиентском приложении, и оттого оно тормозит, нет? Иначе отчего что-то должно тормозить? ... |
|||
:
Нравится:
Не нравится:
|
|||
28.02.2017, 22:44 |
|
Оптимизирует ли Firebird повторное обращение к результатам view?
|
|||
---|---|---|---|
#18+
S.G.wadmanS.G., какой план? какой поток? Остатки считаются либо джобом каждые сутки/неделю/месяц, либо триггером на каждый чих.Я так понял, что в данном случае считается в клиентском приложении, и оттого оно тормозит, нет? Иначе отчего что-то должно тормозить? Не заметил такого в описании, тем более на кассах вряд-ли ставят мощные компьютеры. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.03.2017, 09:01 |
|
Оптимизирует ли Firebird повторное обращение к результатам view?
|
|||
---|---|---|---|
#18+
Тормозит сама база - проверял запустив view в ibexpert, приложение просто получает готовую инфу из view простым селектом. Думаю пойти по пути наименьшего сопротивления - задать job на утро при открытии БД ... |
|||
:
Нравится:
Не нравится:
|
|||
01.03.2017, 09:43 |
|
Оптимизирует ли Firebird повторное обращение к результатам view?
|
|||
---|---|---|---|
#18+
Если можно изменять клиента, то как более простой вариант - запускать расчет в треде при запуске проги или в любой удобный момент, и кешировать результаты самому. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.03.2017, 10:01 |
|
Оптимизирует ли Firebird повторное обращение к результатам view?
|
|||
---|---|---|---|
#18+
Василий №2Если можно изменять клиента, то как более простой вариант - запускать расчет в треде при запуске проги или в любой удобный момент, и кешировать результаты самому. Я примерно так делаю. После открытия "новой смены" в потоке рассчитываю кэш остатков на начало этой смены. А если нет возможности изменять клиента - всегда можно написать еще одного - фоновую прогу, которая будет запускаться по расписанию. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.03.2017, 13:38 |
|
Оптимизирует ли Firebird повторное обращение к результатам view?
|
|||
---|---|---|---|
#18+
арт2010Тормозит сама база - проверял запустив view в ibexpert торможение может быть вызвано массой причин - на сервере не хватает памяти - слабая дисковая подсистема - не хватает каких-то индексов запросу во view - модель данных слишком денормализована - и т.д. Тем не менее, судя по исходному посту, проблема именно в предпоследнем пункте - на этапе разработки данных было мало, и повторный пересчет одних и тех же данных не вызывал проблем. Когда данных стало больше (и со временем становится еще больше) - разумеется появились тормоза, и периодическое елозенье по одним и тем же данным можно ускорить только переделкой структуры БД, с введением хранимых агрегатов. Пример приведен тут http://www.sql.ru/forum/964534/hranimye-agregaty-bez-konfliktov-i-blokirovok-recept ... |
|||
:
Нравится:
Не нравится:
|
|||
01.03.2017, 14:00 |
|
Оптимизирует ли Firebird повторное обращение к результатам view?
|
|||
---|---|---|---|
#18+
kdv, один мой коллега обожает view's. У него в проекте их уже сотни полторы, наверное. Одна view поверх другой, потом еще и так далее. Все работает ме-е-е-дленно, ибо первые view создавались, когда он только начинал осваивать FireBird (после MS Access). А потом там уже стало "черт ногу сломит". - Распечатай, пожалуйста, отгрузки за прошлый месяц. Это долго? - Нет, мгновенно: минут пять . У меня готовая view для этого есть... ... |
|||
:
Нравится:
Не нравится:
|
|||
01.03.2017, 14:54 |
|
|
start [/forum/topic.php?fid=40&msg=39412487&tid=1561688]: |
0ms |
get settings: |
9ms |
get forum list: |
12ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
64ms |
get topic data: |
11ms |
get forum data: |
2ms |
get page messages: |
51ms |
get tp. blocked users: |
2ms |
others: | 14ms |
total: | 171ms |
0 / 0 |