Мир InterBase. Архитектура, администрирование и разработка приложений баз данных в InterBase/FireBird/Yaffil

Был улучшен алгоритм работы оптимизатора запросов, в частности в следующих направлениях:

* использование индексов в подзапросах с агрегатами,

* игнорирование "плохих" индексов, т. е. индексов, использование которых может привести лишь к замедлению выполнения запроса;

* более качественный анализ селективности индексов при построении плана;

* оптимальное построение плана в случае доступности одно- и многосегментных индексов;

* более совершенное использование индексов в условиях типа "OR", особенно в случае сложных предикатов (в частности, сложных неявных соединений).

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

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

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

Все вышесказанное привело к заметному увеличению производительности. Например, выполнение серии промышленных тестов TPC-R (уже упоминавшейся в этой книге) показало почти трехкратное превосходство новой версии по сравнению с линией 1.0. Разумеется, это не значит, что выполнение абсолютно всех 5апросов будет осуществляться быстрее, но позволяет рассчитывать на улучшение производительности в ряде случаев

Конфигурирование

Эта версия сервера содержит новый менеджер конфигурации, единый для всех платформ. Все настройки теперь хранятся в файле firebird.conf. Этот файл содержит значительно больше параметров, чем ibconfig в предыдущих версиях. Например, в него вынесены параметры управления памятью, использованием и настройкой сетевых протоколов, режимами совместимости по новым возможностям, настройками безопасности и т. п.

Кроме того, в версии 1.5 реализован механизм "псевдонимов" (aliases) баз данных, т. е. возможность подключения к БД без знания физического пути к соответствующему файлу. Список псевдонимов хранится в файле aliases.conf, расположенном в корневом каталоге установки сервера. Запись о псевдониме выглядит следующим образом: <aliasnarr,e> = <database pathname>

При этом строка соединения с сервером будет выглядеть следующим образом (в случае TCP/IP): <hostname>:<aliasname>. Это позволяет избавить клиентов от необходимости знать структуру файловой системы сервера и обезопасить сервер от несанкционированного доступа извне.

Firebird 2.0 - взгляд в будущее

Итак, выше мы узнали о том, что сделано в рамках версии Firebird 1.5, теперь самое время поговорить о том, что нам стоит ожидать от следующей версии, которая будет носить номер 2.0.

Новая версия ODS

Значительная часть запланированных изменений потребует реализации новой версии ODS (On-Disk Structure), что было признано неприемлемым для версии 1.5 (которая является полностью совместимой с IB6/FB1), поэтому введение новой ODS отложено до версии 2.0. Элементами новой ODS будут являться:

* увеличение размера полей, хранящих имена метаданных, что позволит обойти текущее ограничение в 31 символ;

* увеличение размера ряда внутренних идентификаторов до 64 бит, что позволит, например, хранить больше записей в одной таблице и обрабатывать большее количество транзакций без необходимости цикла backup/restore;

* более полная реализация безопасности метаданных на уровне SQL, что снимет сразу ряд имеющихся в настоящее время проблем в этой области;

* перенос информации о пользователях и группах из системной базы данных isc4.gdb внутрь оперативных баз данных для более качественной защиты тиражируемых продуктов;

* реализация признака корректности скомпилированного объекта базы данных и соответствующего механизма проверки (validation), что позволит более гибко контролировать зависимость объектов друг от друга и их работоспособность при обнаруженных нарушениях в цепочке зависимостей;

* возможность работы со значительно большими размерами ключа индекса;

* несколько новых типов данных и объектов базы данных.

Поддержка SMP

Несмотря на то что классическая архитектура сервера полностью использует возможности SMP-систем, она имеет ряд недостатков, которые накладывают слишком высокие требования на ресурсы сервера в случае очень большого количества соединений с базой данных. Как известно, корпорация Borland отказалась от развития архитектуры Classic и сосредоточила свои усилия на доработке кода SuperServer. В 2002 году мы увидели первый результат их работы - версию InterBase 7.0, в которой декларирована поддержка SMP.

Одной из целей разрабо!ки Firebird 2.0 также является полноценная поддержка SMP во всех вариантах сервера. Здесь можно пойти двумя путями: доработка кода SS (аналогично тому, что сделали в Borland) или объединение кода SS и CS с получением комбинированной архитектуры, позволяющей в зависимости от конфигурации работать либо в режиме разделяемого сервера с общим пулом потоков, либо в режиме выделенного сервера с одним процессом на каждое соединение, либо в одном из смешанных режимов (один сервер на N соединений, один сервер на каждую БД и т. п.). Оба варианта достаточно трудны в реализации, и разработчики проекта еще не приняли окончательного решения на этот счет, но пока наблюдается тенденция к выбору второго варианта (комбинированная архитектура). Это также позволит унифицировать исходный код и упростить внесение в него низкоуровневых изменений.

Средства мониторинга

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

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

Дальнейшее развитие языка SQL

Развитие будет осуществляться по следующим направлениям:

* добавление новых или расширение возможностей существующих команд DDL, в частности по работе с доменами, признаками полей таблиц, кодом процедур и триггеров;

* реализация уникальных ограничений (unique constraints) с возможностью хранений NULL-значений;

* расширение состава встроенных функций в соответствии с SQL-стандартом (TRIM, POSITION, ROUND и т. п.);

* поддержка стандартного типа BOOLEAN (принимающего значения TRUE, FALSE или UNKNOWN) в полях, переменных и логических предикатах языка;