Добрый день.

Разрабатываю приложение, которое использует Firebird в конфигурации Embedded (платформа - Linux, версия FB - 2.1.5). База данных расположена на отдельном диске (без файловой системы - чисто на блочном устройстве).

Есть несколько таблиц со структурой:



Для каждой создан индекс:




Выполняю запрос:



В итоге, при размере таблицы примерно в 700 000 записей первый такой запрос к таблице выполняется от 6 до 17 секунд. Последующие запросы отрабатывают быстрее (подозреваю, вследствие кэширования FB). И далее, чем больше записей, тем больше время выполнения запроса. Макс. время выполнения запроса видел - 65 секунд (!!!!).

Прочитал в документации, что после массового удаления/добавления записей необходимо вручную инициировать пересчет индексов:




И да, это помогает. После перестройки индексов запросы выполняется очень быстро. НО есть две проблемы.

1) Если я завершаю свое приложение и отключаюсь от базы, то при последующем запуске и подключении нужно опять делать перестройку всех индексов - а это приводит к тому, что перестройка всех индексов занимает более 225 сек, что очень плохо. Почему Firebird не сохраняет высчитанные значение в файл базы данных, например ?

2) После перестройки индексов, все запросы из таблицы работают очень быстро, однако, со временем, при изменении таблицы, вновь растет время выполнения запросов. Есть ли какие-либо рекомендации, с какой частотой необходимо перестраивать индексы, чтобы быстро отрабатывались запросы к БД ?

Надеюсь, кто-то сталкивался с таким и поможет найти решение.

__Avenger__NightWizard1) Если я завершаю свое приложение и отключаюсь от базы, то при последующем запуске и подключении нужно опять делать перестройку всех индексов - а это приводит к тому, что перестройка всех индексов занимает более 225 сек, что очень плохо. Почему Firebird не сохраняет высчитанные значение в файл базы данных, например ?

Коммит забыл сделать?

NightWizard2) После перестройки индексов, все запросы из таблицы работают очень быстро, однако, со временем, при изменении таблицы, вновь растет время выполнения запросов. Есть ли какие-либо рекомендации, с какой частотой необходимо перестраивать индексы, чтобы быстро отрабатывались запросы к БД ?

Перестраиваю индексы раз в сутки ночью.

При перестройки коммит для трнзакции делается.

Я тоже хотел один раз в сутки делать, но база наполняется быстро довольно (в каждую такую табличку примерно 10 записей в 20 секунд добавляется - и сутками работает все).

Dimitry SibiryakovNightWizardВ итоге, при размере таблицы примерно в 700 000 записей первый такой
запрос к таблице выполняется от 6 до 17 секунд.
Ты план этого запроса смотрел?

PS: дальше идущий бред пропустил.


Тут все ок:

AriochNightWizard


А зачем Int64, при аличии родного timestamp ?

http://firebirdsql.su/doku.php?id=tipy_dannyx

Ну, предполагая, что у вас третий диалект включён, а то и float получите...

http://wm-help.net/lib/b/book/4054355128/189

Диалект 3. Timestamp не подходит, так как точность до миллисекунд нужна.

Arioch,

Да, тут недоглядел. Но я пробовал менять и на timestamp - от этого быстрее оно не заработало.

Dimitry SibiryakovNightWizardТут все ок:

PLAN (TABLE1 ORDER IDX_TABLE1 INDEX (IDX_TABLE1))
Что об этом индексе говорит "gstat -i"?


Блин, на сервере, где это тестировал gstat'а нет, как и увы gbak'а. Разберусь с этим вопросом.

gfix как раз есть.
Счас посмотрю, подумаю.

AriochNightWizardПрочитал в документации, что после массового удаления/добавления записей необходимо вручную инициировать пересчет индексов

Телега впереди лошади.

1) перед массовым и *монопольным* добавлением/изменением записей *бывает удобно* (чисто для скорости и только для неё, никаих необходимо и близко не стоит) отключить индексы. После этого, действительно, индексы *необходимо* включать - но вовсе не "после массовой вставки", а примитивно "после выключения индексов" (на монопольную операцию, если решили так делать).

2) после массового удаления/изменения записей (сравнимого по кол-ву с общим размером таблицы) образуется непропорционально много мусора. Его желательно - н не необходимо - почистить недожидаясь автоматической регулрно авто-сборки. Но индексы для этого трогать ЕМНИП не нужно, select count(*) from table1 вполне справится. Можно, конечно, и пересчётом индексов того-же добиться.... Это предполагая, что вы не отключали обычную сборку мусора по умолчанию

Сборку мусора не отключал. Если не делать ALTER INDEX idx_Table1 ACTIVE, то даже при старте приложения (а это ведь и старт Embedded сервера по сути) медленно выполняются запросы - а какой мусор может быть у только что запущенного сервиса ?

AriochDimitry Sibiryakovпропущено...

Ни то ни другое. Подвинуть может только sweep, а он стартует только при старте транзакции.

но так даже лучше


запустили программу, убедились что все быстро, остановили программу, скопировали файл БД на полноценный сервер как эталон "всё хорошо".
запустили программу еще раз, погоняли час-два-три до тормозов, остановили и скопировали файл БД как эталон "всё плохо"

потом искать разницу ( !! не подключаясь к ним сервером, а исключительно read-only утилитами типа GStat, ibexpert database inside, IBSurgeon DBInfo http://ib-aid.com/en/ibsurgeon-free-tools/ !! )

тормоза спустя две недели после работы софта начинаются примерно... Это осложняет ситуацию. Ладно, попробую как-нибудь сдампить "плохую" базу и ее посммтреть, видимо по-простому отделаться не выйдет ((

Отчет gstat:

Database header page information:
Flags 0
Checksum 12345
Generation 1753855
Page size 4096
ODS version 11.1
Oldest transaction 1753703
Oldest active 1753704
Oldest snapshot 1753704
Next transaction 1753705
Bumped transaction 1
Sequence number 0
Next attachment ID 88
Implementation ID 24
Shadow count 0
Page buffers 0
Next header page 0
Database dialect 3
Creation date Apr 6, 2016 18:58:41
Attributes

Variable header data:
*END*
...
TABLE1 (140)

Index IDX_TABLE1 (1)
Depth: 3, leaf buckets: 1874, nodes: 744214
Average data length: 4.27, total dup: 0, max dup: 0
Fill distribution:
0 - 19% = 0
20 - 39% = 0
40 - 59% = 1
60 - 79% = 0
80 - 99% = 1873

Index RDB$PRIMARY19 (0)
Depth: 3, leaf buckets: 2207, nodes: 744214
Average data length: 6.06, total dup: 0, max dup: 0
Fill distribution:
0 - 19% = 1
20 - 39% = 0
40 - 59% = 0
60 - 79% = 0
80 - 99% = 2206

..

AriochNightWizard,

Это - "хорошая" или "плохая" ?

"плохая", с адскими тормозами

МимопроходящийArioch, ты в архитектуре сервера профан.
на что и намекает, очень тактично кстати, DS.
читай статьи, про то, что там внутри.
что такое свип, зачем оно вообще надо и т.д.

чтоб не особо напрягать, разверну мысль DS вширь:
автосвип ты можешь отключить манипуляциями gfix, а сборку мусора - нет.



А можно ссылочки на статьи "по системной части" ?

Особенно по архитектуре Embedded.