Современные объемы хранимых данных, обязательные требования к их доступности и скорости обработки, динамика развития систем обуславливают важность исследования факторов, влияющих на качество баз данных, лежащих в основе современных информационных систем.

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

С точки зрения функционирования распределенной системы, одним из главных критериев является время отклика при обращении к базе данных. Время отклика складывается из продолжительности следующих процессов: доставка запроса; обработка запроса и поиск необходимой информации; доставка результатов запроса клиенту. Для минимизации данного показателя необходимо комплексное исследование всех подсистем, реализующих эти функции. Таким образом, целью магистерской работы является исследование характеристик распределенной системы, в частности, сервера InterBase, которое позволит выявить возможные пути оптимизации приложений баз данных.

Здесь приводится ряд выводов относительно разработки эффективных приложений, сделанных в ходе изучения работ некоторых специалистов в области баз данных.

Прежде чем приступать к оптимизации приложения баз данных, необходимо выявить узкие места в системе и уже затем оптимизировать именно их. Если приложение еще не создано, то о его оптимизации следует задуматься уже на этапе разработки, так в дальнейшем исправить ошибки будет сложнее. Далее перечисляются аспекты, влияющие на производительность работы приложения:

1. Выбор стратегии доступа к данным.
   Многозвенная архитектура решает проблемы масштабируемости, поэтому она должна использоваться во всех приложениях, за исключением самых простейших. Многозвенные системы должны изначально разрабатываться так, чтобы они никогда не запрашивали большие объемы данных (это требование должно строго соблюдаться в системах, где сервер приложений не сохраняет состояния – stateless application server). В двухзвенных системах таких жестких ограничений не существует. [1]

2. Нормализация таблиц базы данных [2].

3. Выбор компонентов доступа к данным.
   Следует принять решение о том, какие компоненты для доступа к данным использовать: независимые от типа СУБД или адаптированные для работы с определенным типом СУБД (например, компоненты InterBase Express - IBX). Если в процессе эксплуатации системы не ожидается замены сервера БД, то лучше использовать специфические компоненты (IBX), так как они позволяют достичь значительно лучшей производительности.

4. Создание эффективных запросов к базе данных. [3]

   4.1. Минимизация объемов данных, передаваемых по сети.
   Прежде всего следует запрашивать меньше данных (не использовать оператор '*' в запросах на выборку, перечислять поля явно; продумать пользовательский интерфейс так, чтобы не было необходимости возвращать пользователю все записи таблицы, предоставив ему средства для поиска; предпочтительно выполнять объединение таблиц (операторы WHERE, JOIN) вместо lookup-полей).

   4.2. Выполнение подготовки запросов (метод Prepare()).

   4.3. Отказ от использования вложенных подзапросов [4].

   4.4. Отказ от использования итераций по наборам данных.
   Работа в многопользовательской среде делает сложным подсчет записей, поэтому желательно не использовать свойство RecordCount и агрегатную функцию SQL COUNT. Также следует избегать итераций по результирующему набору, поскольку это означает пересылку большого объема данных между клиентом и сервером. Процесс значительно ускорится, если эти операции выполнять на сервере.

5. Правильное использование механизма транзакций.

   5.1. Определение уровней изоляции.
   Следует разделить все запросы на группы и для каждой группы использовать транзакции с определенными параметрами (уровнем изоляции, режимом доступа). Например, для запросов на чтение самых последних изменений в базе данных установить уровень изоляции транзакции read committed, а для запросов на чтение данных для построения отчета - уровень изоляции snapshot [5]. Установление транзакции в режим только для чтения (Read-Only) позволяет указать цель использования транзакции, в некоторых случаях это позволяет серверу провести внутреннюю оптимизацию.

   5.2. Рациональное завершение транзакций.
   Существует два способа завершения транзакций: подтверждение (Commit) и откат (Rollback). Откат следует делать только тогда, когда это действительно необходимо, в остальных случаях – подтверждать, так как количество откатов учитывается сервером для определения момента времени очистки базы данных. Транзакции с долгим временем жизни способны значительно повысить загрузку сервера, следовательно, при планировании проекта следует обращать внимание на то, чтобы транзакция не оставалась активной дольше, чем существует запрос (поэтому нужно с осторожностью использовать одну транзакцию для нескольких запросов). Нежелательно использовать Commit/Rollback Retaining, так как они не завершают транзакцию. Транзакции предпочтительнее завершать, даже если их немедленно придется перезапустить, так как это уменьшает время жизни транзакции.

   5.3. Очистка базы данных (сборка мусора).
   Существует несколько способов решения проблем с производительностью, связанных со сборкой мусора: во-первых, запретить автоматическую очистку базы данных и запускать ее вручную в период наименьшей загруженности сервера [5], во-вторых, использовать транзакции в режиме read committed вместо snapshot и, по возможности, избегать откатов.

6. Изменение значений параметров конфигурационного файла сервера. [6]
   В InterBase – это файл ibconfig.

7. Настройка размера кеша базы данных.

8. Выполнение резервного копирования и восстановления из копии.
   В результате пересоздания базы данных происходит удаление устаревших версий записей («мусора»), перестройка индексов, дефрагментация страниц базы данных.

9. Использование функций, определяемых пользователем (UDF), триггеров, хранимых процедур.
   Это приводит к увеличению скорости вычислений и снижению нагрузки на сеть. [5]

Были проведены эксперименты (тест вставки и тест удаления), целью которых было установить каким образом индексы влияют на скорость выполнения запросов вставки и удаления записей (INSERT, DELETE) в базе данных InterBase.

Здесь приводится только общая идея алгоритма, без подробностей реализации, и анализ полученных результатов.

Тест вставки записей состоит в следующем: в таблицу, содержащую определенное количество записей (возможно, пустую) вставляется некоторое количество записей, время выполнения этого запроса засекается и сохраняется. При этом запрос на вставку записей выполняется для таблицы с индексированными полями, так и с неиндексированными. Таким образом, можно оценить влияние индексов на время выполнения запроса типа INSERT. Описание алгоритма см. рис. 1.

АЛГОРИТМ ВСТАВКИ Открыть тестируемую базу данных; Запустить транзакцию; Зафиксировать дату и время (BeginTime); Цикл: от 1 до ACount      {Выполнить запрос INSERT;} Зафиксировать дату и время (EndTime); Зафиксировать изменения, выполненные транзакцией (Commit) Сохранить результаты тестирования в базе данных результатов. Примечание: ACount – количество вставляемых записей

Тест удаления записей выполняется аналогично тесту вставки, только с учетом особенностей многоверсионной архитектуры InterBase. Описание алгоритма см. рис. 2.

АЛГОРИТМ УДАЛЕНИЯ {определение времени выполнения запроса SELECT} Зафиксировать дату и время (BeginTime); Выполнить запрос SELECT; Зафиксировать дату и время (EndTime); TimeForSelect := EndTime – BeginTime; {определение времени выполнения запроса DELETE} Зафиксировать дату и время (BeginTime); Выполнить запрос DELETE; Зафиксировать дату и время (EndTime); TimeForDeleteQuery := EndTime – BeginTime; {определение времени выполнения запроса SELECT + времени сборки мусора} Зафиксировать дату и время (BeginTime); Выполнить запрос SELECT; Зафиксировать дату и время (EndTime); TimeForSelectAndSweep := EndTime – BeginTime; {определение реального времени удаления} DeleteTime := TimeForDeleteQuery + TimeForSelectAndSweep - TimeForSelect

Тесты вставки записей:

Результаты тестов изображены в виде диаграммы. На оси Х отложено количество записей в таблице до вставки, по оси У – время выполнения запроса на вставку.

	Тест 1 В пустую таблицу последовательно добавляются записи по 50 тысяч, пока число записей в таблице не достигнет 1 млн. 250 тысяч. В таблице нет активных индексов.
	Тест 2 В пустую таблицу последовательно добавляются записи по 100 тысяч, пока число записей в таблице не достигнет 1 млн. 300 тысяч. В таблице нет активных индексов.
	Тест 3 В пустую таблицу последовательно добавляются записи по 200 тысяч, пока число записей в таблице не достигнет 1 млн. 400 тысяч. В таблице нет активных индексов.
	Тест 4 В пустую таблицу последовательно добавляются записи по 50 тысяч, пока число записей в таблице не достигнет 1 млн. 250 тысяч. В таблице есть активные индексы.
	Тест 5 В пустую таблицу последовательно добавляются записи по 100 тысяч, пока число записей в таблице не достигнет 1 млн. 300 тысяч. В таблице есть активные индексы.
	Тест 6 В пустую таблицу последовательно добавляются записи по 200 тысяч, пока число записей в таблице не достигнет 1 млн. 400 тысяч. В таблице есть активные индексы.

Тесты удаления записей:

Следует обратить внимание на важную особенность архитектуры сервера InterBase при выполнении теста удаления записей. Дело в том, что транзакция, выполняющая запрос на удаление (DELETE …) не производит фактического удаления записей, это связано с многоверсионной архитектурой, реализованной в InterBase, поэтому и время выполнения запроса DELETE будет мало. Реальное же удаление записей производит уже другая транзакция, которая обращается к записям после выполнения запроса DELETE. Поэтому при вычислении времени, затрачиваемого на удаление записей, следует это учитывать.

Таким образом, время, потраченное на удаление записей, складывается из времени выполнения запроса DELETE (при этом удаляемые записи просто помечаются как удаленные) и времени, потраченном запросом SELECT (который выполняется сразу после предыдущего запроса) на сборку мусора.

Был проведен ряд тестов в таблице, содержащей от 500 тысяч записей до 1 млн. 200 тысяч.

Для таблицы, не содержащей индексированные поля, было установлено время удаления от 7 до 12 секунд.

Для таблицы с индексированными полями это время составило от 14 до 18 секунд.

Тест вставки:

Тесты показали, что если таблица не индексированная, то время вставки мало (в среднем: 30 с - для вставки 50 тысяч записей, 55 с – для вставки 100 тысяч записей, 2 мин. – для вставки 200 тысяч записей), причем это время не зависит от степени заполненности таблицы, в которую записи добавляются.

В случае, если таблица имеет поля с индексами, то время вставки существенно увеличивается, к тому же оно увеличивается пропорционально заполненности таблицы, куда производится вставка.

Таким образом, можно сделать вывод, что наличие индексов замедляет процесс вставки. Конечно, пользователю это будет заметно, если вставляется много записей. Поэтому при необходимости вставки большого числа записей (порядка несколько сот тысяч) рекомендуется временно удалять индексы (затем их можно заново создать с помощью запроса CREATE INDEX).

Тест удаления:

Тесты показали, что удаление записей в таблице с индексами занимает больше времени, чем в неиндексированной таблице. Поэтому можно дать ту же рекомендацию, что и при вставке записей: временно отключать индексы. К тому же сразу же после удаления большого числа записей следует выполнять запрос на чтение или backup/restore, производя, таким образом сборку мусора, чтобы запрос пользователя, который будет обращаться к записям, не выполнялся слишком долго.

В результате изучения существующих исследований по теме магистерской работы был сделан ряд выводов, касающихся разработки эффективных приложений баз данных.

В ходе проведения собственных исследований было установлено, что индексация в базах данных InterBase оказывает существенное воздействие на производительность системы. Оба теста показали, что наличие в таблице индексированных полей существенно замедляет выполнение запросов, поэтому их временно следует отключать. Результаты теста удаления позволили также получить практические подтверждения многоверсионности в InterBase. Это в очередной раз подтверждает то, что при работе с базой данных, при выполнении запросов следует внимательно относиться к особенностям архитектуры сервера и учитывать их при работе с базами данных.

1. Optimization I: Optimizing InterBase Applications, by Craig Stuntz, 2003
   (http://bdn.borland.com/borcon2004/article/paper/0,1963,32255,00.html).
   

2. Tips for improving InterBase server performance
   (http://www.ibphoenix.com/main.nfs?a=ibphoenix&s=1133335039:381637&page=ibp_tip_perf).
   

3. Optimization II: Optimizing InterBase SQL and Metadata, Craig Stuntz, Borland Convention 2003.
   (http://blogs.teamb.com/craigstuntz/articles/IBOptimization2.aspx)

4. Оптимизация приложений С++Builder в архитектуре клиент/сервер, Наталия Елманова, Центр информационных технологий
   (http://www.citforum.ru/programming/cpp/cb_498.shtml).
   

5. А. Н. Ковязин, С.М. Востриков "Мир InterBase. Архитектура, администрирование и разработка приложений баз данных в InterBase/Firebird/Yaffil (3-е издание)" - М.: Кудиц-образ, 2005
   

6. InterBase configuration parameters, by Ann Harrison
   (http://ibphoenix.com/main.nfs?a=ibphoenix&s=1132891400:150223&page=ibp_config).
   

При написании данного автореферата магистерская работа еще не завершена. Окончательное завершение: январь 2007. Полный текст работы и все материалы по теме могут быть получены у автора или его руководителя после указанной даты.