Добавить комментарий

Firebird 2.5: состояние

Давненько я не обращался к теме Interbase/Firebird. Последний раз прототип приложения с использованием Firebird 1 был сделан в 2002 году, с тех пор не складывалось. Изучая содеянное разработчиками за 11 лет, исполняюсь противоречивыми впечатлениями.

Даже учитывая тяжелое наследие Interbase, нельзя признать нормальным тот факт, что для создания внешнего ключа (foreign key) между двумя таблицами в этой СУБД надо проводить операцию только при наличии одного единственного соединения к БД. Притом что сами таблицы создать можно и в обычном соединении. И просуществовало это ограничение до версии 2.1.

Штаных же средств соединения в однопользовательском режиме нет. Не учитывая юмористического FAQ по теме, предлагают (1, 2) утилитой gfix отключить базу данных (в экспулуатации, да), потом её же включить в режиме sysdba, что впрочем, тоже не гарантирует наличия более одного соединения (как, у вас более одного человека имеют доступ sysdba?). Дискуссия с "объяснениями" несколько проясняет причины такого наследства.

Редакций Firebird по-прежнему несколько, добавилась SuperClassic. Зачем они все нужны?

Исторически, Interbase использовал classic-архитектуру: на каждое соединение стартовал свой серверный процесс. Соответственно, надежность (один процесс "упал" остальные "не заметили потери бойца"), параллелизм (средствами ОС), но отсутствие общего кэша данных. В superserver серверный процесс один, каждое соединение работает в потоке с разделяемым кешем. Но вот незадача: super не умеет распараллеливать запросы. То есть, пока один запрос выполняется на 100% одного ядра (одного процессора), остальные ждут. Эту ситуацию якобы исправляет появившаяся редакция super classic. На самом деле, super classic - это тот же "классик", но обернутый в один процесс: потоки внутри по прежнему максимально изолированы и потому не разделяют кэш, риск падения сервера снижается, но по сравнению с классиком разница в производительности практически никакая. Если точнее, один поток не соответствует соединению, поскольку используется пул соединений, использующих потоки по мере необходимости, поэтому "суперклассик" должен быть немного производительнее и рачительнее к памяти. Администратору же удобнее наблюдать и поддерживать в работоспособном состоянии один процесс, чем множество. При этом, "супер" Interbase еще в версии 7 от Borland умел распараллеливать запросы по нескольким процессорам (ядрам), то есть ребята изначально пошли по пути усовершенствования редакции, а не создания новой.

Собственно, кэш у Firebird весьма условный, как пишут в обсуждении. СУБД вовсю использует файловый кэш ОС, поэтому сбросить его для проверки производительности запросов невозможно даже перезапустив СУБД (например, в SQL Server для этого есть специальная команда), поэтому гугл выдает множество ссылок по ключевым словам "firebird clear cache".

Средства администрирования, прежде всего аудита и мониторинга, те что из комплекта, достаточно примитивны. Например, трассировщик запросов (образцом может служить MS SQL Server Profiler) являет собой утилиту командной строки, запускаемую со своим конфигурационным файлом. Далее, расшифровку логов надо вести руками при помощи регулярных выражений. Есть и коммерческие утилиты, предоставляющие более дружественный интерфейс. В версии 2.5 появились возможности накопления статистики в системных таблицах MON$XXX.

Средством "полной очистки" БД от мусора до сих пор является процедура резервного копирования и последующего за ним восстановления при помощи утилиты gbak. Однако, эта процедура означает отключение СУБД от пользователей на всё время восстановления, т.е. работа в режиме 24x7 проблематична. При этом файл данных понемногу растет даже при нулевом балансе добавленных/удаленных записей с постоянной фиксацией транзакций, данные дефрагментируются, снижается производительность. Удивляет, что до сих пор ничего не сделано в этом направлении (см. тот же VACUUM в PostgreSQL).

СУБД не блокирует используемые файлы. То есть файл БД можно скопировать на сервере прямо во время многопользовательской работы. Как оказалось, некоторые наши клиенты именно так и поступают, называя такое непотребство "резервным копированием". Непотребство заключается в том, что во время копирования нет никакой гарантии нахождения файла в целостном состоянии как и отсутствия активных пишущих транзакций. Наверное, все-таки лучше предусмотреть блокирование, как дополнительную защиту "от дурака".

С одной стороны - удобный сервер для разработчиков: лёгкий, переносимый, с развитым процедурным языком, полноценная встроенная (embedded) версия, средства доступа практически во всех средах разработки от Явы до Руби. С другой - проблема для администратора: шаманство перехода в негарантированный монопольный режим, неурядицы с кэшем и редакциями, относительно примитивные средства трассировки и мониторинга, не позволяющие поднять усредненную планку использования выше "больших рабочих групп" (многие десятки пользователей с БД в десятки Гб).